Windsock

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the accepted reference kinds, but does not disclose what openWorld implies (e.g. external link fetching/validation) or any auth requirements.

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 compact sentences, front-loaded with the action and its purpose, then the parameter contract. No filler, though the enum listing could be tightened.

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?

An output schema exists so return values need not be described, and annotations cover the mutation safety profile. Still missing: whether the referenced section/page/URL must already exist, label semantics, and any idempotency or duplicate-citation behavior.

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 and it partially does: it enumerates the kind enum values and defines what 'reference' holds for each kind. However report_id, item_id, and label remain completely undocumented in both schema and description.

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?

States a specific verb and resource ('Attach a citation to a diligence item') plus the purpose ('substantiating its status'), so an agent can tell this apart from add_diligence_comment or add_diligence_item. It stops short of explicitly naming those siblings as alternatives.

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 phrase 'substantiating its status' implies when you would cite evidence, but there is no explicit when-to-use vs. when-not guidance and no mention of prerequisites such as the item existing or whether duplicate citations are allowed.

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

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

With annotations declaring readOnlyHint=false, openWorldHint=true, and destructiveHint=false, the description usefully adds that comments are attributed to the caller and appear in the item's living thread — context beyond the structured fields. It stops short of noting permission requirements or editability of posted comments.

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 tight sentences with the action front-loaded and no filler; the parenthetical examples add information rather than padding.

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?

The existence of an output schema means return values need not be explained, and annotations carry the safety profile. However, with two of three parameters undocumented and no guidance on report_id/item_id linkage, the description is adequate but leaves clear gaps for a mutation 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 only 33%: item_id and report_id have no descriptions at all. The description obliquely implies item_id via 'checklist item's thread' but says nothing about report_id or the relationship between the two identifiers, so it does not compensate for the coverage gap.

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?

