Create a manual ticket for a specific agent using a QA comment that becomes the ticket title. Use it to log follow-up tasks or issues tied to an agent.
Create Manual Agent Ticket
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| qa_comment | Yes | What the ticket is about, e.g. a follow-up task for the agent. This is shown as the ticket title. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the agent knows this is a non-idempotent write. The description adds nothing beyond that — no mention of side effects, required permissions, or what a 'manual' ticket means versus an auto-created one. With annotations carrying the safety profile, a low score reflects the complete absence of added behavioral context.
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 single fragment is short but not concise in any useful sense — it is under-specification, not economy. There is no front-loaded scope or actionable content for the agent to act on.
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 mutating, non-idempotent ticket-creation tool with no output schema and only 50% schema coverage, the description provides nothing: no return behavior, no relation to the other ticket routes, no note on what 'manual' implies. An agent cannot safely place this call from the definition alone.
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 coverage is 50%: qa_comment is documented but agent_id has no description in either schema or description text. The description supplies no parameter meaning at all, so it fails to compensate for the undocumented agent_id. Baseline 3 is not reachable given the coverage gap.
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 'Create Manual Agent Ticket' is a verbatim restatement of the tool name, offering no scope, object, or distinguishing detail. It does not differentiate this tool from near-identical siblings such as create_agent_conversation_ticket_route or create_agent_response_test_route. This is a tautology rather than an explanation.
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?
There is no indication of when this tool should be used versus alternatives, nor any prerequisite or context. The crowded 'ticket' sibling family makes this omission costly. No misleading claim is made, but no guidance whatsoever is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.