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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond those: it is a polling endpoint, defines the three states (pending, completed, expired), specifies a 7-day expiration, and notes it is free. No contradiction exists; the description enriches the annotations rather than repeating them.

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 entire description is a single, well-structured sentence that leads with the cost ('Gratis'), immediately names the action, and compactly lists all possible states with their meanings. Every clause carries essential information; there is no filler or redundancy.

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 simple two-parameter polling tool, the description covers the lifecycle states, expiration, and the ticket origin. An output schema exists to document the return structure, and annotations handle safety/idempotency. The only minor gap is the absence of guidance on polling frequency or error handling, but these are not critical given the tool's simplicity.

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 100% and both parameters (ticket, resultToken) have descriptive definitions. The description references them indirectly through 'created with ask_human_verdict' but does not add additional semantic detail such as formats, validation rules, or relationship nuances beyond what the schema already provides. Per the calibration rule, with full schema coverage the baseline score of 3 is appropriate.

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 clearly states a specific action: 'Pollea el estado de un ticket creado con ask_human_verdict' (polls the status of a ticket created with ask_human_verdict). It also enumerates the possible statuses (pending, completed, expired), making the tool's purpose unambiguous and distinguishing it from its sibling ask_human_verdict, which creates the ticket.

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 ties the tool explicitly to tickets from ask_human_verdict, which implies when to use it: after creating a ticket with that tool. It doesn't explicitly say 'use this after ask_human_verdict' but the relationship is clear. Since there is only one sibling, no alternative comparison is needed, though adding a note like 'use after ask_human_verdict' would be slightly more explicit.

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