States a specific verb (Post a comment) and a specific resource (a diligence checklist item's thread), which cleanly distinguishes it from siblings such as add_diligence_citation, add_diligence_item, or update_diligence_item. An agent can identify the operation without opening the 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?

Provides illustrative content types (rationale for a pass/fail, a question, a finding), which implies when this tool is appropriate, but never states explicit conditions, prerequisites, or alternatives such as add_diligence_citation. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/safety profile is covered. The description adds a genuine behavioral detail beyond annotations: the checklist is auto-created on first use, which affects agent expectations. Auth and duplicate-handling behavior remain undocumented.

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 sentences, front-loaded with the action and followed by parameter intent. Tight and largely waste-free, though the parenthetical 'accepted-suggestion' phrasing is slightly informal.

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?

An output schema exists so return values need not be described, and annotations cover safety. For a 7-parameter mutation tool at 0% schema coverage, the description is fairly complete but leaves report_id and the source enum unaddressed.

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 0%, so the description must carry the burden. It documents title (required), category, guidance, critical, and value_impact {min,max}, but omits the required report_id and the source enum (user/rag), leaving two of seven parameters 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?

States a specific verb+resource: adding a checklist item to a report's diligence checklist, and clarifies the item can be custom or from an accepted suggestion. This distinguishes it from add_diligence_citation and add_diligence_comment by resource, though it does not explicitly contrast with those add-type siblings.

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?

Usage is implied ('custom or accepted-suggestion item') but there is no explicit when-to-use guidance or routing to alternatives like generate_diligence_checklist or get_diligence_suggestions for bulk sourcing. The agent must infer the appropriate context.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, which leaves unexplained why a seemingly analytical tool is not read-only and what it persists or writes. The description adds nothing about side effects, cohort selection behavior, or whether results are stored. With annotations already carrying the safety profile, the description should have clarified the non-read-only behavior but does not.

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 tight sentences, front-loaded with the behavioral claim before the use-case rationale. No filler, though the second sentence is a list of audiences rather than operational information.

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?

An output schema exists, so return values need not be restated, and the tool is a single-model analysis with no nested objects. However, the undefined cohort-selection path (make_model_id vs registrations) and the unexplained non-read-only annotation leave meaningful gaps for correct invocation.

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 67%, with 'registration' documented and 'registrations' described as explicit cohort tails, while 'make_model_id' is undocumented in both places. The description alludes to a 'comparable cohort' but never explains how make_model_id vs registrations determines that cohort, so it adds little beyond the schema.

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+resource: it characterizes how an aircraft is flown across seven usage categories relative to a peer cohort. That is concrete and distinct from generic aircraft-lookup siblings. It stops short of differentiating itself from the closest sibling (assess_flight_activity_risk) or naming its own output.

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 downstream contexts ('appraisal narratives, insurance underwriting, validating seller claims'), which implies when the result is useful, but offers no explicit when-to-use/when-not guidance and never names an alternative tool. An agent still has to infer the trigger conditions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that this is a probabilistic, forward-looking projection over a defined ~180-day window rather than an observed measurement, but says nothing about data sources, latency, or confidence/precision.

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 tight sentences with the core computation front-loaded and the application list secondary. No filler, though the application clause is somewhat promotional rather than operative.

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?

An output schema exists, so return values need not be explained, and the description adequately conveys what the number means and its time horizon. Remaining gaps are minor: input format for registration and the source of the underlying flight data.

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 50%: as_of_date is documented in the schema while registration is bare. The description echoes the date concept ('as of a given date') but adds no format or semantics for registration (e.g. tail number vs serial), so it does not compensate for the undocumented half.

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?

States a specific computed quantity (forward-looking probability of low flight activity) with an explicit horizon (~180 days) and an as-of reference date, which is far more precise than the title. It does not, however, name or contrast itself with the sibling analyze_flight_usage, leaving the boundary between the two to inference.

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 second sentence names downstream applications (flagging stagnant inventory, prioritizing inspections, risk-scoring collateral), which implies when the tool is relevant. It offers no when-not conditions, prerequisites, or explicit alternative such as analyze_flight_usage for historical activity, so routing guidance is only implied.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description adds substantial behavioral context beyond them: counts are capped by fleet_cap, spec filters exclude aircraft with missing values (with per-field coverage percentages), airworthiness_class is missing for 36% of the fleet, the registry includes ~21.6% international aircraft, and there is no `country` filter because the v3 validator rejects it. These are exactly the operational caveats an agent needs before calling the tool.

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 opening sentence front-loads the core purpose well, but the remainder is very long and re-documents much of what the input schema already covers (filter conditions, location_point format, field enumerations). The data-quality warnings earn their place, yet the prose is dense with repeated schema detail and emoji emphasis, so it is more verbose than necessary.

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?

An output schema exists, so return values need not be fully re-explained, and the description still mentions total_count/state_counts for convenience. Given the tool's complexity, the definition covers the critical traps (fleet_cap limits, sparse spec data, international registrations, missing country filter), leaving nothing essential for correct invocation unstated.

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 schema already documents both parameters and the filter grammar; baseline is 3. The description nevertheless adds meaning beyond the schema: it warns that spec filters (engine_power_hp, useful_load_lbs, engine_make) exclude aircraft with missing values at stated rates, explains union vs AND semantics for make_model_id clauses, lists registration_authority codes and cohort tokens, and clarifies that registration_country replaces the nonexistent `country` filter.

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 states a specific verb and resource: 'Aggregate registry census for a filter set: the total number of matching aircraft plus breakdowns by US state and by build year — in one call, without paging individual tails.' It also explicitly distinguishes the tool from search_aircraft by noting it avoids paging individual tails, so an agent can tell them apart without opening either 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?

The description gives a concrete use case ('Directly answers "how many Cessna R182s are registered in Oregon" (filter make_model_id + state, then read total_count / state_counts)') and says it 'Uses the same filter grammar as search_aircraft,' which implicitly routes agents needing individual records to that sibling. However, it never explicitly states when not to use count_aircraft or names search_aircraft as the alternative for tail-level data, so it falls short of full 5-level when/when-not guidance.

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

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

Annotations only declare readOnly=false, destructive=false, openWorld=true; the description goes well beyond them by disclosing that a durable account-owned report is created, that PDF generation is queued asynchronously, that omitted aircraft_info fields are imputed with the cohort median, and that the response exposes inputs.stats_imputed / inputs.year_imputed. The entitlement prerequisite (PRO/Enterprise) is also surfaced, which annotations cannot 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?

Front-loaded with the purpose, then the durability/PDF behavior, then the imputation warning and the entitlement requirement. Every sentence carries information, though the imputation explanation is compressed into one long clause and the 'same inputs as the windsock.ai valuation wizard' framing adds little for an agent.

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 create-a-durable-artifact tool with 7 nested parameters and an output schema, the description covers what is created, the side effect (queued PDF), the entitlement gate, the imputation risk, and which response fields report imputation. Nothing essential to correct invocation 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?

Schema coverage is 100%, so the schema already documents every field and the baseline is 3; the description still adds genuine meaning by explaining the imputation semantics of omitted aircraft_info fields (filled with make/model cohort median) and by instructing the agent to always send the tail. It stops short of explaining how registration and make_model_id interact beyond what the schema says.

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?

States a specific verb+resource ('Generate a full Windsock verified value report') and scopes it ('contemporary model only'), and the phrase 'Creates a durable report owned by your account and queues PDF generation' implicitly separates it from the ephemeral sibling value_aircraft. It never names value_aircraft or any other sibling explicitly, so the differentiation is inferred rather than stated.

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?

Gives concrete context for use: send the tail plus all known aircraft_info, and notes two hard constraints ('contemporary model only', 'Requires Windsock PRO or Enterprise'). It does not tell the agent when to prefer this over the value_aircraft sibling, leaving the report-vs-instant-valuation choice to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds meaningful context beyond annotations by explicitly calling it a 'soft delete' and noting progress counters are recomputed automatically—behavior a caller would not infer from annotations alone. It could go further on reversibility or authorization, but this is a solid contribution.

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?

A single efficient sentence that front-loads the action and resource, then adds two key behavioral notes in a tight parenthetical and trailing clause. Zero waste.

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 an output schema present, the description needn't explain return values, and annotations cover the safety hints. What remains important—soft-delete semantics and counter recomputation—is provided. Given a 2-parameter mutation tool with low schema coverage, a bit more on ID semantics or error cases would fully complete it.

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% for the 2 parameters (report_id, item_id), so the description must compensate. It names both concepts implicitly—'one item' (item_id) and 'a report's diligence checklist' (report_id)—providing meaning beyond the bare type declarations. However, it doesn't specify ID formats or whether item_id is scoped globally or per report, leaving a gap.

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?

States a specific verb (remove) and resource (a report's diligence checklist item), clearly distinguishing from siblings like add_diligence_item and update_diligence_item. The parenthetical '(soft delete)' further clarifies the operation type. It lacks explicit references to those siblings by name, so it falls short of 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?

No guidance on when to use this tool versus alternatives like update_diligence_item or the checklist-generation tools. There are no stated prerequisites or contexts. The description only describes what it does, not when to invoke it.

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

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.

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description carries real additional weight: it discloses tier requirement, per-aircraft metering, and nuanced calibration caveats for book_total ('ran wide for large mixed books and narrow for books concentrated in one segment') plus which values are excluded. This is exactly the behavioral context an agent cannot infer from structured fields.

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?

Purpose and scope are front-loaded, and every sentence carries information (item shape, book_total behavior, calibration caveats, tier/metering). It is information-dense and slightly long, but no sentence is filler.

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?

An output schema already exists, so return formatting is covered, yet the description still clarifies summary.outside_range directions and the book_total structure with exclusions. Combined with tier, metering, and calibration notes, nothing an agent needs to invoke this 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?

Schema coverage is 100%, and the schema already documents both parameters. The description goes beyond that by spelling out the shape of each item (registration or make_model_id + aircraft_info.year, insured_value, reference) and by explaining what book_total produces and how exclusions surface in book_total.excluded, adding meaning over the terse schema wording.

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?

States a specific verb and resource (enrich a carrier's hull schedule), names the scope (up to 100 aircraft), and explicitly anchors to the sibling enrich_aircraft_for_underwriting. An agent can distinguish this batch tool from the single-aircraft enrichment without opening either 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 clear context for use — running enrichment across a whole schedule rather than one aircraft — and adds tier gating ('Fleet Command and Enterprise API tiers only') and a metering note. It stops short of an explicit 'use this instead of enrich_aircraft_for_underwriting when you have multiple aircraft' routing statement, so it is not a full 5.

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

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

Annotations cover the safety profile (readOnly=true, openWorld=true, non-destructive), lowering the bar. The description adds useful input-composition context (registry + flight patterns + overrides) and the fact that assumptions are optional. It doesn't mention caching, rate limits, or precision/confidence.

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 sentence plus a short benefit clause; the purpose and inputs are front-loaded with zero wasted text.

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?

An output schema exists, so return format need not be explained. Combined with annotations, the description gives enough for correct invocation; only the units/format of override parameters remain unspecified.

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 only 17% (only 'days' documented), so the description must compensate. It enumerates override dimensions (fuel, insurance, hangar, annual hours) that map to undocumented parameters and calls out lookback context, adding real meaning beyond the schema.

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?

Names a specific verb (estimate), resource (cost of ownership for a specific tail), and discloses the data composition (registry data, flight patterns, overrides). Clearly distinguishable from siblings like value_aircraft or analyze_flight_usage.

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?

Explicitly names use cases: pre-buy disclosures and TCO comparisons, which tells the agent when this tool is appropriate. No explicit exclusions or alternative-naming, 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.

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

Annotations already cover read-only, non-destructive, and open-world nature. The description adds significant behavioral context beyond annotations: it explains the registry-scoping default, the rationale (different markets and airworthiness authorities), and the real-world impact (foreign comps not actionable substitutes). It doesn't describe pagination or return format, but the output schema likely covers that.

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 reasonably concise and front-loads the core purpose and default scoping behavior. It includes a specific example that, while helpful, adds length; overall it remains focused and every sentence contributes to understanding.

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 has an output schema, the description needn't explain return values. It covers the key behavioral nuance (registry scoping) and use cases thoroughly. The only minor gap is lack of guidance on the registration parameter format, but for a read-only lookup tool with clear defaults, this is acceptable.

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?

The input schema provides a description for registry_scope that already covers its meaning and default, matching the description's explanation. The registration parameter is required but has no schema description, and the tool description doesn't add any syntax or format guidance for it. With 50% schema coverage, the description doesn't fully compensate, so a baseline 3 is appropriate.

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?

States a specific verb and resource (find comparable aircraft for a given tail) and scopes it to a defined cohort (same make/model and equipment profile). It also names concrete use cases (comp tables, substitute inventory), which clearly distinguishes it from siblings like lookup_aircraft, search_aircraft, or value_aircraft.

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 explicitly states the default behavior (comps stay on the anchor's own register) and provides a clear condition for overriding it (pass registry_scope="all" only when the caller genuinely wants the global fleet). It even includes a concrete example (US Robinson R44 with 14 foreign comps) to reinforce why the default matters, leaving nothing to inference.

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

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

Annotations already declare openWorldHint=true, destructiveHint=false, and readOnlyHint=false, covering much of the safety profile. The description adds that results include uncertainty bands and are bounded to 1-15 day horizons, which is useful output context. It says nothing about data freshness, as_of_date semantics, or any cost/rate behavior though.

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 tight sentences with the core purpose and scope front-loaded and the intended use case second. Every clause earns its place and there is no filler.

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 an output schema present, return values need not be explained, and the annotations carry the safety profile. The remaining gap is the undocumented as_of_date parameter and lack of guidance on default horizon behavior, but for a forecast tool this is largely complete.

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 67%: days_ahead and airport_code are documented in the schema, but as_of_date has no description anywhere. The description reinforces the 1-15 horizon and airport scope, but adds no format or semantics beyond what the schema already states, so the baseline 3 is appropriate.

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?

Names a specific verb (projection/forecast), resource (avgas/jet fuel price), and scope (airport, 1-15 day horizons), which is unambiguous. No sibling tool offers fuel forecasting, so explicit differentiation isn't needed, but the description also stops short of contrasting itself with cost/market siblings like estimate_cost_of_ownership or get_market_metric.

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?

'For trip budgeting and FBO economics' implies the intended context, giving some indication of when it is useful. However, there is no explicit when-to-use versus when-not, no mention of alternatives, and no prerequisites stated, leaving usage to inference.

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

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

Annotations already indicate this is not read-only and not destructive; the description adds two important behaviors beyond that: idempotency (an existing checklist is returned unchanged) and asynchronous background execution. These are substantive and directly influence how an agent should call the tool. No contradiction with the annotations exists.

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 sentences with no wasted words. The primary purpose is front-loaded, followed by the critical idempotency and async behavior, then explicit polling endpoints. Every sentence adds decision-relevant information.

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 one parameter, an output schema, and annotations that already cover the safety profile, the description provides everything needed to invoke the tool correctly: what it does, that it is idempotent, that it runs asynchronously, and where to check status. The inclusion of two polling tool names removes ambiguity about next steps. Nothing required for correct use 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?

The input schema has one required report_id with no description, so schema coverage is 0%. The description does connect the parameter to 'a report,' giving minimal semantic context, and the parameter name is self-explanatory, but the description does not specify the ID's format, source, or constraints. For a single obvious parameter this is adequate but not rich.

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 opens with the specific action 'Generate' and the exact resource: a make/model-specific pre-buy diligence checklist for a report. It also adds meaningful specificity by noting that the research is grounded in real ADs/STCs. This clearly distinguishes it from sibling tools like get_diligence_checklist, add_diligence_item, and delete_diligence_item.

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 operational usage: generation runs in the background)Skip and the agent should poll get_diligence_checklist or get_diligence_progress for status. It also notes idempotency, which helps the agent know that calling twice is safe. It does not explicitly list exclusions, but the async and polling guidance gives strong context for when and how to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, and an output schema covers the return shape, so the bar is lower. The description adds the auth-scoped nature ('the authenticated account's') and that cost is estimated, which is useful context, but says nothing about freshness, caching, or rate considerations.

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 sentences with no waste: the returned data is front-loaded, and the usage cue follows. Every clause carries information.

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 read-only, parameterless tool with an output schema, the description covers what is returned and when to call it. Nothing an agent needs in order to invoke it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool is 4.

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 a specific resource (the authenticated account's tier, quotas, current-month usage, and estimated cost), which is distinct from every sibling tool in the list. It is a noun-phrase enumeration rather than an explicit verb, but combined with the name get_account_usage the behavior is unambiguous.

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?

'Use to check entitlements before firing paid tools' gives a clear trigger condition for calling it. There are no relevant sibling alternatives to exclude, so the only gap is the absence of an explicit when-not clause.

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

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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds real behavioral value beyond them by disclosing the "available is false when no profile exists yet" edge case, which an agent needs to handle a null/empty profile.

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 sentences, front-loaded with the substantive content of the profile and closing with the availability caveat. No filler; only minor tightening possible.

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?

An output schema exists, so return-value documentation is not required, yet the description still orients the agent on what the profile contains and the empty-profile case. For a one-parameter read tool this is sufficient, lacking only sibling differentiation.

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?

There is a single parameter with 100% schema coverage, and the schema description already tells the caller where line_id comes from (list_portfolio_aircraft). The description adds nothing about the parameter, so the baseline 3 for fully documented schemas applies.

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 a specific resource (one portfolio aircraft) and enumerates the profile's contents — weekly flying days vs. seasonal expectation, local/pattern vs. cross-country mix, detected utilisation changes. That is more concrete than a tautology, but it never distinguishes itself from near-neighbours like analyze_flight_usage or assess_flight_activity_risk, so it falls short of 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?

"One portfolio aircraft" implies the line_id scope and the parenthetical in the schema points to list_portfolio_aircraft, and the availability caveat gives some context. However, there is no explicit when-to-use vs. when-not guidance, and no routing away from the similar read tools in the sibling list.

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

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

Annotations already establish readOnly, non-destructive, open-world reads. The description adds real behavioral context beyond them: results are grouped into episodes keyed by the question they answer, ranked alert/warn/info/history, each with sources, and pre-acquisition records are also returned. It omits pagination/volume limits or latency expectations.

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?

Effectively one rich sentence plus a short supplement, front-loaded on resource and scope with the grouping/ranking detail following. No filler, though the parentheses list is slightly dense.

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?

An output schema exists, so return values need not be enumerated, yet the description still conveys result structure and the inclusion of pre-acquisition records. Combined with annotations and a fully documented single parameter, an agent has everything needed to invoke it correctly.

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?

Only one parameter and schema description coverage is 100%, with the schema itself pointing to list_portfolio_aircraft as the source of line_id. The description adds no syntax or format detail beyond that, so the schema does the heavy lifting as expected.

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?

States a specific verb (get) and resource (web findings for one portfolio aircraft), then enumerates the content types (for-sale posts, rental/charter use, accident reports) and how results are organized. The scope is clearly per-aircraft and scoped to the portfolio, which separates it from generic search tools like search_reports.

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 the workflow by tying the call to a portfolio aircraft and the schema ties line_id to list_portfolio_aircraft, so an agent knows the prerequisite step. It does not, however, name a sibling alternative or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and external-data profile is covered. The description adds that both current and forecast products are returned, but says nothing about latency, data freshness, or behavior when an ICAO ident is unknown. With annotations carrying the behavioral burden, a 3 is appropriate.

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?

A single tight sentence that front-loads the resource and the two data products. Every clause earns its place with no filler.

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?

An output schema exists, so return values need not be explained, and the single input parameter is well documented. What remains missing is error behavior for invalid idents and any freshness caveat for METAR/TAF data.

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 100% and the schema already documents the single ident parameter with an example. The description only mentions 'ICAO/ident', adding no format, casing, or lookup details beyond the schema. Baseline 3 applies 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?

States a specific verb (get) and resource (airport weather) and disambiguates scope by naming both data products, METAR and TAF. No sibling in the list covers weather, so the tool is instantly recognizable as distinct from the aircraft/market/diligence tools.

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 phrase 'for trip planning context' implies when this is useful, but there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. Usage is implied rather than stated.

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

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

Annotations already convey readOnly, openWorld, and non-destructive behavior. The description adds meaningful behavioral context by explaining the average-catalogue-price-plus-wholesale-factor structure and the exact calculation formula, which goes beyond what annotations alone provide. No contradictions with annotations.

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 efficiently front-loaded: it defines the map, gives the formula, and names the companion tool in three sentences. Every sentence earns its place with no filler or redundant restatement of the title.

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 zero-parameter, read-only map with an output schema, the description is complete: it explains what the map represents, how to perform the wholesale calculation, and how to integrate with search_avionics. No critical operational context 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?

The tool has zero parameters and 100% schema description coverage, so there is no parameter burden for the description to carry. The baseline for a zero-parameter tool is 4, and the description adds no unnecessary parameter details.

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 precisely identifies the tool as an avionics-id-to-price map used for equipment-adjusted valuations, with a clear formula for computing wholesale value. It distinguishes itself from search_avionics, whose role is resolving text to ids, and from value_aircraft by focusing specifically on the panel-price map.

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 gives concrete usage guidance: use this map to value an aircraft's panel from avionics ids, and pair it with search_avionics for text-to-id resolution. It does not explicitly name exclusions or contrast with value_aircraft, but the workflow is clear enough for an agent to select the tool correctly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: it returns an exists:false shape rather than erroring when nothing has been generated, which is exactly the kind of non-obvious outcome an agent needs.

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 sentences, front-loaded with the action and the returned content, with the edge case and its remedy in the second. No filler.

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?

Output schema and annotations are rich, and the description covers the key non-happy-path (exists:false) plus the remedy. The only shortfall is the absent report_id semantics, which is minor for a one-parameter read.

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 schema does not document report_id at all; the description only implies it by saying "for a report." With a single, largely self-evident identifier this is adequate, but it adds no format, sourcing, or lookup detail.

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?

States a specific verb and resource ("Fetch the pre-buy diligence checklist header for a report") and enumerates what the header contains (generation status, progress counters, knowledge score). It does not, however, distinguish itself from the sibling get_diligence_progress, which plausibly overlaps on the progress-counter content.

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?

Gives a concrete conditional path: if no checklist exists, call generate_diligence_checklist instead. That is real routing guidance, though it never contrasts this tool with get_diligence_progress or list_diligence_items for the case where a checklist does exist.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds only the payload contents, which the output schema already documents, and does not mention permissions, rate limits, or side effects. It is consistent with annotations but offers little beyond structured fields.

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 tight sentence with the verb and resource front-loaded. The field enumeration is slightly redundant given the output schema, but the description remains efficient and easy to scan.

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?

A simple read tool with annotations covering safety and an output schema covering returns, so the description needn't explain those. However, the sole required parameter is undocumented in both schema and description, and there is no usage guidance relative to siblings, leaving avoidable ambiguity.

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% and the single required parameter report_id has no schema description. The phrase 'for a report's' gives a weak hint that the parameter identifies a report, but it never names report_id, states that it is required, or gives its format.

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 'Fetch' and resource 'gamified progress payload for a report's diligence checklist', with enumerated metrics (percent complete, knowledge score, counters by state, critical-items-verified, auto-verified count). It implicitly separates itself from sibling get_diligence_checklist by being a progress summary, but it never explicitly names or contrasts any sibling.

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?

No indication of when to use this versus get_diligence_checklist or list_diligence_items, no prerequisites, and no exclusions. Usage is only implied by the tool name and purpose statement.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond that: results are real AD/STC records plus anonymized buyer-sourced items, and it flags that nothing is persisted until add_diligence_item is called. Return format is left to the output schema.

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 sentence describing the content of the suggestions, followed by a short actionable instruction. The purpose is front-loaded and nothing is wasted, though the single sentence is slightly list-heavy.

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 read-only suggestion tool with an output schema that carries the return shape, the description supplies the essential missing pieces: what the suggestions contain, their provenance, and the next step. Only the report_id semantics remain underspecified.

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?

There is a single required parameter (report_id) at 0% schema description coverage. The description implicitly ties it to 'a report's diligence checklist', making its meaning evident, but it never states the expected identifier format or where to obtain it. With one mostly self-evident parameter, this is adequate but not additive.

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 (suggest) and resource (additional pre-buy checklist items) and spells out exactly what the suggestions are drawn from: real Airworthiness Directives / STCs for the make/model not yet on the checklist, plus anonymized items other buyers added for similar aircraft. This distinguishes it clearly from siblings like generate_diligence_checklist and search_airworthiness_directives.

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 clear context for when to call it (to enrich an existing report's diligence checklist) and points to the follow-up action, add_diligence_item with source 'rag'. It does not state explicit exclusions or when a plain checklist lookup is preferable, but the usage context is unambiguous.

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

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

Annotations already declare readOnlyHint, openWorldHint and non-destructive behavior, so the bar is lower. The description still adds real context: that results include historical actuals plus an optional forward projection with 75/95/99% confidence bands, which tells the agent what it will receive and that forecasting is opt-in.

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 tight sentences with the core resource and scope front-loaded and no filler. Every clause (bands, segment scoping, valuation complement) carries information.

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 read-only, three-parameter tool with a full-coverage schema and an output schema, the description covers the essential shape of the result. It does not point to the discovery tools needed to supply metric_name, a minor omission given the schema references them.

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 all three parameters are already documented in the schema, including the forecast default and the segment/category key. The description only restates that the segment scope and forecast are optional, adding little beyond the structured fields, so baseline 3 applies.

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?

States a specific verb (retrieves) and resource (market metric time series) plus the optional forecast and segment scoping. It implicitly contrasts with siblings like list_market_metrics (which enumerates metric ids) by saying 'for a named market metric', but the differentiation is not made explicit.

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 closing phrase 'provides market context to complement individual valuations' implies when the tool is useful, but there is no explicit when-to-use, no when-not, and no pointer to list_market_metrics/list_market_categories for discovering valid inputs even though the schema references them.

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

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

Annotations already carry the safety profile (readOnlyHint, destructiveHint=false), so the lower bar applies. The description adds real behavioral context: it explains holding.imputed_fields vs holding.unknown_fields provenance, and that archived=true plus departure date/reason/price are returned for departed aircraft. It stops short of rate limits, auth, or pagination behavior.

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?

Front-loaded with the return payload, then the provenance and archived clauses. Dense and information-rich, though the two long sentences pack a lot and could be split for scannability.

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 read-only detail fetcher with an output schema present, this covers everything an agent needs: what comes back, the semantics of the provenance fields, and the archived-aircraft branch. Nothing material 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?

Schema coverage is 100%, so the schema already documents both parameters; baseline is 3. The description adds noteworthy meaning to line_id by noting it can also come from an event or an archived-aircraft listing, but inflation_base gets no treatment beyond the schema.

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?

Opens with a specific verb+resource and scope ('One portfolio aircraft in full') and enumerates exactly what the payload contains. It is immediately distinguishable from the sibling list_portfolio_aircraft because it operates on a single line_id.

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 routes the caller explicitly: pass a line_id from list_portfolio_aircraft, or a line_id from an event / list_portfolio_archived_aircraft to get the archived view. That covers both entry points well, though it never states when NOT to use it or what the alternative retrieval tools (get_portfolio_positions, get_portfolio_overview) offer instead.

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

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

Annotations already mark this read-only, non-destructive and open-world, so the safety bar is low. The description still adds real behavioral context beyond them: how 'restated' model changes are reported separately from the move, that unexplainable aircraft are counted rather than estimated, and the availability gating on stored daily valuations.

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 core purpose is front-loaded and the follow-on sentences each carry distinct information (drivers, restated handling, availability). The first sentence is dense and the 'Aircraft the period cannot be explained for are counted' clause is slightly awkward, but there is little dead weight.

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 an output schema present, the description need not explain return values, and it covers the key behavioral caveats (restated, unestimated aircraft, availability gating) an agent needs. What is missing is the sibling comparison for correct tool selection, which matters given the six-plus adjacent portfolio tools.

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 100% and both parameters carry descriptions, so the schema already documents them. The description only restates the window enum/default and does not add format or interpretation detail beyond what the schema provides. Baseline 3 is appropriate.

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 (why a portfolio's value moved) plus the resource (portfolio value) and enumerates the drivers of the move. It implicitly separates itself from the daily-vs-monthly sibling get_portfolio_attribution_by_month, but never names that sibling or otherwise explicitly differentiates itself, so it falls short of 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?

It gives concrete usage conditions: which window values are valid, what the default is, and that 'available is false until a daily valuation has stored explanations.' However, it never says when to choose this tool over get_portfolio_attribution_by_month or other portfolio-value siblings, leaving the primary routing decision to inference.

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

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

Annotations only declare read-only/non-destructive/open-world. The description adds substantial behavioral context beyond that: available is false until a month is explained, pending_aircraft are excluded from level and change, change.restated is reported beside the move rather than inside it, and amounts are nominal dollars.

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 purpose and the sibling alternative are front-loaded in the first and last sentences, and every clause is dense with domain meaning. However, a large middle block explains output field relationships (change.amount, level.typical, level.fleet) that an output schema already carries, making it longer than strictly necessary.

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 complex domain tool the description covers the caveats an agent needs (pending exclusion, availability gating, restated handling, nominal dollars) and the annotations carry the safety profile. It leans heavily on restating output structure that the output schema already defines, so it is complete but not optimally partitioned.

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?

There is a single parameter, portfolio_id, and schema description coverage is 100% ('From list_portfolios.'). The description adds no syntax, format, or sourcing detail beyond the schema, so the baseline 3 for high-coverage schemas applies.

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 states a specific verb+resource+scope: one portfolio's value by driver at every month start of its history, oldest first. It explicitly distinguishes itself from the sibling get_portfolio_attribution ('for the last day, week or month with the aircraft behind it'), so an agent can route correctly without opening either 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?

Names the alternative tool and the exact condition that selects it (recent day/week/month snapshots vs. full monthly history). It also gives an operational rule for the pending_aircraft edge case: report the breakdown as being updated rather than quoting it when pending share is large.

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

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

Annotations already mark this readOnly/non-destructive, so the safety bar is covered. The description adds genuine behavioral context beyond that: newest-first ordering, exclusion of pre-acquisition records unless include_history is true, and cursor-based pagination.

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 well-ordered paragraph: what the feed contains, then filtering, then history semantics, then pagination. Front-loaded and each clause carries information, though it is close to paragraph-length.

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?

An output schema exists, so return values need not be explained. Filtering, history scope, and pagination are all covered, leaving only minor gaps such as default date span or ordering tie-breaks.

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 83%, so the schema already documents most parameters. The description adds meaning the schema does not: the comma-separated prefix rule ('a prefix ends in .') and the semantic categories that kinds can take, which helps an agent pick values.

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?

States a specific verb and resource ('Get a portfolio's event feed') and enumerates the event categories returned (value moves, flight activity, registration changes, listings, incidents, web mentions, LTV crossings). This clearly distinguishes it from sibling list tools like get_portfolio_aircraft or list_portfolio_aircraft.

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?

Explains the two filtering axes (kinds prefixes or line_id) and the include_history condition with its default-off behavior. It gives clear context for use but never names an alternative sibling tool or states when-not to use this feed.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description nonetheless adds substantive behavioral context: the numbers are ESTIMATES derived from purchase price/date under lending assumptions, and per-aircraft terms override those assumptions field by field. That is exactly the interpretive context an agent needs.

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 sentences, front-loaded with the returned artifacts, and every clause earns its place — the second sentence exists to qualify the estimate methodology. Slightly dense with backtick field references but not wasteful.

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?

An output schema exists, so return values needn't be explained, and annotations cover safety. The description fills the remaining gap by explaining the estimate basis and the terms-override rule, leaving little an agent needs that 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?

Only one parameter exists and schema description coverage is 100% ('From list_portfolios'), so the schema already carries the semantics. The description adds nothing about the parameter, making the baseline 3 appropriate.

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 (get) and resource (a portfolio's lender view) and enumerates the concrete outputs — estimated loan balances, estimated LTV per aircraft, book summary, watchlist. This lets an agent distinguish it from nearby portfolio tools like get_portfolio_overview or get_portfolio_positions, though it never names a sibling explicitly.

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?

There is no when-to-use guidance, no prerequisites, and no reference to alternative tools. With many overlapping portfolio tools (get_portfolio_overview, get_portfolio_positions, get_portfolio_aircraft), an agent gets no help deciding when the lender view is the right choice over those.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's value-add is the inventory of returned sections, which is real context but largely overlaps the existing output schema; no auth, rate-limit, or scoping caveats are disclosed.

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?

A single dense sentence that front-loads the primary output (fleet value and KPIs) and then enumerates secondary sections; the inflation_base note is placed last as a modifier. Long but every clause names a distinct returned artifact.

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 an output schema present, the description need not detail return values, and the two parameters are fully covered by the schema. It is complete enough for an agent to select and call the tool, missing only sibling routing guidance.

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 both parameters are already documented (portfolio_id 'From list_portfolios', inflation_base 'YYYY-MM'). The description restates inflation_base's effect (inflation-adjusted dollars) but adds no syntax or behavior beyond the schema, so the baseline 3 applies.

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?

Names a specific resource (one portfolio) and enumerates exactly what the tool returns: fleet value/KPIs, value history, segment/state split, forecast, newest events. Clear verb+resource, though it does not explicitly distinguish itself from siblings like get_portfolio_positions or get_portfolio_events that overlap on data.

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?

Usage is only implied by the word 'overview' — an agent can infer it is the aggregate/summary entry point, but nothing states when to prefer it over get_portfolio_positions, get_portfolio_positions, or get_portfolio_events. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the data-provenance fallback chain (live ADS-B → last fix → base) and that each position is returned with its source, which tells the agent how to interpret staleness. It omits freshness/rate-limit details, but the lineage disclosure is substantive.

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?

A single front-loaded sentence with zero filler. The em-dash fallback clause packs the most important semantic (definition of 'last-known') into the opening statement rather than burying it.

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?

An output schema exists, so return structure is covered, and annotations cover safety. Combined with a fully documented single parameter and a description that explains the position-source semantics and the no-live-data fallback, 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?

One parameter with 100% schema description coverage, so the schema already documents portfolio_id and its provenance (list_portfolios). The description adds nothing about the parameter; baseline 3 applies when the schema does the work.

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?

Names the resource (each aircraft in a portfolio) and the exact payload (last-known position plus its source), with a precise fallback hierarchy: live airborne, else last ADS-B fix, else base. This distinguishes it cleanly from siblings like get_portfolio_aircraft (roster) and get_tracked_aircraft_snapshots (tracking history) without the agent needing to open a 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?

Usage is implied by the description — an agent can infer you call this to see where portfolio aircraft physically are — but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as get_portfolio_aircraft or get_tracked_aircraft_snapshots. The prerequisite (portfolio_id from list_portfolios) lives only in the schema, not the description.

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

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

Annotations already declare readOnly/destructive/openWorld, so the bar is lower, yet the description adds real context: the print_preflight mode is owner/admin-only, returns booleans plus an opaque reference, and performs no report data, token, render, or write action. That auth requirement and return-shape note is genuinely beyond the annotations.

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 sentences, core purpose front-loaded, and the special-case mode is clearly segmented. The second sentence is dense but every clause (auth scope, return type, side-effect disclaimer) earns its place.

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?

An output schema exists, so return values needn't be spelled out, and the description covers the two meaningful invocation modes plus the include options. It is complete enough for an agent to call correctly, with only minor gaps in block-value exhaustiveness.

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 carry the burden. It does so for `include` by enumerating valid block values and the special print_preflight value, though it leaves `report_id` as just 'by id' and the block list is presented as an example rather than exhaustively.

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?

States a specific verb and resource ('Fetch one report by id'), which distinguishes it from sibling list/search tools like search_reports and list_portfolio_reports. It does not name an alternative sibling explicitly, so it stops short of 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?

Gives clear conditional usage: use `include` to inline sub-blocks in a single call, and use only ['print_preflight'] for an owner/admin eligibility check. This tells the agent when to pick each mode, though it never names the sibling tools (get_report_section, get_report_download_link) an agent might otherwise reach for.

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

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

Goes well beyond the readOnly/openWorld annotations: 15-minute expiry, credential-free GET on the returned URL, 409 behavior with retry_after_seconds and generation_deferred_until, and the terminal generation_failed code. This is unusually rich error and lifecycle disclosure that 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?

Front-loads the core action and lifetime in the first clause, then layers usage precondition and error semantics. No filler sentences; every clause carries operational information.

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?

An output schema exists, so return values need not be explained, and the description still names the `url` field and its auth-free nature. Combined with full precondition and error-path coverage, an agent has everything needed to call this correctly.

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% for the single report_id parameter, so the description must compensate. It implies access scoping ('a report your account can access') but never states the expected identifier format or where report_id comes from. Baseline 3 given only one simple parameter.

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?

States a specific verb and resource: 'Mint a short-lived (15 minute) direct download URL for the generated PDF of a report'. This is clearly distinguishable from sibling get_report (which returns status) and search_reports, since it explicitly frames itself as producing a downloadable artifact.

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?

Explicitly tells the agent when the tool is usable ('Only works once the report has finished generating') and routes to the sibling: 'poll get_report until report_status is "complete"'. It also states exactly what to do on failure (409 retry semantics).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds that these mirror PDF report sections, which is useful context, but says nothing about auth, rate limits, or what a missing section returns.

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 sentences, front-loaded with the verb and resource; the enum list is long but earns its place by clarifying allowed values. Slight verbosity from enumerating all sections already in the schema.

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?

Output schema exists so return values needn't be described. However, with 0% schema description coverage and only the section list, the description is minimally adequate: it doesn't explain report_id semantics or error behavior for an invalid report/section.

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 0%, so the description carries the burden. It enumerates the section enum values (duplicating the schema) but adds no meaning for report_id or the format/meaning of section values. Baseline 3 as schema has an enum that is self-documenting.

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?

States a specific verb ('Fetch') and resource ('one of a report's structured sub-resources') and then enumerates every possible section value, making the scope concrete. An agent can pair this with get_report unambiguously.

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 'Mirrors the sections of the PDF report' line implies this is the way to retrieve sub-resources of a report, but no explicit when-to-use vs get_report or alternative is given. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the historical/dated nature of the result and the watchlist scoping, but says nothing about how many snapshots are returned, date-range limits, or auth requirements.

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 sentences with the resource stated first and use cases second; no filler. Slightly terse given the gaps elsewhere, but every clause earns its place.

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?

An output schema exists, so return values need not be described, and the read-only annotation covers safety. For a single-parameter read tool the description is nearly sufficient, lacking only guidance on result volume or time coverage.

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% for the single tracked_aircraft_id parameter, so the schema supplies no meaning. The description partly compensates by framing the input as a 'watchlisted tail,' but it doesn't clarify the ID's format or provenance.

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?

States a specific verb (get) and resource (historical valuation snapshots for a watchlisted tail), with the added qualifier that they are dated value points. It is distinguishable from value_aircraft and list_tracked_aircraft, though it doesn't explicitly name those siblings.

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?

Gives three concrete use cases (value trends, portfolio appreciation/depreciation, collateral monitoring), which implies when to reach for it. However, it never says when NOT to use it or names an alternative such as value_aircraft for a current valuation.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds genuinely new behavioral facts: the result is an immutable historical snapshot rather than a recomputation, and access is scoped to "the key that created it and to its enterprise workspace." It omits rate limits or pagination behavior, but those are secondary here.

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?

Front-loaded with the verb and resource, then a tight clause on snapshot semantics and a short sentence on access scope. Both sentences earn their place, though the em-dash clause packing value/ranges/hull-check is somewhat dense and slightly overlaps what the output schema conveys.

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 an output schema present, the description needn't enumerate return fields, and it correctly covers the things the schema cannot: immutability across model releases and the visibility/authorization scope. Nothing essential for correct invocation is missing, aside from any note on error behavior for an unknown id.

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 100% and the single parameter is already documented in the schema as the "uwe_…" id from an enrich result. The description only restates that the lookup is "by its enrichment_id" and adds no format or provenance detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb ("Return") and resource ("a stored underwriting enrichment") with a clear scoping qualifier ("exactly as it was first served ... even after a later model release") that distinguishes it from the sibling enrichment-creating tools such as enrich_aircraft_for_underwriting. An agent can tell this is a retrieval-by-id of a frozen snapshot, not a computation.

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?

Gives clear context for when this tool applies — re-serving a previously stored enrichment by its id, useful for reproducibility after a model release. It does not explicitly name alternatives (e.g. call enrich_aircraft_for_underwriting to produce a fresh enrichment) or state when-not to use it, so it stops short of full routing guidance.

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

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

Annotations only give the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description usefully adds that supplied fields are preserved, that field_sources encodes provenance (provided/registry/imputed), and the input vs return quality scales. It stops short of explaining auth needs or persistence/side effects, which matters given readOnlyHint=false.

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?

Front-loads the core purpose and then layers provenance and scale warnings in a compact sequence with no obvious filler. It is dense but every sentence carries actionable information.

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?

An output schema exists, so return-value structure is already documented, and the description focuses on the non-obvious semantics (field_sources, scale mismatch, chaining to value_aircraft). The one gap is the unresolved relationship to infer_aircraft_specs, which the description never clarifies.

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 schema coverage at 63%, the description compensates by explaining the identity parameters and the tricky 1-10 input vs 0-1 return scale for quality fields, which the schema only partly covers. It does not touch on the year parameter, so it adds solid but not full value over the schema.

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?

States a specific verb (ML fill-in) and resource (missing airframe, engine, and condition fields) with concrete examples (SMOH, AFTT, quality). However, it never differentiates from the near-identically named sibling infer_aircraft_specs, leaving an agent to guess which imputation/inference tool applies.

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?

Gives clear context ('before a valuation') and an explicit downstream route ('Pass the returned values straight to value_aircraft, which accepts either scale'). It also explains how to identify the aircraft (registration or make_model_id), but offers no when-not guidance and does not name a sibling alternative.

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

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

Adds substantial context beyond annotations: it discloses the underlying vision/LLM 'autopilot inference', the FAA registry lookup behavior triggered by anchoring, the tiered auth requirement, per-field source reporting, and a ready-to-POST report_input. The readOnlyHint=false is consistent with a tool that must be gated behind PRO/Enterprise and produces downstream artifacts; nothing is contradicted.

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?

A single dense paragraph with the core action front-loaded and no filler sentences. Slightly packed with clauses, but every element (specs, sources, storage anchor, impute, auth) earns its place.

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 six-parameter inference tool with an output schema, it covers what an agent needs: inputs accepted, anchoring behavior, gap-filling option, auth gate, and a preview of the return shape. Nothing material is left unexplained.

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 100%, so the schema carries the baseline (3). The description still adds meaning: it explains that registration/make_model_id pull make/model and year from the FAA registry, that images may be a listing's own photos or data: URLs, and how impute relates to the imputation model — more than the terse schema strings convey.

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?

States a specific verb ('Extract') and resource ('aircraft specs') and enumerates exactly what is extracted (AFTT, SMOH for engine 1/2, prop time, year, quality ratings, avionics). The scope — observable page content (text and/or image URLs) — cleanly separates it from the sibling impute_aircraft_specs, which is referenced only as a gap-filling model.

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?

Gives clear activation context: extract from visible text or image URLs, anchor with registration/make_model_id, and set impute=true to fill gaps. Prerequisites (Windsock PRO or Enterprise) are stated outright. It stops short of an explicit 'use this instead of X' routing statement, but the boundary with the imputation model is implied clearly enough.

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

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

Annotations already cover read-only, non-destructive, open-world safety profile. The description adds useful field-level shape (item states, sources, evidence) but does not state ordering, pagination, or that it requires an existing report. With annotations covering safety, this is adequate but thin.

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 front-loaded sentences, no filler. The field enumeration is long but informative rather than redundant. Could be tightened but nothing is wasted.

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?

An output schema exists, so return-value explanation is unnecessary; the enumerated fields are a helpful complement. For a simple single-param list tool with annotations, the description is nearly complete, lacking only usage routing and the report_id semantics.

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 0% and the single parameter 'report_id' is undocumented. The description says items are listed 'for a report', implying the param identifies the report, but adds no format or constraint detail. With 0 params documented in the schema, the description should compensate more.

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?

Clear verb+resource: 'List the pre-buy diligence checklist items for a report.' It is distinct from get_diligence_checklist and get_diligence_progress, though the description does not explicitly differentiate which sibling to use when. The enumerated fields give a precise sense of what an item is.

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?

No when-to-use, prerequisites, or alternative-tool guidance. With siblings like get_diligence_checklist and get_diligence_progress, an agent gets no signal which to pick. Only implied usage from the name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that the values are segment keys usable as a category argument; it says nothing about whether the list is static, how large it is, or how it relates to a live market data source. Adequate but thin beyond the annotations.

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 short sentences, the identity of the resource front-loaded ahead of the follow-on call. Every clause earns its place; nothing is repeated from the title.

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 zero-parameter read tool with a full output schema, the description need not explain return structure, and it correctly focuses on how the output feeds into get_market_metric. Only the absence of any note on the list's scope or stability keeps it from a 5.

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?

Zero parameters, so the baseline is 4. The description does add value by characterizing the value domain of the returned keys and showing an example format, which helps the agent construct a valid `category` for the sibling tool.

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?

States specifically what is returned — aircraft segment keys with a concrete example ('single_engine_piston') — which distinguishes it from the sibling list_market_metrics and get_market_metric. It never uses the word 'list' or explicitly says this tool retrieves the enumeration, but the resource is unambiguous.

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?

Gives an explicit follow-on use: pass a returned key as the `category` argument to get_market_metric, which tells the agent when this tool is the right entry point. It does not name a when-not condition or an alternative enumeration tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond that: the identifiers are stable and each entry flags forecasting support, telling the agent this is a durable reference catalog rather than a dynamic result set. Return-format details are omitted but are covered by the output schema.

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 sentences, both front-loaded: what the catalog contains first, then the actionable ordering advice. No filler, no restatement of the title.

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?

An output schema exists, so the description need not explain return values, and with zero parameters there is no input semantics to document. The description covers purpose, contents, and the workflow relationship to get_market_metric, which is everything an agent needs to call it correctly.

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?

The tool takes zero parameters, which is the baseline 4 case. There is nothing for the description to clarify about inputs, and the empty schema is consistent with the described no-argument catalog call.

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?

States a specific verb and resource ('Catalog of macro GA market metrics Windsock tracks') and enumerates the fields returned (identifiers, labels, units, forecasting support). It clearly separates itself from get_market_metric, but does not distinguish itself from the sibling list_market_categories, which an agent could plausibly confuse it with.

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?

Gives explicit sequencing guidance: 'Discover valid metric names before calling get_market_metric.' This is a clear when-to-use rule tied to a named sibling. It lacks any when-not guidance or differentiation from list_market_categories, so it stops short of a 5.

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

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

Annotations already declare readOnly/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it explains that imputed_fields marks facts Windsock inferred (estimated or FAA registry) vs holder-provided, and unknown_fields marks facts cleared or unreadable — real data-provenance semantics an agent could not infer.

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?

Dense and front-loaded with the returned resource, then provenance and pagination. The imputed/unknown-fields sentence is long but earns its place by defining a non-obvious data model; nothing is redundant filler.

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?

An output schema exists, so return-value enumeration is bonus rather than requirement, and the description still supplies the semantic meaning of returned fields plus pagination. For a read-only list tool with annotations and an output schema, this is complete; only the sibling-choosing guidance 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?

Schema description coverage is 100%, so the schema already documents limit, cursor and portfolio_id. The description reinforces pagination via next_cursor and the default page size, but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb+resource (list the aircraft in one portfolio) and enumerates the returned facts, letting an agent know exactly what this returns without opening a schema. It partially distinguishes itself from siblings by noting line_id addresses aircraft in the other portfolio tools, but it never contrasts against get_portfolio_aircraft or list_portfolio_archived_aircraft, leaving some ambiguity about which variant to pick.

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?

Usage is only implied — the description explains the shape of the data and points at 'the other portfolio tools' as consumers of line_id, but never states when to choose this over list_portfolio_archived_aircraft or get_portfolio_aircraft. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: exit-first ordering, the semantics of entry/exit price (first asking vs last asking on a for-sale portfolio), and the last Windsock value at exit.

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?

Front-loads the core purpose and is dense but earnable: the price-semantics sentence is genuinely non-obvious information. The trailing sentence about line_id addressing is useful for chaining but slightly tangential to the listing purpose.

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?

An output schema exists, so return values need not be explained, yet the description still orients the agent on row content. For a read-only single-parameter list tool with openWorld semantics and clear sibling hand-offs, nothing an agent needs in order to call it 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?

Only one parameter with 100% schema coverage, so the schema already documents portfolio_id (and its source, list_portfolios). The description does not add parameter-level meaning beyond repeating that the portfolio_id is derived from list_portfolios. Baseline 3 is appropriate when the schema fully carries the parameter.

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?

States a specific verb+resource ('aircraft that have left one portfolio') with the exit reasons in parentheses, making it immediately distinguishable from list_portfolio_aircraft (active aircraft). The description also names the sibling it hands off to (get_portfolio_aircraft for full history).

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 clearly frames when this list applies (sold, paid off, listing ended) and points to get_portfolio_aircraft for full history and update_portfolio_aircraft for addressing, which is useful chaining guidance. However, it never states the explicit contrast with list_portfolio_aircraft (active) as an alternative, leaving the sibling selection partly to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one real behavioral fact not in the structured data — results are ordered newest first — and signals that only 'locked' reports are returned, which is meaningful scoping.

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?

A single tight fragment that front-loads the resource and the ordering constraint; nothing is wasted. It reads as a label rather than a full sentence, but that is appropriate here.

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?

An output schema exists, so the description need not enumerate return values, and the safety annotations cover mutation behavior. The main gap is the absence of any routing guidance relative to sibling report tools, but for a simple one-parameter read this is otherwise complete.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents portfolio_id (including its source, list_portfolios). The description adds nothing about the parameter, so the baseline of 3 applies.

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?

States the specific resource — a portfolio's locked point-in-time reports — with clear scope ('newest first' plus the field set returned). This distinguishes it reasonably well from generic siblings like search_reports and get_report, though the listing verb itself is only implied by the name.

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?

There is no when-to-use guidance: nothing says to call this instead of search_reports or get_report, and no prerequisite or context (e.g., when a portfolio is locked) is given. The only hint is the required portfolio_id, which the agent must infer means 'use for a specific portfolio'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: the freshness dimension ('when each was last revalued') and the upstream role in the portfolio_id workflow. It does not discuss auth scope or result limits, but with annotations present the bar is lower.

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 sentences, zero filler, and the key directive ('Start here') is front-loaded after the payload summary. Every clause earns its place.

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 parameters, an existing output schema, and read-only annotations, the description only needs to explain purpose and workflow position — and it does both. Nothing an agent needs in order to call it 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description implicitly clarifies that no filtering input is needed and that the output feeds portfolio_id into other tools, which is the only 'parameter-like' guidance available here.

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?

States a specific verb+resource ('List your Pro Portfolios') and even enumerates the payload (fleet value, aircraft count, last revalued date), which is well beyond a tautology. It also distinguishes itself from the many portfolio-* siblings by positioning itself as the entry point that supplies portfolio_id.

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?

'Start here: every other portfolio tool takes a portfolio_id from this list — never guess one' is an explicit when-to-use plus a routing rule to alternatives. An agent knows both when to call this and why not to skip it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description's only added behavioral fact is the ordering guarantee ('newest first'), which is genuinely useful but thin; it says nothing about pagination, limits, or empty-result behavior.

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?

A single compact clause, front-loaded with the resource and backed by a useful ordering note. It is a noun fragment rather than a full sentence, which is mildly less scannable than a verb-first phrasing, but nothing is wasted.

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?

An output schema exists, so return values need no prose, and annotations carry the safety semantics. For a one-parameter read tool the description covers what is listed, its content, and its ordering, leaving only pagination/limit behavior unstated.

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 one parameter at 100% schema description coverage, the schema already documents portfolio_id fully (including its origin from list_portfolios). The description adds no syntax, format, or sourcing detail, so the baseline 3 applies.

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 specific resource (a portfolio's saved Stress Lab scenarios) and parenthetically clarifies their content (market shocks and their inputs). It is clearly distinct from neighbors like get_portfolio_events or list_portfolio_reports, though it never names those siblings to reinforce the distinction.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The agent must infer from the resource name that this is the retrieval path for stress scenarios and that it supersedes nothing else in the sibling list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only 'with their latest tracking state', which hints at freshness but says nothing about pagination behavior, result ordering, or what happens with large watchlists. With annotations carrying the behavioral weight, this partial contribution is a 3.

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?

A single front-loaded sentence with no filler; the resource and scope come first. It is appropriately sized, though its brevity shades into under-specification rather than elegance.

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?

An output schema exists, so return values need not be explained, but the tool has two undocumented parameters and no differentiation from the similar sibling get_tracked_aircraft_snapshots. For a list endpoint with pagination, the description is too thin.

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% and the description never mentions limit or offset, so an agent gets no guidance on pagination, defaults, or ranges. With two undocumented parameters, the description fails to compensate for the schema gap.

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?

States a specific verb ('List') and resource ('tails on your watchlist') plus the returned state, so the tool's function is immediately clear. It does not, however, distinguish itself from sibling get_tracked_aircraft_snapshots, which appears to cover related ground.

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?

There is no statement of when to use this versus siblings such as get_tracked_aircraft_snapshots or list_* market tools, and no prerequisites or exclusions. Usage is only implied by the phrase 'on your watchlist'.

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

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

Annotations already cover read-only/open-world/non-destructive, and the description adds substantial value beyond them: the 17 supported registers, the acceptance of international marks, the make_model_id/avionics_ids outputs, and the non-US registration_authority block plus FAA-only jurisdiction caveat for faa_ads/faa_stcs.

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?

Front-loaded with purpose, then acceptance, outputs, workflow position, and the jurisdiction caveat — all earning their place. The final sentence is long and run-on, slightly hurting readability, so not a full 5.

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?

An output schema exists, yet the description still usefully characterizes the key return fields; combined with the international-register and jurisdiction nuances, an agent has everything needed to invoke and interpret this tool correctly.

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 100%, so baseline is 3, but the description adds breadth to the parameter beyond the schema's single example by enumerating four international format examples and the register count, reinforcing that non-US marks are valid input.

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?

States a specific verb+resource (look up aircraft by tail number) and clearly distinguishes its role from siblings by positioning itself as 'the first step in any value this tail workflow', separating it from value_aircraft and search_aircraft.

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?

Clearly frames usage as the entry point to a valuation/reference workflow and identifies the downstream IDs it supplies. However, it never explicitly names the alternatives (e.g. search_aircraft) or states when-not to use this tool, which would push it to a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds return shape (individual tails), pagination/sorting, and the union-vs-intersection trap. However, the genuinely consequential behavioral disclosures — spec filters excluding 22-25% of the fleet, 36% missing airworthiness_class, 21.6% international aircraft meaning an unfiltered count is a world count, and international tails having no predicted_price — live in the filters schema text rather than the tool description, so the description itself carries only a moderate share of the burden.

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?

Front-loaded with purpose, then routing, then a note on filter shape — a sensible order. The closing 'Each filter is {field_name, condition, value}' mildly restates the schema and is the only near-redundant line in an otherwise dense, waste-free paragraph.

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 complex filter-search surface with an output schema, this covers purpose, return granularity, alternatives, and union semantics adequately. The one residual gap is that the most costly misuse — reporting a worldwide count as a US total, or using a nonexistent `country` filter — is only guarded inside the filters schema description, not at the top level where an agent skims first.

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 100%, so the baseline is 3; the description earns above that by explaining cross-parameter semantics the schema only implies — that filters are AND-combined, that multi-model search must be a single 'in' clause with an id array, and that each filter is {field_name, condition, value}. It does not itself mention limit/offset ceilings or sort defaults, leaving those to the schema.

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?

States a specific verb and resource ('Registry-wide aircraft search') and immediately scopes the output ('Returns individual registered tails'), which distinguishes it from the aggregate sibling count_aircraft. It also names the filter axes and the surrounding tool chain (search_make_models for id resolution), so an agent can place it in the workflow without opening the 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?

Gives explicit routing rules: resolve model names via search_make_models first, use condition 'in' to union several models in one pass, and prefer count_aircraft for population totals like 'how many R182s in Oregon'. It even pre-empts the failure mode of repeating make_model_id in separate AND-combined clauses.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral detail beyond that — no mention of result volume, pagination, or what the search actually covers (e.g., does it search full AD text?). With annotations carrying the load, this is adequate but thin.

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 compact clauses, no filler, with the core action front-loaded and the filters and use cases following. Every sentence earns its place.

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?

An output schema exists, so return-value explanation is not required, and the annotations cover the safety profile. But with four parameters at 0% schema description coverage, the missing meaning for q and limit leaves the definition incomplete for correct invocation.

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, yet it only explains two of the four parameters (make_model_id, status) and leaves q and limit completely undefined. The two it mentions are named without any format or accepted-value detail, so the gap remains substantial.

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 (Search) and resource (FAA Airworthiness Directive records) and names two of the filters, so an agent can distinguish it from siblings like search_aircraft or search_stcs. It is clear but does not explicitly differentiate itself from every neighboring search tool.

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 offers three concrete usage contexts (pre-buy AD review, maintenance planning, appraisal compliance sections), which implies when the tool is appropriate. However, it never names an alternative tool or states when NOT to use it, so routing guidance is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds that results affect equipment-adjusted valuations, which is useful context. However, it doesn't describe return format, pagination, or rate limits, and the output schema exists to cover returns.

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 concise sentences with no waste, front-loading the purpose and then the usage context.

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?

Complete for a read-only search tool with annotations covering safety and an output schema for returns. The main gap is lack of parameter semantics for the query, but the description gives enough for an agent to call it in the intended context.

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. It implies 'q' is for search text but provides no syntax, format, or examples for the query, and doesn't mention the 'limit' parameter at all. Baseline is 3 due to low coverage and no added parameter details.

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 (Search) and resource (avionics equipment names/types) and explains the output (avionics_ids that affect equipment-adjusted valuations), distinguishing it from sibling search tools like search_aircraft or search_make_models.

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 specifies a clear use case: 'Use to map panel/upgrade text to canonical ids.' This gives explicit context for when to invoke it, though it doesn't name alternatives or exclusions.

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

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

Annotations declare openWorldHint=true and destructiveHint=false, so safety is partly covered, but the description adds genuinely useful context not in the annotations: results are limited to 'reports you can access' (permission scoping) and hits carry page ids for citation. It does not disclose ranking, result volume, or pagination behavior.

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?

Three tight sentences with the core purpose front-loaded and no filler. The middle sentence enumerating hit fields is partly redundant given an output schema exists, but it remains short and useful.

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?

An output schema means return values need not be re-explained, and access scoping is covered, but with a 3-param tool the undocumented 'limit' and the absence of any guidance on result volume or ranking leave a real gap for correct invocation.

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 only 33%, so the description must compensate. It does clarify report_id's role as a scope filter, but 'limit' is left undocumented in both schema and description, and no format or default is given for it.

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?

States a specific verb ('semantic/hybrid search') and a specific resource ('digitized aircraft logbook entries'), which is clearly distinct from siblings like search_reports or search_airworthiness_directives. It stops short of naming an alternative tool or drawing an explicit boundary, which is what a 5 would require.

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 closing sentence 'Scope to a report with report_id' gives practical guidance on narrowing the search, but only at the parameter level. There is no statement of when to use this tool versus search_reports or the other search_* siblings, and no exclusions.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds real value beyond them: what the output is used for (value_aircraft, impute_aircraft_specs, reference lookups) and that it is an id-resolution step. It says nothing about matching behavior (fuzzy vs exact) or ordering of multiple hits.

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 sentences, no filler, with the scope and return type front-loaded before the usage condition. Every clause carries information the agent needs.

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?

Output schema exists and annotations cover safety, so the description need not explain return structure; it correctly focuses on purpose and workflow placement. Minor gap: no guidance on handling ambiguous multi-result searches versus the default limit of 25.

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. The description adds meaning by showing a query that mixes year and model ('2015 Cirrus SR22'), implying the search tolerates extra tokens such as year, which the schema's 'Cessna 172' example alone does not convey.

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?

States a specific verb and resource (text search over FAA make/model names) and names the concrete artifact returned (make_model_id values). It does not explicitly distinguish itself from the neighboring search_aircraft or lookup_aircraft tools, so the agent must infer that this searches model types rather than individual aircraft.

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?

Gives a concrete trigger scenario ('resolve "2015 Cirrus SR22" to a canonical id when no tail number is available'), which implicitly tells the agent to use a tail-number-based tool when one exists. It stops short of naming that alternative tool, so the when-not guidance is inferred rather than explicit.

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