fa_get_airport

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the accepted code formats (ICAO/IATA/LID), which is useful. The view parameter description in the schema adds rich behavioral context about response shapes (compact vs full, what gets stripped). The description itself doesn't add much beyond the schema, but the schema's view description is part of the tool definition and provides strong behavioral transparency. Since the description doesn't contradict annotations and the schema carries the behavioral load, a 4 is appropriate.

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 sentence, front-loaded with the verb and resource, and the parenthetical about code formats is efficient. Every word earns its place. The schema's view description is verbose but that's in the schema, not the description.

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 simple read-only lookup tool with 2 parameters, 100% schema coverage, and readOnlyHint=true, the description plus schema is nearly complete. The only minor gap is that the description doesn't mention what the response contains (e.g., airport name, location, timezone), but with no output schema and the openWorldHint, the agent can infer the response from the 'details' wording. A 4 is appropriate; a 5 would require explicit mention of return fields or when to prefer this over fa_resolve_airport.

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%, so the schema already documents both parameters thoroughly. The description adds the accepted code formats (ICAO/IATA/LID) which reinforces the id parameter semantics. The view parameter has an exceptionally detailed schema description explaining the difference between compact and full, including what gets stripped. The description doesn't need to add more because the schema does the heavy lifting. Baseline 3, but the description's explicit mention of code formats adds a small increment.

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 a specific verb ('Get details'), a specific resource ('airport'), and the exact identifier formats accepted (ICAO, IATA, LID). It clearly distinguishes this from sibling tools like fa_resolve_airport or fa_list_airports by focusing on fetching details for a single airport by code.

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?

The description implies when to use this tool: when you have an airport code and need details for that specific airport. It doesn't explicitly name alternatives or exclusions, but the sibling list shows many other airport tools (e.g., fa_get_airport_flights, fa_get_airport_delays) and the description's focus on 'details for an airport by code' provides clear context. A small deduction for not explicitly saying 'use fa_resolve_airport if you need to resolve a code to an airport' or similar.

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