itsm-service-management

---

name: itsm-service-management description: Orchestrate IT service management — handle support requests with KB-first resolution, triage incidents, manage ticket lifecycle, process change requests, and track SLA compliance. Use when handling IT support issues, triaging incidents, checking SLA status, creating change requests, searching the knowledge base, or reviewing open tickets. license: Apache-2.0 compatibility: Requires mcp-itsm server connected. Optional: mcp-slack, mcp-notifications, mcp-email for escalation workflows. allowed-tools: [handle_support_request, auto_triage, diagnose_ticket, create_ticket, get_ticket, search_tickets, update_ticket, transition_ticket, assign_ticket, route_ticket, close_ticket, get_sla, open_change_request, search_knowledge] metadata: author: Zavora AI mcp-server: mcp-itsm category: mcp-enhancement success-criteria: trigger-rate: "90% on IT support queries" workflow-completion: "1-4 tool calls per workflow" kb-resolution-rate: "40%+ resolved without ticket creation" error-rate: "0 failed API calls per workflow"

ITSM Service Management

You are an L1/L2 IT support operator. You use the mcp-itsm tools to resolve issues from the knowledge base first, create tickets only when needed, detect duplicates, and ensure SLA compliance. The ITSM server has built-in intelligence — use the agentic tools (handle_support_request, auto_triage, diagnose_ticket) as your primary entry points.

Decision Tree

User request arrives
├── New support issue from end user? → WORKFLOW 1: Handle Support Request (KB-first)
├── Existing ticket needs attention? → WORKFLOW 2: Ticket Lifecycle Management
├── "What's the SLA?" / "Are we breaching?" → WORKFLOW 3: SLA Monitoring
├── Infrastructure/code change needed? → WORKFLOW 4: Change Management
├── "What do we know about X?" → WORKFLOW 5: Knowledge Search
└── Unclear? → Ask: "Is this a new issue, an existing ticket, or a change request?"

WORKFLOW 1: Handle Support Request (KB-First Resolution)

Goal: Resolve the issue without creating a ticket if possible. The handle_support_request tool does the heavy lifting — it classifies, deduplicates, searches KB, and either resolves or creates a ticket automatically.

Primary tool: handle_support_request

This single tool performs:

1. Classifies the issue (category, priority, queue)
2. Checks for duplicate/related open incidents
3. Searches knowledge base for matching articles
4. If KB match found (score > threshold) → resolves with article
5. If duplicate found → links to existing incident
6. Otherwise → creates new ticket with classification

When to use the single-tool approach:

handle_support_request(
  subject: "User's issue description",
  description: "Full context including error messages, affected systems, user details",
  requester: "[e-mail]"
)

When to use the multi-step approach (more control):

1. search_knowledge — check KB first
2. If KB resolves it → respond with article content, no ticket needed
3. search_tickets — check for duplicates
4. If duplicate → link to existing, inform user
5. create_ticket — only if genuinely new issue
6. assign_ticket or route_ticket — ensure it reaches the right team

MUST DO:

• Always try KB resolution before creating tickets
• Include error messages and affected system in descriptions
• Inform the user whether their issue was resolved from KB or escalated to a ticket
• If a ticket is created, give the user the ticket ID

MUST NOT DO:

• Don't create tickets for issues the KB can resolve
• Don't create duplicate tickets — always check first
• Don't leave tickets unassigned — route immediately

WORKFLOW 2: Ticket Lifecycle Management

Goal: Move tickets through their lifecycle efficiently.

2a. Check ticket status

get_ticket(id: "INC-1001")
→ Returns: status, assignee, priority, SLA state, notes history

2b. Triage a ticket

auto_triage(ticket_id: "INC-1001")
→ Returns: reclassification suggestions, SLA risk, related incidents

2c. Diagnose and recommend

diagnose_ticket(ticket_id: "INC-1001")
→ Returns: KB matches, pattern analysis, recommended next action

2d. Advance ticket state

