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 cover only the safety profile (readOnly/openWorld/non-destructive), and the description adds substantial behavioral context beyond that: the fleet_cap scan ceiling, the fact that unfiltered counts are WORLD counts rather than US counts (21.6% international), that spec filters exclude aircraft lacking values, and that the `country` filter is rejected by the v3 validator and cannot select international aircraft. For a read-only aggregation tool this is unusually rich disclosure of data-quality and scoping 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 purpose, use case, and mechanism in the first three sentences, and the dense warning blocks are formatted with headers and emoji anchors. However, the filter-grammar material is exhaustive to the point of overlap with the schema, and the registry-fleet caveats are restated more than once, so it is 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?

An output schema exists, so return values need not be explained in prose, yet the description still names the fields to read (total_count / state_counts). Combined with the filter-grammar guidance, the fleet_cap limit, and the international-registry caveat, an agent has everything needed to call this correctly and interpret the number.

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%, so the baseline would be 3, but the description adds genuine semantics beyond the schema: union vs AND semantics for `make_model_id` (use `in` with an array, never repeated clauses), the `within_<miles>` + "lat,lon" pattern for location_point, the registry-authority code/token list, and population percentages for each sparse spec field. It also explicitly resolves a naming ambiguity (no `country` filter, use registration_country).

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: 'Aggregate registry census for a filter set: the total number of matching aircraft plus breakdowns by US state and by build year.' It explicitly contrasts itself with the sibling search_aircraft by noting it works 'without paging individual tails,' so an agent can route between counting and listing 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?

Gives a concrete use case ('how many Cessna R182s are registered in Oregon' with the exact filter shape), states it reuses 'the same filter grammar as search_aircraft,' and calls out the boundary condition that counts are computed over up to fleet_cap aircraft. It also tells the agent when NOT to repeat a filter ('Do NOT repeat make_model_id in separate clauses') and to warn the user when sparse-coverage filters are used.

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 but say nothing about side effects; the description adds that it creates a durable account-owned report and queues asynchronous PDF generation, plus a PRO/Enterprise entitlement requirement. That is meaningful behavioral context beyond the structured data, though it omits failure modes and whether duplicate reports are allowed.

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: purpose and scope first, then side effects, then the entitlement gate. No filler and nothing buried.

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 shape need not be described, and the description covers the write/side-effect profile and access requirements. It is slightly incomplete on the three input parameters, whose meanings and formats remain undocumented at the description level.

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 33% and the description says nothing about registration, make_model_id, or the nested aircraft_info payload. The legacy 0–1 quality-scale caveat lives only in the schema, so the description 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 and resource (generate a Windsock verified value report) and scopes it ('from instant valuation data (contemporary model only)'), which implicitly separates it from value_aircraft (instant valuation) and get_report (retrieval). An agent can tell what is produced and from what input 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 real eligibility constraints — 'contemporary model only' and 'Requires Windsock PRO or Enterprise' — that tell the agent when the call can succeed, and the 'from instant valuation data' phrasing implies value_aircraft is the upstream step. It stops short of explicitly naming alternatives or stating 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=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?

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 declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds no behavioral context beyond annotations — no notes on freshness of valuation, auth requirements, or staleness of tracking status — leaving the description with nothing beyond a payload inventory.

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. It is efficient, though it spends its whole budget enumerating return fields, which the output schema already covers.

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 return-value list is largely redundant, and the safety profile is fully covered by annotations. What remains missing is the guidance an agent actually needs — when to call this versus list_portfolio_aircraft or get_portfolio_positions.

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%, and both parameters (line_id and inflation_base) are documented in the schema with useful provenance and format hints. The description contributes no additional parameter meaning, 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 the resource precisely: a single portfolio aircraft ('One portfolio aircraft in full'), which implicitly contrasts with the plural sibling list_portfolio_aircraft. It does not name the retrieval verb or explicitly route against the list tool, but the singular scope 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?

No when-to-use guidance, no mention of the sibling list_portfolio_aircraft as the way to obtain line_id, and no statement of prerequisites or when this differs from get_portfolio_positions. The only hint is that line_id provenance lives 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 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=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds genuinely useful semantics: the values are ESTIMATES derived from purchase price, purchase date, and the portfolio's lending assumptions, and are explicitly not loan records — a caveat an agent must know before presenting them as facts.

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 padding: the content list comes first and the important estimate caveat is front-loaded immediately after. 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?

