Will my flight be delayed?

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.

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

Goes well beyond the read-only/idempotent annotations: enumerates the verdict vocabulary, lists the returned fields (expected times, reasons, cancellation chance, post-departure lateness and landing), and instructs the agent to surface the willmyflightbedelayed.com link because that page updates over time. That last point is genuine behavioral context an agent could not derive from structured fields.

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?

Three front-loaded sentences with no filler; the output contents are stated before the advisory about the link. Slightly dense in the first sentence but each clause carries information.

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 carries the return-value burden and does so fully: verdict scale, timing fields, reasons, cancellation chance, and post-departure state. Nothing an agent needs to call it or relay results correctly is missing.

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%, so both parameters are already documented. The description only adds a forecast-horizon nuance ('today or tomorrow'), which actually sits slightly in tension with the schema permitting arbitrary YYYY-MM-DD dates, so it adds little and could mildly confuse.

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 resource and verb: a delay/cancellation forecast for ONE flight number, today or tomorrow. The explicit 'one flight number' scope distinguishes it from route-level siblings like flights_between and carrier-level ones like airline_status without needing to name them.

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?

Gives clear context for when the data applies (today or tomorrow, and that it becomes retrospective after departure). It does not explicitly name the alternatives or say when NOT to use it, so an agent must infer routing from scope alone.

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

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

Annotations already declare a safe, read-only, idempotent, non-open-world operation, so the lower bar applies. The description adds useful return behavior: up to 10 results, soonest first, each with a delay forecast and a willmyflightbedelayed.com page link. It does not discuss rate limits or authentication, but for a public read tool that is not a major gap.

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 front-loaded and compact: it states the resource and scope, then the usage condition, then the output instruction. Every sentence adds practical guidance with no filler.

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?

There is no output schema, but the description clarifies that results include delay forecasts and page links, plus the 10-item cap and soonest-first ordering. Combined with full schema parameter coverage and read-only annotations, it is complete enough for an agent to call correctly; only explicit sibling routing language is slightly light.

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 all three parameters are documented in the input schema, so the baseline is 3. The description mentions route inputs and today/tomorrow but does not add syntax or constraints beyond what the schema already provides, aside from the result limit and ordering.

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 names a specific resource and scope: flights between two airports or cities for today and tomorrow, each with a delay forecast and a page link. It distinguishes route-based lookup from flight-number lookup by saying to use it when the user knows the route but not the flight number, though it does not name the sibling tools directly.

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 explicitly says to use this when the user knows the route but not the flight number, and it instructs the agent to give the user the links. It does not name check_flight or airline_status as alternatives, nor does it spell out exclusions beyond the flight-number distinction.

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