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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it defines the three status values, ties them to list_matches' vocabulary, explains status_as_of as 'when we LOOKED', and warns there is no live check. This is exactly the freshness/liveness semantics an agent needs to interpret results correctly.

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?

Front-loaded with the return shape, then the status vocabulary, then the usage note. Dense but every sentence carries meaning; only minor tightening is possible.

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?

With an output schema present, the description need not explain return values, yet it adds the status semantics and liveness caveat that make the output interpretable. It is complete for invocation, with the only gap being the unclear relation to the get_alert sibling and the alert-vs-itinerary naming.

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 the single parameter is documented in the schema (its id comes from list_my_itineraries or create_itinerary). The description adds no parameter-level detail, so the baseline 3 applies.

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 precisely what the tool returns: one route with per-night legs, each night's zone, and openings with statuses. It is clearly singular and distinguishable from the list_* siblings, though the verb is implicit (a noun-phrase return description) and the title's 'route alert' wording sits awkwardly against the itinerary_id parameter.

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?

It gives explicit context for use — 'This is how to answer "is it still available" — there is no live check' — which tells the agent exactly when this tool is the right call. It does not, however, name exclusions or contrast with the retrieval sibling get_alert, so alternatives remain unaddressed.

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