With an output schema present, the description need not enumerate return fields, yet it usefully summarizes them and flags the estimate-vs-record distinction. The only gap is the absence of routing guidance against the many sibling 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?

Only one parameter, and the schema documents it fully (100% coverage) including its provenance ('From list_portfolios.'). The description adds nothing about the parameter, 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 the concrete content returned — estimated loan balances, LTV per aircraft, book summary, watchlist — which is a specific resource+verb and distinguishes it from generic siblings like get_portfolio_overview or get_portfolio_positions. It stops short of naming those siblings, so an agent must infer the routing.

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 statement and no alternatives named, despite many portfolio-scoped siblings (get_portfolio_overview, get_portfolio_positions, get_portfolio_aircraft). The lender framing implies a lending-analysis context but the agent gets no explicit trigger condition.

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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and access profile is covered. The description adds one genuinely useful behavioral fact: `include` inlines sub-blocks into a single response rather than requiring follow-up calls. It says nothing about errors on unknown/invalid section names or defaults.

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, with the core action front-loaded and the optional parameter guidance second. Every clause earns its place by naming the mechanism and giving a usable example.

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 need not be re-explained, and the description adequately covers both the identity parameter and the optional expansion parameter. It could be tighter about what happens when `include` is omitted or contains an unrecognized section, but nothing prevents a correct call.

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 does this well for `include` by giving a concrete example array that effectively enumerates the valid section values — information absent from an untyped string array in the schema. `report_id` is left to the reader's obvious inference as the report identifier.

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 report by id'), and the singular 'one report' plus 'by id' implicitly contrasts with the sibling search_reports. However, it never names the alternative (search_reports, get_report_section) outright, so differentiation relies on 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?

It gives one concrete usage cue — use `include` to inline sub-blocks in a single response — which tells the agent how to batch related data. It does not say when to prefer this over get_report_section or search_reports, leaving the selection decision unaddressed.

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 the safety profile is covered. The description adds valuable behavioral context: the URL is short-lived (15 minutes), carries its own authority, needs no credentials, and only works after generation completes. This goes beyond the annotations and helps the agent understand the operational 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 sentences, each earning its place: the first defines the action and lifetime, the second explains how to consume the result, the third states the precondition. Information is front-loaded and there is 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?

