fa_get_nearby_airports

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no behavioral context beyond the annotations—it does not mention pagination, response shape, rate limits, or that results may be incomplete due to the openWorldHint. Since annotations already provide the core safety signal, the description misses the opportunity to add value (e.g., that results are paginated via cursor or capped by max_pages). This is a notable gap for a tool with 7 parameters.

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 a single, unambiguous sentence without any filler. It front-loads the core purpose and includes the key constraint (statute miles). Every word earns its place, and there is no redundancy with the schema or annotations.

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 and a tool that could return complex paginated results (cursor, max_pages, view), the description is too minimal. It does not mention the response shape (e.g., list of airport objects), pagination behavior, or anything about the optional parameters. An agent cannot infer that results are paged or that 'view' affects field richness without opening the schema. The description covers only the primary intent, leaving out critical context for correct invocation.

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 every parameter already has a description (including radius, latitude, longitude, and the optional view/cursor/only_iap/max_pages). The tool description adds no meaning beyond the schema; it does not explain relationships between parameters, like that max_pages and cursor are used together. Per the calibration rule, with high coverage, a baseline of 3 is 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 states a specific verb ('Find'), a resource ('airports'), and the key scoping criteria (near a latitude/longitude within a radius in statute miles). This clearly differentiates it from sibling tools like fa_get_airport (single lookup) or fa_list_airports (potentially broad list) by tying the search to a geographic proximity query.

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 it (when a location-based search for airports is needed) but does not explicitly state alternatives or exclusion conditions. It does not mention that fa_list_airports or fa_search_flights are not the right choice, nor does it note preferences such as 'use this instead of fa_list_airports when you have coordinates'. This is adequate for a simple, obvious use case but lacks explicit routing guidance.

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