Recommends whether a customer support ticket needs human escalation by evaluating SLA breach status and priority. Helps agents decide when to escalate while making no changes itself.
Heuristic escalation recommendation for a ticket, based on SLA breach status and priority. Read-only — recommends whether a human should escalate; does not escalate anything itself.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden Diamonds. It explicitly states the operation is read-only and advisory, and that no escalation action is performed. It does not describe the output shape or error behavior, but for a simple heuristic recommendation tool the key side-effect transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full purpose, basis, and read-only nature of the tool with no wasted words. The core action is front-loaded, and the clarifying side-effect statement is placed immediately after.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description is mostly complete. It explains what the tool does, what it is based on, and that it is read-only. However, it does not specify the exact return value format, which would be helpful when no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only refers to 'a ticket' without explaining the ticket_id format, source, or validity requirements. The parameter name and schema title are self-explanatory, but the description adds no meaningful parameter guidance beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('recommends') and clearly names the resource (escalation for a ticket) and the decision criteria (SLA breach status and priority). It also distinguishes itself from action-oriented siblings by explicitly stating it does not escalate anything itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need an escalation recommendation for a specific ticket based on SLA and priority. The explicit 'read-only' note and 'does not escalate anything itself' imply it is not for performing escalations, but no alternative tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.