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

Beyond the readOnly/idempotent/openWorld annotations, it discloses keyless auth, a daily-refreshed public-domain bulk source, a data_as_of freshness stamp on every response, and the precise privacy behavior (individual registrant names withheld, deregistered records never return a name and why). This is exactly the extra behavioral context annotations cannot carry.

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?

Core purpose and input format are front-loaded, and the output fields are listed compactly. The registrant-name explanation runs to two long clauses about why deregistered records lack registrant-type data, which is useful but slightly over-elaborated for a lookup tool.

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 must explain returns itself, and it does — enumerating returned fields, the freshness stamp, and the registrant-name caveats. Nothing an agent needs to call or interpret this keyless read correctly is missing.

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?

With 100% schema description coverage, the schema already documents the single n_number parameter, and the description's format guidance (with/without leading N) largely mirrors the schema's own examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (look up) and resource (US aircraft tail number in the FAA civil aircraft registry) and enumerates the exact fields returned. An agent can distinguish this from every sibling (research, market, competitor-scan tools) without opening any schema.

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 concrete invocation guidance — the N-number may be supplied with or without the leading "N" — and clarifies the registrant-name limitation context so the agent knows what output is and isn't obtainable. It stops short of naming when NOT to use it or pointing to an alternative, so not a 5.

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