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

With no annotations provided, the description fully discloses behavior: it costs 100 credits, requires Authorization and sufficient balance, uses a specific data source, and clearly states limitations (only the Part 77 200ft threshold, not airport-specific lower heights). It also describes the return JSON structure, making the tool's behavior highly transparent.

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 and information-dense, delivering cost, use case, source, threshold, limitations, auth requirements, and return format in a few sentences. Every sentence earns its place; there is no fluff or repetition.

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?

Given the tool's moderate complexity (3 params, no annotations, output schema present), the description is remarkably complete. It covers inputs (implicitly), outputs (explicitly), cost, authentication, data source, and limitations, leaving little for the agent to guess.

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 compensate for parameter meanings. It explains proposed_height_agl_ft and its role in triggering FAA notification, but it never explicitly describes the required 'lat' and 'lon' parameters, leaving the agent to infer that 'US point' maps to these. This is a significant gap for the two required parameters.

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 identifies the tool's purpose: to assess nearby FAA-registered vertical obstructions at a US point for telecom/tower-siting due diligence. It uses specific verbs and examples ('is there anything tall already near this proposed tower site'), and it distinguishes itself from sibling tools by focusing on airspace obstruction proximity with a specific source (FAA Digital Obstacle File).

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 provides clear context for when to use the tool (telecom/tower-siting due diligence) and includes a concrete example. It also states an exclusion: it only flags the 200ft AGL notification threshold and is not a full aeronautical study, nor does it check lower heights near airports. It does not explicitly name alternative tools, but the guidance is sufficient.

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