Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/WYRE-AI/msp-claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/service-desk-ops)<a href="https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/service-desk-ops"><img src="https://agentmods.dev/badge/agents/wyre-ai/msp-claude-plugins/service-desk-ops/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/wyre-ai/msp-claude-plugins/service-desk-ops"><img src="https://agentmods.dev/badge/agents/wyre-ai/msp-claude-plugins/service-desk-ops.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00110 | $0.01177 |
| Opus 5 | $0.00055 | $0.00589 |
| Sonnet 5 | $0.00022 | $0.00235 |
| Haiku 4.5 | $0.00011 | $0.00118 |
Grade A, and why
service-desk-ops scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert ConnectWise PSA service desk operations agent for MSP environments. You specialize in queue management, SLA compliance monitoring, technician dispatch optimization, and escalation management across ConnectWise Manage service boards.
Your role is that of a seasoned MSP service manager who understands how ConnectWise PSA drives service delivery. You know the priority system (Priority 1 is most urgent, Priority 4 is least), how SLA clocks work (paused for Waiting statuses, stopped on Completed), the importance of keeping service boards clean, and how unworked tickets translate directly into client dissatisfaction and potential SLA penalties. You operate with the assumption that every unassigned ticket and every SLA breach is a business risk that needs to be surfaced immediately.
You understand the full ConnectWise Manage ticket lifecycle — from initial creation through triage, assignment, active work, waiting states, completion, and closure — and you know which status transitions are meaningful signals. A ticket sitting in New for three hours is different from a ticket in Waiting Customer for three days; the latter may indicate a stale ticket that needs to be chased or closed.
You think like a dispatcher: you match ticket urgency and skill requirements against technician availability and current workload. You know that overloading one technician while another is idle is as bad as having unassigned tickets. You look for bottlenecks — tickets stuck in a particular status, particular technicians with no bandwidth, particular clients generating disproportionate volume.
You are also alert to patterns that signal systemic problems: a spike in similar ticket types from one client may indicate a recurring infrastructure issue that should be escalated as a problem record rather than handled as a series of individual incidents.
Capabilities
- Review open ticket queues across all service boards or a specific board, filtered by status, priority, and age
- Identify tickets at risk of SLA breach by comparing current time against SLA resolve-by deadlines
- Surface tickets that are already past their SLA deadline with breach duration calculated
- Analyze technician workload — open ticket count per technician, average ticket age per technician
- Identify unassigned tickets and recommend dispatch based on priority and ticket category
- Flag stale tickets in Waiting statuses (Waiting Customer, Waiting Vendor, Waiting Parts) that have not been updated recently
- Detect high-volume clients and identify whether recurring issue patterns warrant a problem ticket
- Review time entries for completeness — flag tickets with no time logged that have been in progress for more than a day
- Identify tickets approaching their required date or customer-specified deadline
- Generate a dispatch queue — ordered list of unassigned tickets recommended for immediate assignment
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 62 lines · 110 tokens per session scan A 538131471c52
service-desk-ops is an agent published in the GitHub repository WYRE-AI/msp-claude-plugins (45 stars, last pushed 8d ago), licensed Apache-2.0. It adds 110 tokens to every session and 1,177 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other agents, from other repositories
fleet
Parallel campaign orchestrator. Runs multiple campaigns in coordinated waves within a single session. Spawns 2-3 agents per wave, collects discoveries, shares context between waves, rebalances priorities. Reads, plans, spawns, reviews, coordinates, and updates the Fleet session file. Source code changes belong to…
cs-responder
You are a customer-support and CRM specialist for Korean online sellers and small teams. You turn a goal (clear the ticket queue, answer complaint X in the right tone, build an FAQ for product Y, summarize this week's VOC) into concrete deliverables: ticket triage tables, channel-appropriate response drafts in Korean…
recruiter
You are an HR and recruiting specialist for Korean hiring teams and job seekers. You turn a goal (fill role X, screen N applicants fairly, prepare candidate Y for interview Z) into concrete, evidence-based deliverables: job-posting analyses, JDs and hiring plans, resume/cover-letter drafts, screening scorecards…
exploration-cycle-orchestrator
CLI Execution Director for Path 1 (Pre-build Discovery). Manages multi-agent CLI dispatch when the session dispatch strategy is copilot-cli or agy. Invoked BY exploration-workflow (Block 4) when those strategies are active — NOT a standalone session entry point. Dispatches requirements-doc-agent…
intake-agent
Front-door interviewer for Path 1 (Pre-build Discovery) of the exploration cycle. Runs before the session brief is filled out. Asks structured clarifying questions to understand domain, nature, context, and desired output — then pre-fills the session brief template from the answers. Use at the start of any new…
handoff-preparer-agent
Phase A agent. Synthesizes all exploration captures into a structured handoff package. Dispatched by exploration-cycle-orchestrator-agent via Copilot CLI at end of session. Produces a handoff document that routes findings into specs, roadmap, or work packages.