airport_activity

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

With no annotations present, the description carries the full burden of disclosing behavior. It explains that buckets are inferred from position and climb/descent rate, that no schedule/gate/destination knowledge exists, and that nearby-airport misattribution is possible. This is substantial behavioral transparency, though it does not mention output format, freshness, or rate limits.

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 compact, front-loaded with the core concept, and every sentence adds useful context. The structure flows naturally from definition to inference behavior to caveats, with no wasted words.

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?

The description does a good job of explaining the tool's behavioral model and limitations, which matters because there is no output schema and no annotations. However, it omits explicit parameter semantics and does not clearly state when to choose this over sibling tools, leaving an agent with some ambiguity in real selection scenarios.

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 0%, so the description must explain the parameters, but it only implies 'nearby' and 'airport' without defining `icao` or `radius_nm`, including units, defaults, or behavior. The agent is left to infer that `icao` identifies the airport and `radius_nm` controls the search area, which is a significant gap at this coverage level.

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 clearly states what the tool does: it reports what is moving around an airport right now, observed rather than scheduled, and groups aircraft into departing, arriving, on the ground, and overflying. It also explicitly differentiates itself from a departure board, making its purpose and scope immediately clear.

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 gives practical usage context by emphasizing that this is observed activity, not scheduled information, and warns about misattribution near multiple airports. It does not explicitly name alternative tools or give a direct when-to-use sentence, but the limitations and exclusions effectively guide the agent's choice.

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