Check the durable delivery state of a submitted support ticket to verify it was accepted and track its processing during outages.
Return the current durable delivery state for a submitted ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | ||
| status | No | ||
| attempts | No | ||
| ticket_id | No | ||
| created_at | No | ||
| last_error | No | ||
| updated_at | No | ||
| external_id | No | ||
| next_attempt_at | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavior on its own. 'Return' clearly indicates a read-only operation, which is helpful, but it does not disclose behavior around invalid ticket IDs, missing tickets, or delivery-state semantics. Still, it gives a basic and accurate behavioral profile.
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?
The description is a single, focused sentence with no filler or redundant restatement. It front-loads the action ('Return') and the target resource, which is ideal for a simple one-parameter tool.
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?
This is a low-complexity tool with one required parameter and an output schema available, so the description need not explain return structure. It covers the essential purpose and resource, with the only notable gap being explicit usage context relative to the sibling submission tool.
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%, so the description should compensate for the single parameter. It adds context that the ticket must already be submitted, which helps explain ticket_id's origin, but it does not specify format, where to obtain the ID, or any constraints beyond what the schema's type and required fields already state.
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 states a specific verb ('Return') and a specific resource ('durable delivery state for a submitted ticket'), making the tool's purpose clear. It is naturally distinguished from the sibling submit_support_ticket by being a read/status operation rather than a submission, though it does not explicitly name the sibling.
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 phrase 'for a submitted ticket' implies this tool should be used after a ticket has been submitted, and the sibling name suggests the alternative creation path. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.