Support Ticket Triage MCP

Overview Schema Source Related Servers Discussions Admin

submit_triage_recommendation

Submit a local triage recommendation for a support ticket, capturing evidence-backed decisions without changing the ticket or external systems.

Instructions

Store a local triage proposal without changing the ticket or external systems.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticketId": "<ticketId>",
      "sourceRevision": "<sourceRevision>",
      "category": "<category>",
      "priority": "<priority>",
      "team": "<team>",
      "duplicateCandidates": "<duplicateCandidates>",
      "outageRisk": "<outageRisk>",
      "securityRisk": "<securityRisk>",
      "slaRisk": "<slaRisk>",
      "missingInformation": "<missingInformation>",
      "knowledgeArticleIds": "<knowledgeArticleIds>",
      "draftCustomerResponse": "<draftCustomerResponse>",
      "rationale": "<rationale>",
      "confidence": "<confidence>",
      "recommendedNextAction": "<recommendedNextAction>",
      "actor": "<actor>"
    },
    "name": "submit_triage_recommendation"
  }
}

Input Schema

Name	Required	Description	Default
`tags`	No
`team`	Yes
`actor`	Yes
`slaRisk`	Yes
`assignee`	No
`category`	Yes
`priority`	Yes
`ticketId`	Yes
`rationale`	Yes
`confidence`	Yes
`outageRisk`	Yes
`securityRisk`	Yes
`ticketStatus`	No
`sourceRevision`	Yes
`missingInformation`	Yes
`duplicateCandidates`	Yes
`knowledgeArticleIds`	Yes
`draftCustomerResponse`	Yes
`recommendedNextAction`	Yes

Output Schema

Name	Required	Description	Default
`recommendation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 11, 2026

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotations: it explicitly states that the tool does not change the ticket or external systems, and that the proposal is local. This provides more specific non-destructive behavior than the annotations' destructiveHint=false. It could further disclose persistence or visibility details, but the key context is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that delivers the core purpose effectively without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (19 parameters, 16 required) and the presence of an output schema, the description is too minimal. It does not explain how this tool fits into the triage workflow (e.g., relation to approve/reject), what the parameters mean, or under what circumstances it should be called. The description is insufficient for an agent to correctly select and invoke the tool in context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. However, the description provides zero details about any of the 19 parameters. It mentions 'triage proposal' but does not explain what fields like category, priority, team, or rationale signify, leaving the agent to rely solely on the schema's property names and enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Store') and resource ('local triage proposal'). It also explicitly notes that it does not change the ticket or external systems, which distinguishes it from sibling tools like approve_triage_recommendation and reject_triage_recommendation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through 'without changing the ticket or external systems', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any when-not-to-use conditions. The context is clear but the guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server