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

Annotations only declare readOnly/openWorld/non-destructive. The description adds substantial behavioral context the annotations cannot: it is a CURRENT-roster monthly snapshot of a daily-updated FAA file, snapshot_date staleness implies deregistration, deregistered history is a planned (not yet available) follow-up, and results are FAA records republished verbatim rather than inferred. These disclosures directly shape how an agent should interpret and caveat results.

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?

Content is front-loaded: what it returns first, then use cases, then lookup semantics, then caveats. Most sentences earn their place given nine parameters and no output schema. It is somewhat over-long and includes mildly editorial framing ('Pure-publisher posture ... parsed by KeyVex'), plus a stray hyphen in 'Deregistered- aircraft', but nothing that obstructs use.

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, the description carries the full return-value burden and does so: it enumerates the aircraft and registrant fields, the five-co-owner cap, the FAA type-code legend, and the snapshot/staleness semantics. Combined with 100% parameter coverage and read-only annotations, an agent has everything needed to call and interpret this tool.

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 baseline is 3 and the schema already documents all nine parameters (including n_number's N-prefix tolerance and registrant_name's co-owner matching). The description reinforces those semantics and adds interpretive nuance for registrant_name — that a missing company match does not disprove ownership — which meaningfully aids filter choice.

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 first sentence names a specific verb+resource ('Returns FAA aircraft registrations') and quantifies scope (~314K US-registered aircraft, one record per N-number). It further enumerates exactly what a record contains (aircraft attributes and registrant details), so the agent knows precisely what it is getting and can distinguish it from any sibling in this large tool set.

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 an explicit enumeration of triggering user intents: 'who owns an aircraft (by N-number), what aircraft a company / person / nonprofit registers, corporate-jet fleets, aircraft registered in a state, or to join tail numbers seen in flight-tracking data to owners.' It also supplies a crucial when-interpreting caveat (trustee-bank and management-LLC registrations mean an absent company name is not proof of no ownership). No sibling overlaps, so no alternative needs naming.

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