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

With no annotations, the description carries the full disclosure burden and does well: it states the data is live/current, that FAA coverage is limited to U.S. airports while weather is global, and that some restrictions are private-aircraft-only and labeled as such — all behaviorally relevant. It does not cover failure modes such as invalid or non-U.S. airport codes, so it is not exhaustive.

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?

Two sentences, front-loaded with the returned content, then coverage scope, then the exclusion. The parenthetical about private-aircraft restrictions is the only dense bit and it carries real information, so nothing is wasted.

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 single-parameter read tool with no annotations and no output schema, the description adequately previews the return payload (delays, ground stops, GDPs, closures, plain-language weather, delay-risk rating). Remaining gaps — error handling for unknown codes, response shape details — are minor for this tool class.

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 there is only one parameter ('airport', documented as IATA or ICAO code), so the schema already does the work. The description adds no format hints, examples, or edge-case guidance beyond that, making the baseline 3 appropriate.

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 verb-like framing ('Airport status right now') and then enumerates exactly what is returned: live FAA delays, ground stops, ground delay programs, closures, current weather, and a delay-risk rating. The 'right now' framing and 'Not for flight planning' clause separate it from the sibling travel_airport_forecast without needing the schema.

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 a clear negative boundary ('Not for flight planning') and states data scope per source (FAA covers U.S. airports, weather covers worldwide), which tells the agent when the result will be partial. It stops short of naming the alternative sibling (e.g. travel_airport_forecast) for future-looking queries, so routing is implied rather than explicit.

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