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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing that each returned figure carries measurement provenance and timestamp — useful for an agent deciding whether to trust the numbers — though it does not state coverage gaps, freshness limits, or what happens for unsupported airports.

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?

One front-loaded sentence capturing resource, granularity, scope, and output provenance, followed by a compact args clause. No filler, no restatement of the title, and the essential scoping information comes first.

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 a single required parameter, a 0%-coverage schema, a declared output schema, and rich read-only annotations, the description supplies nearly everything needed: what it returns, provenance, and the identifier format. The only missing piece is guidance on when to prefer this over the adjacent border_wait or airport_conditions tools.

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 0% and the schema only declares a bare string, so the description is the sole source of parameter meaning. 'airport = IATA or ICAO code' usefully constrains the accepted identifier format, which the schema does not. It stops short of showing example values or case/format rules (e.g. 'JFK' vs 'KJFK').

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?

States a specific verb+resource+granularity: security checkpoint wait times, broken down by checkpoint, scoped to an airport. It is clearly distinguishable in substance from the sibling border_wait (security vs. border), but it never names that sibling or explicitly disambiguates itself from it, so differentiation is implicit rather than stated.

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 when-to-use guidance at all: no conditions, no prerequisites, and no routing to alternatives such as border_wait or airport_conditions. The phrase 'with how each figure was measured and when' describes output characteristics rather than usage context, so an agent must infer when this tool is the right pick.

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