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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful provenance — data drawn from the latest FAA MASTER file, the 2020 / Nov 2025 registrant lists, Form 323 ownership — plus the cost signal 'Free.'. Score is held at 3 because it omits important behaviour: what happens when neither of the two optional keys is supplied, whether both may be passed, and what an empty match looks like.

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?

Two long but front-loaded sentences, each keyed to an input branch, with no filler or marketing language. The dense field lists earn their space given there is no output schema to document the return shape. Slightly dense for one sentence, but structurally sound.

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 an undocumented input schema, the description carries the full burden and largely meets it by enumerating returned fields per branch, which is exactly what an agent needs to judge relevance. The remaining gap is the missing rule for supplying zero or both keys. Adequate for a free read-only lookup, though the parameter interaction is left to inference.

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 both parameters are bare strings, and the description does partially compensate by tying call_sign to earth-station/C-band data and n_number to FAA airframe data. That mapping is the main value it adds. However, it never states mutual exclusivity, what precedence applies if both are given, or that both are optional — leaving the 0-required-parameter design unexplained.

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 names the resource (Clearinghouse records) and the two lookup keys, then enumerates the substantive content returned for each: registrant/FRN/control group for a call sign, owner/airframe/registration status for an N-number. This is far more specific than a restatement of the title. It stops short of distinguishing itself from the overlapping sibling aircraft_owner, so it does not reach a 5.

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 usage through its two branches ('for an Upper C-band earth station call sign' vs 'for an N-number'), which tells an agent roughly which key triggers which dataset. But it gives no explicit when-to-use versus when-not-to-use guidance and never mentions the obvious neighbours (aircraft_owner, clearinghouse_precheck, clearinghouse_validate), so an agent facing an overlapping aircraft-owner question has no routing signal.

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