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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the exact payload: a delay share benchmarked against a usual day, a disruption note, a 90-day record, and an external page link. It does not state behavior for an unknown or ambiguous airline name.

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 that lists the returned components in a logical order with no filler. It is dense but every clause carries information; a slight readability cost from being a single long clause.

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 no output schema, the description must explain return values and it does so thoroughly, including the benchmark and the external link. Only minor gaps remain, such as not saying what happens if the airline cannot be resolved.

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 100% and the single 'airline' parameter is documented with concrete examples (KLM, Ryanair, DL), so the schema does the heavy lifting. The description only implies the parameter is airline-level via 'its departures'; it adds no format or matching rules (e.g. case sensitivity, code vs name) beyond the schema.

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 gives a specific verb-like framing ('How an airline is running today') and enumerates the exact metrics returned: share of departures expected 15+ minutes late vs a usual day, disruption notes, and a 90-day on-time record. That clearly separates it from the flight-level siblings check_flight and flights_between, though it never names them explicitly.

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?

Usage is only implied: the phrase 'how an airline is running today' signals an airline-level aggregate rather than a single flight, which is the natural contrast with check_flight. There is no explicit 'use this when...' or 'for a specific flight use check_flight instead' guidance.

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