The tool has a single parameter, an output schema, and clear annotations. The description covers the key operational context: the URL's temporary nature, no-credential access, and the precondition. It doesn't describe error cases (e.g., what happens if the report isn't ready), but for a simple one-parameter tool with an output schema, this is nearly 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 description coverage is 0%, so the description must compensate. It mentions 'report your account can access' and 'once the report has finished generating', which implies report_id must reference an accessible, completed report. However, it doesn't explicitly explain what report_id is or how to obtain it, though the sibling get_report and search_reports tools provide that context. The description adds some meaning but not exhaustive parameter semantics.

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 ('Mint'), a resource ('short-lived direct download URL for the generated PDF of a report'), and a clear scope ('your account can access'). It distinguishes itself from siblings like get_report and get_report_section by focusing on the download link rather than the report 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?

The description explicitly says when to use it: only once the report has finished generating, and it tells the agent to poll get_report until report_status is 'complete'. It also explains how to use the returned URL (plain GET, no credentials), which is essential usage 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 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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows it's a non-destructive write with possible external data. The description adds valuable context: supplied fields are preserved, there is an unusual scale inversion (1 on input = like-new; output on 0-1 scale), and returned values are compatible with value_aircraft. That is meaningful beyond the annotations, though it doesn't cover idempotency or rate limits.

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 purpose, then scale semantics, then usage. It is compact but packs several sentences; the scale warning is repeated from the schema, which is necessary for a trap but slightly increases 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?

Given the output schema exists, the description needn't explain returns. The description covers the key behavior, the input/output scale mismatch, and integration with value_aircraft. It could be more complete about what fields are imputed and any side effects, but it's solid for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, so the description must compensate. It does so by explaining the scale trap for exterior_quality and interior_quality and confirming that registration/make_model_id identify the aircraft. But year, and any other param semantics, are left undocumented.

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 action (ML fill-in of missing fields) on a specific resource (airframe, engine, condition specs) with the business purpose (before a valuation). It's clear what it does, though it doesn't explicitly differentiate itself from the sibling infer_aircraft_specs, which likely overlaps.

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 the when-to-use context (before a valuation) and names the downstream tool (value_aircraft). However, it doesn't address exclusions or clarify when to prefer it over infer_aircraft_specs, its closest sibling.

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 cover the safety profile (readOnly, non-destructive, openWorld), and the description adds useful behavior: page size default, cursor-based pagination, and the identity semantics of line_id. It could still note ordering or whether tracking data is refreshed, but it goes 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 dense sentences, no filler, front-loaded with the returned row shape before pagination mechanics. 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?

An output schema exists, yet the description still efficiently previews row contents, and it covers pagination and the cross-tool line_id linkage. For a read-only list tool with full schema coverage, nothing an agent needs 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?

Schema coverage is 100%, so all three parameters (limit, cursor, portfolio_id) are already documented in the schema. The description's restatement of the page size and cursor mechanics adds little beyond the structured fields, 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 and resource ('The aircraft in one portfolio') and enumerates exactly what each row contains (tail, make/model/year, value and change, tracking status, loan balance). This clearly distinguishes it from the singular get_portfolio_aircraft and from list_portfolios.

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 explains the pagination workflow (next_cursor, default 50 per page) and, importantly, that line_id is the handle used by the other portfolio tools, which tells the agent how to chain calls. It stops short of explicitly saying when to choose this over get_portfolio_aircraft or list_tracked_aircraft.

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 cover readOnly/openWorld/destructive, but the description adds rich context beyond them: data coverage warnings (engine power 75%, weights 76%, smoh 12%, certification 36% missing), and the crucial registry state warning that ~21.6% are international and unfiltered counts are global. This is essential behavioral disclosure.

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 purpose and then moves into exhaustive filter mechanics and warnings. Information density is high and each sentence adds value, but it runs long and some repetition (e.g. filter structure stated twice) slightly harms scanability.

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's complexity (5 params, nested filter object, enum-heavy fields), the description is complete: it covers return semantics (individual registered tails, pagination/sorting), data caveats, international registry scope, and workarounds. Output schema exists but the description still provides necessary operational 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 coverage is 100%, but the description adds substantial meaning: filter structure {field_name, condition, value}, AND combination semantics, the union trick with condition 'in', location_point syntax "lat,lon" with within_<miles>, the fact that using a filter EXCLUDES missing-value aircraft, and the absence of a country filter with the recommended workaround.

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 ('aircraft search'), names the scope ('registry-wide', 'fleet / market-research search surface'), and distinguishes itself from siblings by referring to search_make_models and count_aircraft. An agent can identify its purpose 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?

Explicit when/when-not guidance: resolve model names with search_make_models first, prefer count_aircraft for population totals, use condition 'in' for multiple models. Naming sibling tools and conditions makes routing 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=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.

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 externally. The description adds that results are paginated and account-scoped, which is useful behavioral context, but it says nothing about default page size, sort behavior, or result shape.

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 front-loaded and no filler. The only cost is that the second sentence spends its budget on filters that don't map to real parameters.

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?

Filter semantics are essential for a 6-parameter, 0%-coverage search tool, and the description both omits sort/limit/offset meaning and names filters that aren't in the schema. An output schema exists so return values need not be explained, but the input picture is incomplete and partly inaccurate.

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% across 6 parameters, so the description must carry the burden — but it partly misleads, advertising 'price bounds' and 'whether logbooks are attached' filters that do not exist in the schema. It also omits any semantics for sort, limit, and offset, leaving a reader likely to attempt unsupported arguments.

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 plus resource ('Paginated search over appraisal/valuation reports') and scopes it to reports the account can access. It does not, however, distinguish itself from the sibling get_report beyond the search/get verb pair, so the reader must infer the difference.

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 use this instead of get_report or search_aircraft, and no preconditions (e.g., needing a known report id) are stated. Only the access scope 'your account can access' hints at applicability.

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 safety is covered. The description adds real operational behavior the annotations cannot: that a single row can exceed ~90K characters due to large applicability lists, and that slim=true trades those strings for an applicability_summary so the endpoint stays usable. That payload/limit guidance is unusually valuable, though it says nothing about auth or rate limits.

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 core action, then the use case, then the large-payload caveat. Dense but every clause adds information; the final sentence is long but justified by the concrete 90K+ figure and the slim mitigation.

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 carry the safety profile. The description covers purpose, use case, the make_model_id filter, and the payload-size hazard, leaving only minor gaps such as what q matches against and default/pagination behavior for limit.

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 25%, with q and limit undocumented in both schema and description. The description does explain make_model_id's role and slim's effect and rationale, partially compensating, but two of four parameters carry no meaning anywhere — so the description is incomplete rather than fully compensating.

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 (search STC records) plus the optional filter (make_model_id) and the returned content (certificate numbers, descriptions, applicability). It is clearly distinguishable from the adjacent search tools in the family (search_airworthiness_directives, search_avionics, search_make_models) by naming the STC record type.

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 usage context — pre-buy due diligence and documenting mods that affect value — which tells the agent when this tool is the right choice. It stops short of naming a sibling alternative or stating when not to use it, so it is clear but not fully routing.

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 supply the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds that this creates a persistent recurring-monitoring entry, which is real context, but says nothing about duplicate handling if the tail is already tracked, permission requirements, or whether the entry can be removed.

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, with the purpose of the tool front-loaded before the parameter requirements. 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 explained, and the annotations cover the write/safety profile. However, for a tool that mutates a watchlist, the description omits duplicate-tracking behavior and the relationship between the optional registration and the required aircraft_info, leaving gaps.

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%, so the schema does not carry the load. The description names make_model_id and aircraft_info.year as required and explains that registration identifies the tail, but does not say where make_model_id comes from (e.g., search_make_models) or how registration relates to the required aircraft_info.

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: add a tail to a portfolio watchlist, with stated purpose (recurring valuation snapshots, change monitoring). This distinguishes it from one-off valuation siblings like value_aircraft and from read paths like list_tracked_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 phrase 'recurring valuation snapshots and change monitoring' implies when this is appropriate versus a single valuation, but no alternative is named and no condition or prerequisite is stated. Usage is inferable rather than explicit.

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 adds genuine context by implying only 'user items' accept field edits (title/category/guidance/critical), which is a real constraint. It says nothing about permissions, reversibility of state changes, or whether omitted fields are preserved.

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 full list of editable surfaces, followed by the usage cue. Nearly every clause earns its place, with only mild redundancy in repeating 'set its state' and 'edit a user item's fields' after the opening 'Update one diligence item'.

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 explanation, and annotations cover safety. However, for a 10-parameter mutation with 0% schema documentation, the description should at minimum flag the required identifiers and the partial-update semantics; those gaps leave the agent under-informed before calling.

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% across 10 parameters, so the description must carry the load. It names most editable surfaces (state with its enum, notes, photo_keys, value_impact, and the user-item fields), but leaves report_id, item_id, critical, category, and guidance only obliquely covered, and never clarifies that report_id/item_id are required.

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 ('Update one diligence item') and enumerates what can be changed: state, notes/photo keys, value_impact, and user-item fields. It is clearly distinguishable from add_diligence_item and delete_diligence_item by the verb, though it never names a sibling to sharpen the boundary.

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 line 'Use this to tick items off as you verify them' gives an implied usage context, but there is no guidance on when to prefer add_diligence_comment (whose job overlaps with the notes field here) or when the item must be user-created before fields can be edited. Usage is implied rather than specified.

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 generic readOnly=false/openWorld=true/destructive=false profile, so the description carries real weight: it discloses that the tool is machine-generated, the date boundary (2020) that switches between the contemporary and deep-history longitudinal models, and that richer output requires opting in via include. It does not cover auth, determinism, or latency, but the model-selection disclosure is genuinely useful and non-obvious.

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?

Four sentences, front-loaded with what the tool is, then input modes, then the date-driven model switch, then the optional expansions. No filler; every clause conveys an actionable fact.

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 description covers input modes and model selection well. The main residual gap is guidance on choosing this tool over sibling valuation/cost tools, which is minor given the schema and annotations are otherwise rich.

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%, so the baseline would be 3, but the description adds meaning beyond the schema: the as_of_date value is not just a date but a model selector, and include is framed as an output-expansion switch. The tail-vs-spec either/or relationship between registration and make_model_id+aircraft_info is also made explicit.

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 ('machine-generated aircraft market value') with scope (single point in time, back to 1960) and even self-identifies as 'the flagship valuation tool'. It is clearly separable from siblings like create_valuation_report, estimate_cost_of_ownership, and impute_aircraft_specs.

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 input-mode guidance: 'Provide a tail number OR a full spec (make_model_id + aircraft_info)', and explains that as_of_date selects which model runs. It stops short of stating when to prefer this over create_valuation_report or estimate_cost_of_ownership, so it lacks explicit alternatives/exclusions.

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