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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavior beyond that: it explains response shape per status, including that paid bookings carry ticket_url, ticket_pdf_url, and optional wallet URLs. This clarifies what the caller can expect without overpromising.

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 dense sentence that front-loads the core statuses before diving into URL details. Every clause adds value about possible response content, though the sentence is slightly long and could be split for easier scanning.

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 read-only status tool with an output schema, the description covers the important response variations and special URL semantics. It does not mention the required booking_uuid or the locale default, but those are either visible in the schema or inferable from the tool name, making the definition reasonably complete.

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 only 50%, with booking_uuid undocumented in the schema and the description providing no parameter-level meaning beyond the tool's purpose. The locale parameter is covered by the schema but the description does not compensate for the missing booking_uuid semantics, and the booking_uuid's role must be inferred from the tool name.

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 what the tool returns: the current status of a booking, with enumerated possible values. It distinguishes this as a status-read operation, separate from siblings like hold_tickets or set_contact, without ambiguity.

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 read-only 'current status' framing implies this is the tool to call for checking a booking's state, but it does not explicitly state when to prefer it over alternatives such as recover_tickets or wait_for_payment. No exclusions or alternative routing is provided, so the guidance is only implied.

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