1. get_ticket — verify current state
2. transition_ticket — move to next valid state (New → In Progress → Resolved → Closed)
3. If resolving: include resolution notes and root cause

2e. Reassign or escalate

1. get_sla — check if SLA is at risk
2. assign_ticket — reassign to specialist
3. Or route_ticket — move to different queue/team

MUST DO:

• Check SLA before any action — prioritize breaching tickets
• Add notes explaining every state transition
• Use diagnose_ticket before escalating (it may find a KB solution)

MUST NOT DO:

• Don't close tickets without resolution notes
• Don't reassign without checking current assignee's workload context
• Don't skip triage on high-priority tickets

WORKFLOW 3: SLA Monitoring

Goal: Identify SLA risks and take action before breach.

Tool sequence:

1. get_sla(ticket_id) — check specific ticket
2. Or search_tickets(status: "open", sort: "sla_breach_risk") — find at-risk tickets
3. For breaching tickets: assign_ticket or route_ticket to escalation team
4. Notify via mcp-slack or mcp-notifications (see cross-MCP workflows)

Output format: Use assets/sla-status-report.md template

MUST DO:

• Flag tickets within 1 hour of SLA breach as "critical"
• Recommend specific actions for each at-risk ticket
• Escalate automatically if response SLA is breached

WORKFLOW 4: Change Management

Goal: Open change requests with proper risk assessment.

Tool sequence:

1. search_tickets — find related incidents that justify the change
2. open_change_request with:
   • Description of change
   • Risk level (low/medium/high/critical)
   • Impact assessment
   • Rollback plan
   • Implementation window
3. Link to originating incidents

MUST DO:

• Always include a rollback plan
• Reference originating incidents/problems
• Classify risk honestly — don't downplay to avoid approval gates
• Specify implementation window (maintenance window preferred)

MUST NOT DO:

• Don't open emergency changes without explicit justification
• Don't skip impact assessment

WORKFLOW 5: Knowledge Search

Goal: Find and present relevant KB articles.

Tool: search_knowledge(query: "user's question")

The ITSM server uses TF-IDF scoring to rank results. Present the top match with:

• Article title and relevance score
• Key steps from the article
• Link to full article if available

If no match found, suggest creating a KB article after the issue is resolved.

Cross-MCP Orchestration

ITSM + Slack: Escalation alerts

ITSM: get_sla(ticket_id) → breaching in 30 min
SLACK: slack_send_message(channel: "#it-escalations", text: "🚨 SLA breach imminent: INC-1001 - [subject]. Assigned: [assignee]. Time remaining: 30 min")

ITSM + Email: User updates

ITSM: transition_ticket(id, status: "resolved")
EMAIL: email_send(to: requester, subject: "Your ticket INC-1001 has been resolved", body: "Resolution: [notes]")

ITSM + Notifications: On-call alerts

ITSM: create_ticket(priority: "critical") → INC-1005
NOTIFICATIONS: notification_send(recipient: on_call_id, channel: "push", title: "P1 Incident", body: "INC-1005: [subject]")

Important Guidelines

1. KB-first — Always search knowledge base before creating tickets. 40%+ of issues should resolve from KB.
2. No orphan tickets — Every ticket must be assigned or routed within 5 minutes of creation.
3. SLA awareness — Check SLA status on every ticket interaction. Escalate proactively.
4. Duplicate prevention — The handle_support_request tool detects duplicates automatically. Trust it.
5. Audit trail — Every action is traced. Add notes explaining decisions.
6. Graceful handoff — If you can't resolve, provide the next team with full context (what you tried, what you found).

Troubleshooting

KB returns no results: The knowledge base may be sparse. Suggest creating an article after manual resolution. Try broader search terms.

Ticket routing failed: Check if the target queue exists. Verify the ticket isn't in a terminal state (closed/cancelled).

SLA already breached: Document the breach, escalate immediately, and add a note explaining the delay.

Duplicate detection false positive: If handle_support_request links to wrong ticket, create a new ticket manually with create_ticket and add a note explaining why it's distinct.