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

Goes well past the annotations: it discloses an explicit privacy boundary ('never owner names or addresses'), the persistence contract (returns an enrichment_id that get_underwriting_enrichment re-serves exactly later — consistent with readOnlyHint=false), the 2.5s activity_risk wait semantics, and the strict 1–10 condition scale. This is materially more than the annotations convey.

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?

One dense but front-loaded paragraph; the highest-value clause (what is returned) leads and the input path and tier gate close. The long semicolon-delimited inventory is efficient, though the single-sentence block is heavier than it needs to be for scanning.

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?

For a 7-parameter, nested-object tool with an output schema, the description supplies the input contract, privacy limits, timing behavior, persistence, and tier gating. Nothing an agent needs to invoke it correctly is missing, and return-value detail is legitimately delegated to the output schema.

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 coverage is already 100% (baseline 3), but the description adds meaning: the calibrated range semantics ('likely = 68%, outer = 90%'), that insured_value specifically 'Adds hull_value_check', the back-to-1960 as_of_date window, and the OR relationship between registration and make_model_id + year.

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?

Specific verb + resource + full payload scope: 'Everything an aviation underwriter checks about one aircraft, in one call' followed by an enumerated list (value with calibrated ranges, registration record, airworthiness context, ADS-B activity). An agent can distinguish this from lookup_aircraft, value_aircraft, or search_aircraft 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?

States the two accepted input modes ('tail number OR make_model_id plus aircraft_info.year') and a hard access constraint ('Fleet Command and Enterprise API tiers only'), and points to get_underwriting_enrichment for later re-retrieval. It does not, however, say when to prefer this over the sibling enrich_hull_schedule or the lighter lookup_aircraft, so alternatives are only partially addressed.

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