Jet Tracker

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it defines how nights are counted (midnights between arrival and next departure), how ongoing stays are handled, what overnightEvents means, how confidence is derived, and the caveat that baseUf is the RAB owner state, not a base. This is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a long, clause-chained sentence with heavy in-line definitions of return fields, some of which duplicate what the output schema already conveys. It is information-dense but at the cost of readability and structure.

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 a fairly complex analytical tool with an output schema present, the description is complete enough to call correctly and to interpret the 'base' concept's ambiguity. It over-explains return semantics the output schema would carry, but nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so both parameters (registration and days) are fully documented in the schema, including the default 365 and the 30-730 range. The description restates the window/default but adds no syntax or format detail beyond the schema, 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?

The description names a specific verb+resource combination ('Overnight ranking of one registration over N days') and clarifies the output concept (aerodromes where the aircraft slept, inferredBase). It is distinguishable from siblings like jt_aircraft_flights and jt_aircraft_history, though the density of jargon requires careful reading.

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 implicitly frames the tool around answering 'where is this aircraft based' and warns that the facts can disagree, which hints at when the result is appropriate. However, it never explicitly names an alternative sibling or states when NOT to use this tool, leaving routing 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 readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses coverage limits ('partial', a third of Brazilian flights end at strips without ground coverage), the data provenance split (US via FR24 for the business aviation fleet, without free ADS-B destination inference), ordering, and page caps. That is exactly the kind of reliability context an agent needs before trusting results.

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 paragraph that front-loads the resource and scope, then the return fields, then provenance caveats. The parenthetical token lists are compact rather than wasteful, though the single-block layout makes the caveat easy to skim past.

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 explanation is unnecessary, and the description still adds ordering, pagination and data-source caveats. The dangling 'see the caveat' pointer references something the agent may not have, which is the one loose end.

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

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

With 100% schema description coverage the baseline is 3; the description earns extra by stating the default window (90 days) and a 365-day maximum that the schema does not encode anywhere. It does not explain the arrivalConfidence/coverage tokens as parameter-adjacent semantics, but those are return values rather than inputs.

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 opening sentence states a specific verb and resource ('Tracked flights of one Brazilian registration or US N-number in a period') and enumerates what is returned. It does not name any of the many sibling tools (jt_aircraft_history, jt_movements, jt_global_fleet_stats) to disambiguate scope, so an agent must still infer whether this or jt_aircraft_history is the right call.

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?

Defaults (last 90 days, max 365, 200 per call) and the pagination pattern are supplied, which implicitly tells the agent how to call it. However, there is no explicit statement of when to prefer this over jt_movements or jt_aircraft_history, and no exclusions; usage must be inferred.

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/idempotent/non-destructive, and the description adds substantial extra behavior: timeline items represent owner/operator changes with change=first_seen semantics, dates are observation dates not event dates, foreignOrigin is only filled on recorded foreign marks, and country=US requires an FAA match on N-number AND serial together. This is exactly the kind of nuance an agent cannot get from the schema or 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?

Front-loaded with the core purpose, then dense qualification clauses that each carry real meaning (timeline semantics, FAA match rule, CPF exclusion). It is long and somewhat run-on, but nearly 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 shapes need not be spelled out, yet the description still explains the tricky semantics of timeline[], foreignOrigin, and country that the schema likely cannot convey. Combined with full annotation coverage and a 100%-documented parameter, nothing needed to call this tool correctly is missing.

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

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

Schema coverage is 100% and the single parameter already documents hyphen/case tolerance in detail. The description adds only the term 'matricula' as a synonym for the tail, which is marginal beyond the schema. 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 precise resource and scope: an ownership/operator timeline for a Brazilian-registered tail, plus foreign origin and published accidents/incidents. This is clearly distinguishable from siblings like jt_aircraft_base (static data) or jt_registry_changes (no accident/origin narrative). An agent can pick this tool 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?

Usage is implied by the content described (history/timeline queries for a Brazilian tail), but the description never states when to prefer this over jt_aircraft_base, jt_registry_changes, or jt_cross_registry, nor any exclusions. It's adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint, idempotent, destructive=false and openWorld=false, so safety is covered. The description adds genuine domain context beyond that: it explains what 'base.uf' actually means (registered state of the owner, not an aircraft base) and where the owner city lives, which prevents a real misinterpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a single sprawling sentence enumerating many returned fields that the output schema already covers. It is dense rather than wasteful, yet part of the enumeration is redundant given a structured output 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?

With an output schema present the return-field list is optional, and annotations carry the safety profile, so the description only needs to add the domain caveat it does provide. Nearly complete; only explicit sibling routing would push it higher.

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%, documenting both 'registration' (format, case, hyphen) and 'detail' (compact vs full behavior). The description repeats registration prefixes but adds no parameter semantics beyond the schema, so baseline 3 applies. The field enumeration describes return values, not inputs.

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 ('Full profile of a Brazilian-registered aircraft by its registration mark') and immediately distinguishes itself from the US sibling jt_us_aircraft_lookup by scoping to Brazilian registrations with example prefixes. An agent can pick this over the batch or US variant without opening 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?

The lookup-by-registration usage is implied clearly, but there is no explicit when-to-use/when-not guidance and no mention of near siblings like jt_aircraft_lookup_batch or jt_us_aircraft_lookup. Adequate but leaves routing 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior on top: partial-failure semantics ('found:true with the profile, or found:false with the reason') and quota cost ('Debits one lookup per registration from the daily quota'). Quota consumption is exactly the kind of side effect annotations cannot express.

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, zero filler, and the highest-value facts (sibling equivalence, batch limit, quota cost) are front-loaded. Nothing needs to be read twice.

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 described, yet the tool still discloses partial-failure shape and quota debit. Combined with the batch limit and sibling anchoring, an agent has everything needed 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?

Schema description coverage is 100%, so the schema already documents both parameters including detail defaults, max 25 items, hyphen/case tolerance, invalid-item handling and duplicate collapse. The description only restates 'compact detail by default', adding no meaning beyond the schema; 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 specific resource (aircraft profiles) and the batch scope ('up to 25 registrations in one call'), and explicitly anchors itself to the sibling jt_aircraft_lookup ('same profile as'). An agent can distinguish it from both the single-lookup tool and unrelated siblings immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the reference sibling and the batching condition ('up to 25 registrations in one call'), which implies when this is preferable to jt_aircraft_lookup. It leaves the when-not-to-use (e.g. single registration, or needing more than 25) to inference rather than stating it outright.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds valuable context beyond that: the ranking priority, the meaning of rankingReason and alternatives[], and a caveat that many small strips lack ICAO or runway length.

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 purpose, followed by ranking details and a data-quality caveat. The three sentences are dense but each carries useful information; the ranking list is long but directly relevant to result interpretation.

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 single required parameter, rich annotations, and an output schema, the description is mostly complete: it explains query forms, ranking behavior, output fields, and data limitations. The main gap is the absence of usage guidance relative to sibling tools.

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

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

Schema description coverage is 100% and already documents the query parameter with examples. The description adds some meaning by naming IATA and city/name as valid query types and noting Brazil-first ranking, but does not add syntax or format constraints 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?

States a specific verb (Find) and resource (airport), lists input types (ICAO/IATA/city/name) and returned fields (coordinates, elevation, runway length/type). It is clear what the tool does, but does not explicitly differentiate itself from siblings such as jt_airport_traffic or jt_runway_check.

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 or alternatives are provided. The ranking and Brazil-first note describe behavior rather than usage context, leaving the agent to infer when this tool is preferable to sibling airport-related tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: ordering (nights then activity), a 100-per-call cap with nextCursor pagination, and an explicit partial-coverage caveat. The 'see the caveat' reference is vague since the caveat itself is not included, which keeps this from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core answer ('Which aircraft arrived at or departed...') before the metric definitions. It is a dense block with several parenthetical clauses, but nearly every clause carries real semantic information (nights, overnightEvents, relation thresholds) that an 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?

For a read-only analytical tool with a full output schema, the description is close to complete: it covers defaults, limits, ordering, pagination and the derived fields. The only gap is the reference to an unexplained 'caveat' about partial coverage, which the agent cannot resolve from the definition alone.

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 explains derived semantics not in the schema: what 'nights', 'overnightEvents', and 'relation' (based/recurring/occasional) mean, plus the period defaults and cap. It does not clarify the segment enum, but the added derived-field definitions push it above baseline.

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 precise verb+resource: aircraft that arrived at or departed from a given ICAO airport within a period, drawn from ADS-B/FR24 tracked flights. It explicitly demarcates scope ('who flies to my region', not 'who is registered in my city'), so an agent can separate it from registry-oriented siblings like jt_aircraft_lookup or jt_us_aircraft_lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context (arrivals/departures analysis for an airport, default 90 days, max 365) and a scope exclusion that routes the agent away from registration-based tools. It stops short of naming an explicit alternative sibling or stating when-not to use it in favour of, e.g., jt_movements.

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 read-only, idempotent and non-open-world, so the safety profile is covered. The description adds substantial behavior beyond that: confidence ranking 0–1, matchReason[] in Portuguese, max 10 candidates, empty-list semantics, and the coverage boundary of the underlying dataset.

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?

It is a single dense paragraph, but the key facts (what it matches, coverage restriction, ranking, cap) are front-loaded and every clause carries information. Marginal density could be trimmed, 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 shape need not be explained, yet the description clarifies the two output-relevant fields (matchReason[], hasAircraft) and the group enrichment. For a 6-param, 0-required search tool with annotated safety, nothing an agent needs is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds real meaning: normalization rules for q (accents, case, legal suffixes such as Ltda/S.A./Participações ignored), domain accepting full email/URL, and includeGroup's dependency on jt_owner_group access.

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 (candidate/find) and resource (Brazilian companies / CNPJ) and the exact input modalities accepted (free-text name, email or website domain). It also delineates itself from generic company registries by scoping coverage to companies linked to Brazilian 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?

Explicitly names the situation it is built for ('leads that give a company name or a corporate email but no CNPJ') and states a when-not via coverage limits (an empty list means no known aircraft link) and ignored inputs (personal email domains). It stops short of routing to a named alternative sibling for the case where a CNPJ is already known.

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 read-only/idempotent/no-destruction, and the description adds substantial context beyond them: the exact output set (annual and hourly averages, horizon total, NPV, year-by-year cashflows), the sign convention (outflows negative), the assumptions block, the costModelVersion, and the default Brazilian opportunity rate. This is rich disclosure for a pure-read comparator.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the entire specification is crammed into one run-on sentence of roughly 130 words mixing inputs, outputs, assumptions, aliasing and currency. Every clause is informative, yet the structure makes it hard to parse, so conciseness is only adequate.

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 four-parameter, read-only comparator with an output schema, the description covers everything an agent needs: valid input domain, prerequisite cost profile, alias acceptance, currency and default rate, output contents and sign convention, plus cross-references to the sibling tools that supply profiles and specs.

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 3 is the baseline, but the description adds real meaning: it confirms alias tolerance with concrete examples (phenom-300, embraer-phenom-300e, hawker 400xp) and notes that the response reports which profile was actually used via its model field. The hours/horizon/rate semantics themselves are already fully covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (compute total cost of ownership) and pinpoints the exact scope: five operating models on a model with a full cost profile. It distinguishes itself from siblings by naming jt_model_specs as the shared cost engine and jt_model_search as the source of comparadorProfiles, so an agent can place it precisely in the toolset.

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 clear prerequisite — the model must have a full cost profile — and routes the agent to jt_model_search (comparadorProfiles) to discover the five valid profiles. It never states when NOT to use it or contrasts it with jt_trip_cost, so the guidance is contextual rather than exclusionary.

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, idempotent, non-destructive, closed-world), but the description adds real behavioral value beyond them: the match algorithm (serial + compatible manufacturer/model) and the caveat that serial numbers repeat across models, which warns the agent about false positives.

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, front-loaded with purpose and inputs. The trailing '(see the caveat)' is slightly awkward since no separate caveat section exists, but the substance is tight and 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 single-parameter, read-only lookup with a 100%-covered schema and an output schema, the description supplies everything the agent needs: accepted inputs, matching logic, target registries, and a false-positive caveat. Nothing material is missing.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline would be 3. The description goes beyond the schema by enumerating accepted input formats (Brazilian PR-/PT-, US N-number, CA/AU/NZ/MX registrations, or a serial), which usefully clarifies what a valid 'query' looks like.

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 (find the same airframe across registries) and scopes it to the exact registry set Jet Tracker indexes. The 'traces an aircraft moving between countries' phrase plus the matching rule (serial + compatible manufacturer/model) distinguishes it clearly from siblings like jt_aircraft_lookup and jt_registry_changes.

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 conveys when this tool is the right one: when you have a registration or serial and want the counterpart airframe in another registry. It does not explicitly name alternatives such as jt_aircraft_lookup for single-registry lookups, but the 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?

The annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), and the description layers on non-obvious behavior the schema cannot express: max 100 per call, "the daily quota may truncate (quotaTruncated)", segment auto-selection with segmentApplied/outsideSegment, RBAC 137 returning operators with their fleet, and preview.total still reporting matches when the account cannot list. It also warns that sameAirframeAs lists other live registrations of the same physical aircraft and must be counted once — exactly the trap an agent would fall into.

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?

Every clause carries information, but it is delivered as one long undifferentiated paragraph with parenthetical asides, and the important segment fallback logic is buried mid-stream after the filter list. It would be considerably more usable as two or three front-loaded blocks (what it lists / how segment resolves / limits and gaps).

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 24-parameter, zero-required search tool with an output schema, this covers the things an agent cannot get elsewhere: pagination via nextCursor, row shape (ownerRecords, ownerRole, airworthiness, flightActivity, riskFlags, sameAirframeAs), deterministic registration ordering, quota truncation, and the behavioral caveat about segmentApplied. Nothing needed to call it correctly is absent.

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 description's parameter content largely restates what the schema already documents (CNAE prefixes 3316/5111/64, RBAC 91/135/121/137, cite lists). The one genuine addition is the segment fallback rule — piston category defaults to "all", a model absent from the executive cut switches to "all" — which is semantics of the segment parameter the schema does not state. Baseline 3 is appropriate for a fully documented 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?

"List Brazilian-registered aircraft by COMPOSED filters" gives a specific verb, resource and geographic scope in the first clause, which separates it from jt_global_fleet_search and from single-entity siblings like jt_aircraft_lookup. The enumeration of filterable dimensions (owner state, CNAE, RBAC, tracked hours, hub) makes the tool's surface 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?

It sets a clear usage mode ("one call per question", union through models up to 30, paginate with nextCursor) and states an explicit exclusion: "Filtering by a person's name is not available." What is missing is explicit routing to siblings — it never says to use jt_owner_fleet for an owner's full fleet or jt_global_fleet_search outside Brazil, so the agent must infer those boundaries.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond that: the two counting universes (registry vs live), what each includes and excludes (cancelled registrations; operational + mark reservation + suspended), serial-level dedup, the as_of snapshot date, and the source URL for verification.

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 headline metric and efficient, but the long parenthetical run-ons and stacked clauses take effort to parse; a small amount of restructuring would improve it without losing content.

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 fields need not be explained, yet the description still labels the key metrics, which makes the response interpretable. The remaining gap is the absent routing guidance against the sibling stats/search tools.

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

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

Schema coverage is 100% (the slug description is minimal), and the description adds real meaning: the slug may be an alias, resolves to a whole family, and model.matchedBy reports how resolution happened. That goes beyond the schema's bare 'Slug do modelo.'

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?

It states a specific verb+resource: Brazilian fleet counts for a catalog model drawn from the RAB, with named metrics (registryTotal, alive, airframes). The 'Brazilian' qualifier implicitly separates it from jt_global_fleet_stats, but the sibling is never named, so differentiation requires 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?

Usage is only implied: it returns a count for a model, so an agent can guess it is the aggregate-stat call versus jt_fleet_search or jt_aircraft_lookup. It never states when to prefer this over jt_global_fleet_stats, nor any prerequisite about resolving a slug first.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds meaningful context beyond that: the score is a transparent weighted sum, contributing facts appear in evidence[] with weights, coverage[] reveals which inputs existed, and the result is explicitly heuristic rather than authoritative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and score range are front-loaded, and the inventory of scoring factors is compressed into one clause. It is dense but nearly every element (evidence[], coverage[], the heuristic disclaimer) carries information an agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still clarifies the shape of evidence[] and coverage[], which helps interpretation. Combined with the annotations covering safety, an agent has enough to invoke and read the 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?

Only one parameter and schema description coverage is 100%, so the schema carries the parameter burden (including the Brazilian registration format). The description adds only that one registration is scored, which is inherent in the purpose statement, 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?

States a specific verb and resource: a 0-100 fit score for one registration against a fractional/shared-ownership program, and enumerates the scoring inputs. It is clearly a per-registration scoring tool, distinct from market-level siblings like jt_fractional_market, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scoring factors (owner role, fleet size, age, utilization, state, model category) but there is no explicit when-to-use guidance or routing to an alternative such as jt_fractional_market. The negative framing ('not an appraisal or an offer') narrows interpretation but does not tell the agent when to pick 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/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real provenance context beyond that: EA authorizes MODELS not tails, fleet counts come from the RAB cross-referenced by CNPJ root (getFractionalView), and 'monitored' operators are never certified. That's meaningful behavioral context, though it doesn't cover pagination or provenance caveats for the timeline view.

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 scope and view inventory are front-loaded, which is right for a multi-view tool of this complexity. It is dense but largely earns its length; there is some redundancy in the trailing sentences repeating what EA is and that counts come from the RAB, which 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 formatting needn't be described. Given the multi-view complexity, the description supplies the view inventory, filter semantics, and data-provenance caveats (EA vs RAB, monitored vs certified) an agent needs to call it correctly, leaving no material gap.

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 goes further by explaining the semantics behind each view value (what 'models' aggregates vs 'bases' counts) and clarifying that `operator` accepts slug, brand, legal name, or CNPJ/root, which adds interpretive value over the terse schema entries.

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 resource (Brazilian RBAC 91K fractional/shared-ownership market data) and enumerates the five views with their exact contents (operators roster, per-aircraft fleet, model aggregates, timeline changelog, base counts). This is specific enough that an agent can distinguish it from jt_fleet_search, jt_operator_profile, and jt_market_listings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what each view returns and that `operator` restricts any view to a single operator, which implies usage. However, it never states when to choose this tool over the many related siblings (jt_fleet_search, jt_operator_profile, jt_operators_stats) or any when-not condition, so the routing guidance is left 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?

With readOnly/idempotent/non-destructive annotations already covering the safety profile, the description adds real context: the underlying data sources and their vintage (weekly ANP average, spot EIA), the unit conversions returned, and the scope caveat about wholesale vs into-plane pricing. It does not state refresh cadence or staleness of the 'latest' values, which is the one behavioral gap.

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?

It is one front-loaded sentence that leads with the resource and its two source markets, then layers units, derived metrics, the history parameter, and finally the scope caveat. Dense but almost every clause carries decision-relevant information; it is slightly run-on and would read better split into two sentences.

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-field explanation is unnecessary, and annotations cover the safety profile. The description supplies what those structured fields cannot: data provenance, unit conventions, the derived premium/PTAX outputs, and the wholesale-vs-into-plane limitation. Nothing an agent needs before calling is missing.

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

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

Schema coverage is 100% and the single optional parameter is documented in the schema, so baseline would be 3. The description earns a point by explaining what the window governs — both the monthly averages and the set of marked market events returned — plus restating the default 12 / max 60 in context.

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 resource (jet fuel reference prices) with named sources (ANP QAV/Jet A-1 weekly average, EIA Gulf Coast spot), the units returned, derived metrics (Brazil premium, USD/BRL PTAX), and the historical window. An agent can tell this apart from siblings like jt_price_history or jt_market_index without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing clause 'Wholesale references, not into-plane prices at a given airport' explicitly rules out a class of use case, steering an agent away from using it for airport-level cost modeling. It does not name a sibling alternative (e.g. jt_trip_cost or jt_compute_tco) for those cases, so routing is only partially covered.

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

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

Goes well past the annotations: deterministic ordering, nextCursor pagination, a 100-row cap, a daily quota that can silently truncate (quotaTruncated), how year is inferred from another registry with a source mark, and how unknownYear is counted. It also discloses a meaningful privacy behavior (natural persons are never named) and trust-company exposure via shared registrant addresses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the filter list is useful, but the second half enumerates per-row return fields in long run-on prose even though an output schema exists, so a meaningful share of the text is duplicative. The information is dense but not well structured for scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, optional-nothing search tool, it covers the operational envelope an agent needs: quota truncation, pagination, ordering, required model/category, unknown-year handling, and an explicit statement of what is out of scope. Nothing that would change how the agent calls it 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 baseline is 3, but the description adds semantics the schema does not: offMarket is tied to whether any active listing is linked by Jet Tracker, ownerKind behavior around individuals, and year inference/confidence. Some of it (offMarket, status reserve) duplicates the schema text almost verbatim, which holds it below 5.

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 ('List aircraft across every registry Jet Tracker indexes') plus the exact filter surface (model/category, year range, countries, status, ownerKind, offMarket). It also bounds the scope relative to siblings by noting that Brazilian detail (owner QSA, contact, CVA) is deliberately absent from these rows, which is what separates it from the Brazil-oriented fleet 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?

Gives an explicit intended use case ('Built for off-market prospecting such as "Global 6000 2014-2016 not listed, worldwide"') and the hard precondition that model or category is required. It stops short of naming the sibling tool to use instead when Brazilian detail is wanted, leaving that routing 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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful data context the annotations cannot supply: the source report, the historical window beginning 2005, and the important caveat that the current year is partial. It stops short of explaining pagination or default row behavior beyond what the schema states.

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 whose clauses all carry information: source, scope, enumeration of views, and the two disambiguating caveats. It is front-loaded correctly, though the nested parenthetical list makes it slightly harder to scan than a short lead plus bullets would be.

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 the description covers source, coverage window, view semantics, and the partial-year caveat. What is missing is only marginal: nothing about row limits or how the views rank/report, which the schema partly covers via top.

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, but the description goes further by mapping parameters to the view that consumes them (oems/models for top and oem, kind and query for models). That cross-parameter relationship is not captured in the flat schema and materially helps correct invocation.

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 resource (worldwide general aviation factory shipments), the source (GAMA Shipment Report), the time span (2005 to current quarter), and the four selectable views. It also pre-empts confusion with the sibling fleet tools by stating 'Deliveries, not fleet in service,' so an agent can separate it from jt_fleet_stats or jt_global_fleet_search without opening 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?

The description enumerates what each view returns and which filters apply to which view ('models' uses oem or query), giving clear selection context. It also implicitly excludes fleet-in-service questions. However, it never explicitly names a sibling tool to prefer for those alternative questions, so routing is inferred rather than 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 cover read-only/idempotent/non-destructive, so the bar is lower; the description adds real behavioral context beyond them: tracked-flights-only scope, default 90-day window, 365-day max, 100-per-call cap, cursor paging, and the meaning of coverageGap=true and departure=null/ongoing=true. The dangling 'see the caveat' reference adds no information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core definition leads, then event fields, then use cases, then limits. Every sentence carries information, though the paragraph is long enough that a reader must work through it to reach the operational constraints.

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 annotations, a full input schema, and an existing output schema, the description supplies what's needed: the at-least-one-param rule, defaults, caps, and the coverageGap caveat semantics. The unexplained 'see the caveat' pointer is the only loose end.

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 meaning the schema cannot express: it surfaces that at least one of registration or icao is required (the schema lists zero required params) and restates the default period and record cap. It doesn't clarify the segment default switch beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb+resource: stays of 7+ days at an airport without a following tracked departure, scoped to one registration or one airport. It also enumerates what each event contains (airport, arrival, departure, days, atHub, coverageGap), making it clearly distinguishable from siblings like jt_movements or jt_maintenance_signal.

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 names concrete use cases ('where an aircraft spends long periods away from home (often a maintenance shop)' and 'which aircraft are parked at a given airport') and states the cardinality constraint that at least one of registration/icao is required. It does not, however, point to an alternative sibling when the agent wants a different view (e.g. maintenance-specific signals).

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

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

Annotations already declare readOnly/idempotent/openWorld=false, and the description still adds real operational context: the one-signal-per-airframe de-duplication rule, that registrations[] aggregates multiple reservations and airframeCount differs from registrationCount, the 60-row cap, and the 200-reservation scan per page with nextCursor pagination. That is exactly the behavioral detail annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph, front-loaded with the matching definition before the operational limits and the broker example. Every clause carries information, though the parenthetical PS-XXX/PS-YYY/PR-ZZZ example and the dangling 'see the caveat' reference cost it a point.

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 5-parameter, output-schema-backed signal tool this covers what matters: what qualifies as a hit, how hits are de-duplicated, result caps and pagination, and the semantic boundary between a reservation signal and a completed transfer. Nothing an agent needs 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?

Schema coverage is 100%, so the binding baseline is 3; the description rises above it by explaining pagination mechanics ('Max 60 per call; scans up to 200 reservations per page, paginate with nextCursor') and the aggregation semantics that explain why one result row can cover several registrations. It does not address includeUnmatched, but the schema already documents that flag.

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 precise resource and the exact join rule: Brazilian mark reservations in the RAB whose airframe matches a foreign registry entry (FAA N-number or CA/AU/NZ/MX) by serial + compatible model, and labels the output 'the import signal'. It does not, however, name or distinguish itself from near-neighbours such as jt_cross_registry or jt_registry_changes in a 40-tool sibling set, which keeps it 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?

Usage is only implied. The target audience is named ('useful for brokers, lenders and insurers') and a caveat is gestured at ('It is a signal, not a completed transfer'), but there is no explicit when-to-use vs. when-to-use-an-alternative guidance and the referenced caveat is never actually stated. An agent can infer the use case but gets no routing rules.

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, idempotent, non-destructive, closed-world), yet the description adds substantial behavioral context beyond them: it explicitly disclaims what it will NOT do ('never estimates an inspection due date or airframe hours: those are not in the data') and characterizes each signal's structure and epistemic status (kind, severity, underlying facts; hints rather than facts). This is exactly the honesty about limitations that annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the composition of signals, then limitations, then framing. The middle enumeration is dense but each clause maps to a real signal; the closing caveat earns its place. Minor verbosity from the parenthetical domain references, but 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-value detail is unnecessary, and the description still covers signal composition, structure, and the critical data-limitation caveats. For a single-parameter, read-only analysis tool, an agent has everything needed to invoke it and interpret results 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?

There is a single parameter with 100% schema description coverage, including the Brazilian format example and length bounds, so the schema already carries the parameter semantics. The description adds nothing about the registration argument, leaving the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource ('Composes what is known about one registration into maintenance signals') and enumerates the concrete signals produced (CVA/CA validity, RBAC 145 shop stays, idle days, utilization trends, coverage/owner status), so the agent knows exactly what comes back. It is clearly distinct from siblings like jt_aircraft_base or jt_aircraft_history by domain, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It frames the output's intended use ('hints to prioritise outreach, not facts about the aircraft'), which implies when the tool is useful. However, it does not state when to prefer it over siblings such as jt_aircraft_history or jt_aircraft_base, nor any exclusions, so the 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 the tool as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it is a frozen monthly edition, fragile rows yield only the central count, and prices are asking prices rather than closing prices.

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 front-loaded and dense but purposeful, covering the index scope, metrics, and caveats without filler. The main sentence is long and parenthetical, which slightly reduces readability, but every clause contributes 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 one-parameter index tool with an output schema, the description is complete: it explains the source, cadence, segment behavior, returned metrics, and important caveats such as fragile rows and asking versus closing price. Annotations and schema cover the remaining safety and parameter details.

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 the single optional segment parameter is fully documented in the schema, including the behavior when omitted. The description reinforces that results are per segment but does not add parameter semantics beyond the schema, so the baseline score 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?

The description clearly identifies the resource: the Jet Tracker Index for the Brazilian used business aviation market, broken down by segment. It specifies the exact metrics returned, so an agent can tell what the tool does, though it does not explicitly name sibling tools like jt_market_listings or jt_fleet_stats 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?

Usage is implied by the description: it returns the published monthly index, with per-segment fleet base, for-sale counts, share of fleet, and asking prices. There is no explicit guidance on when to use this versus similar siblings such as jt_market_listings or jt_price_history, and no exclusions are 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 cover safety (readOnly, idempotent, non-destructive), and the description layers on substantial semantics they cannot convey: the active/stale(30+ days)/expired(60+ days) definitions, the treatment of sale-suspended offers in activeCount, priceStats and the sample, and the caveat that prices are portal-advertised, not appraised. The declared-vs-verified distinction for spec filters is exactly the kind of behavioral caveat 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?

Front-loaded with the resource definition, then the status semantics, then the optional filter behavior — a logical order with no filler sentences. It is dense and sentence-heavy, packing several clauses per sentence, which costs some scannability but every clause carries a distinct rule.

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 tool with nested spec_filters and an output schema, the description supplies everything an agent needs to call and interpret it: counting rules, status thresholds, excluded populations, filter semantics and the withSpecsCount caveat. Return-value detail is largely carried by the output schema, so no gap remains.

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 earns more by clarifying that slug accepts an alias and covers the whole model family, and by re-framing spec_filters as filtering on what the seller DECLARED, with an explicit empty-result interpretation rule (unknown, not none). It adds meaning beyond the per-field schema text rather than restating 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 precise verb+resource — for-sale listings for a catalog model (slug or alias, whole family) — and immediately bounds the scope with what is and is not counted (suspended offers excluded). An agent can distinguish this from jt_price_history or jt_model_specs without opening any schema, because the description defines exactly which population and which fields are returned.

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 operational context: spec_filters are optional, only match what the seller declared, and when present the response gains spec_matches/withSpecsCount; it also instructs the agent to read withSpecsCount before concluding 'nothing exists'. It stops short of naming alternative tools (e.g. jt_price_history, jt_sale_propensity) or stating explicit when-not-to-use 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 only declare it a safe, idempotent, closed read; the description goes well beyond that by disclosing quota consumption ("uses the daily records quota"), subscriber-gated fields (links, days on market, price-drop detail), staleness signalling (ingestionStale, lastListingReadAt), and the exclusion rule excludedLikelyTransacted for post-listing registrations of sale/owner change. It also warns that asking prices are never closing prices and defines exactly how askingMedianUsd is computed and why price-on-request aircraft are excluded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the content is dense with no filler, but it is delivered as one very long paragraph mixing filters, output shape, quota caveats, subscriber limits and the social_radar branch. The information all earns its place; the structure would be better served by separating the social_radar branch from the main search.

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 17-parameter, zero-required, open-filter search with an output schema, the description covers what an agent needs to call it and interpret the answer: filters, ready modes, the top-level envelope (total, median, lastListingReadAt), per-row fields, and the two exceptional result shapes. Nothing essential is left to inference.

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

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

With 82% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: that mode=new maps to a 7-day detection window, what mode=price_drops actually returns (from/to and the drop date), and that source=social_radar repurposes the whole result set into off-market items with sourceLabel and detectedAt. It leaves uf/region/country, segment, category, limit and cursor entirely to the schema, which is acceptable given the high coverage.

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 opening sentence names a specific verb and resource — "Aircraft FOR SALE across all models in one call" — and scopes the source (tracked portals, one row per aircraft, duplicates merged). It explicitly distinguishes itself from the per-model sibling jt_market_listings, and carves out the alternate result shape when source=social_radar, so an agent can separate this from the other 48 tools without opening 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?

It gives concrete use contexts — mode=new for "new this week" (last 7 days), mode=price_drops for sellers who lowered asking price, source=social_radar for off-market social-media offers — and routes the per-model/spec-sheet case to jt_market_listings. What is missing is explicit when-not guidance (e.g. for broad fleet counts use jt_global_fleet_search or jt_market_index), so the agent gets positive routing but 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 declare read-only, idempotent, non-destructive and closed-world; the description adds provenance per figure (engine program, published intervals, CENIPA/NTSB/ASN) and, importantly, a hard limitation that no airframe or engine hours exist so no due-date can be derived. That caveat prevents a serious misuse mode the annotations could never convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening clause front-loads the resource and the parenthetical enumerations replace what would otherwise be several paragraphs, so density is earned. The middle section is a long run-on with nested parentheses and acronyms (TBO, HSI, RBAC 145) that slightly impedes scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation; the description instead covers what the tool will not do (no tail-level hours or due dates), where each figure comes from, and where to go for the per-aircraft case. Nothing an agent needs to select and 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?

Schema coverage is 100% and the single `model` parameter is described in the schema, including its format and its source (jt_model_search). The description adds no syntax, format, or validation detail beyond that, 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 a specific verb and resource — a maintenance reference for one catalog model — and then enumerates exactly what figures it returns (engine program TBO/HSI hours, overhaul reserve, published intervals, ANAC 145 shop counts, accident/incident totals). It explicitly frames the scope as model-level, which separates it from the per-tail tools 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?

Gives a clear use case ('MRO, insurer, lender or buyer questions about a type') and names the alternative for the adjacent need ('the events of one tail are in jt_aircraft_history'), plus an explicit exclusion ('never says when a given aircraft is due'). It does not differentiate from overlapping siblings like jt_maintenance_signal or jt_mro_capabilities, which cover adjacent maintenance/shop data.

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 read-only/idempotent/non-destructive, and the description adds genuine behavioral context: the coverageJump flag explains anomalous old registrations appearing at once, and provenance ('same numbers as the Jet Tracker model page and market view') sets expectations. It stops short of describing pagination or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core purpose and return shape come first, defaults and the coverageJump caveat follow, and the sibling pointer is last. Every clause carries information an 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?

With an output schema present, return formatting need not be re-explained; the description covers scope defaults, the coverageJump caveat, and provenance, which is enough to invoke correctly. A note on pagination or output granularity would round it out fully.

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%; the schema documents model and scope but leaves months undescribed. The description fills that gap by stating the default (12) and max (120), and reinforces that scope defaults to the whole family. It adds meaning beyond the schema for the one undocumented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('how the Brazilian fleet of a model moved between monthly RAB snapshots') and enumerates exactly what is returned: entries, mark-reservation/suspended entries, exits, net, per snapshot and total, plus live fleet. It also distinguishes itself from the sibling jt_registry_changes, which covers the underlying aircraft rather than aggregates.

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 operating context (default 12 months, max 120, family scope by default) and routes to jt_registry_changes for per-aircraft detail. It does not explicitly say when to prefer this over jt_movements or jt_fleet_stats, so the exclusion guidance is only partial.

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, idempotentHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the pagination contract (offset/nextOffset) and the coverage caveat that zero results doesn't prove absence, which is real added context. It does not discuss rate limits or result ordering, so it earns above-baseline but not rich.

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 dense sentences, front-loaded with the search axes, then the return shape, then the slug/pagination guidance. The enumerated return-field list overlaps what the output schema already provides, which is minor waste, but nothing else is 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?

For a zero-required-parameter, 4-param search tool with a dedicated output schema and full annotation coverage, the description covers scope, vocabulary, return identity (slug) and the caveat about empty results. An agent has everything needed to call it correctly and interpret an empty response.

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

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

Schema description coverage is 100%, so the schema already documents limit, query, offset and category, including the enum values. The description's value-add is concrete query examples ("piper", "meridian", E55P, BE40) that the schema lacks, but the category and pagination explanation largely restates the schema. 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 (search) and resource (Jet Tracker aircraft models) and enumerates the two axes of filtering (text and category) with concrete examples. An agent can distinguish this catalog-search tool from jt_fleet_search or jt_global_fleet_search without opening 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?

Explicitly notes the category vocabulary matches jt_fleet_search and that the returned slug is the model id other tools accept, which tells the agent how to chain calls. It also warns that zero results is not proof of absence. It stops short of naming a sibling to use instead when searching fleets vs models, so a 4 rather than a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the bar is lower. The description adds genuinely new behavioral context: fuzzy slug resolution via model.matchedBy, the costModelVersion stamp, and the standard_hours_per_year=200 default that drives the total-per-hour figure. It does not mention rate limits or caching, hence not a 5.

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 with no filler; the payload is described first, the resolution semantics second. The parenthetical lists are dense but each item carries information. Slightly over-packed for a one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be enumerated, yet the description names the key fields (variable cost/hour, fixed cost/year, total/hour, acquisition curve, costModelVersion) and flags that the numbers match the model page and jt_compute_tco — enough for an agent to trust and reuse the output. Nothing critical is missing for a single-param read 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 100% for the single slug parameter, so baseline is 3, but the description goes beyond the schema by enumerating accepted forms (bare slug, family slug, slug with or without manufacturer prefix, or model name) and by naming the resolution-echo field. That is real added meaning the schema 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 resource (catalog model technical specs) plus a second, clearly bounded payload (the canonical operating cost engine), so an agent knows exactly what comes back. The phrase 'canonical operating cost engine' and the explicit reference to jt_compute_tco assumptions distinguish it from the cost-computation 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?

Usage is implied: this is the per-model lookup that yields specs and standard cost figures, and the mention of jt_compute_tco signals a relationship. But there is no explicit when-to-use/when-not statement and no routing versus jt_model_search (discovery) or jt_compute_tco (custom TCO runs).

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 read-only, idempotent, non-destructive, so the bar is lower, yet the description discloses a lot beyond them: database-side filtering, the companyMatch row semantics, the known blind spot (RAB keeps only the first owner name, so minority co-owners can be missed), sameAirframeAs de-duplication, and the meaning of truncated/found:false. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The deprecation notice and the core definition are front-loaded, and nearly every sentence carries operative meaning (defaults, match semantics, caveats). It is a single dense block paragraph without sub-structure, which makes the company-filter explanation harder to scan than it needs to be.

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 11 parameters, an output schema present, and rich annotations, the coverage is thorough: pagination, summary ordering, exact total vs truncated, max page size and the segment default are all stated. An agent can call this correctly and interpret the response without opening other sources.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the default segment rule (executive, or all when registrations/cnpj is set) and, importantly, what the cnpj filter actually matches (current aircraft plus owner/operator names the RAB uses for that company) with the rabNamesMatched caveat. It does not clarify from/to or rbac beyond the schema, so not a 5.

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 precisely that this is the deprecated alias of jt_registry_changes with identical behaviour, then names the resource (RAB registry changelog) and enumerates the change types. It explicitly rules out the wrong reading ('not airport movements') that the name jt_movements would otherwise invite.

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 the deprecation window (kept until 2026-12-09) and routes the agent to jt_registry_changes, names what does not belong here (airport arrivals/departures), and warns that a registry change is not a sale, pointing to the caveat field. Both when-to-use and when-not are 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 cover safety (read-only, idempotent), and the description adds genuinely non-derivable behavior: the model-mode list consumes the daily records quota, results are capped at 50 with full coverage first, total is always returned, and per-capability matchType/scope/alsoMatches semantics are spelled out. It even tells the agent how to present exact versus approximate counts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and every block maps to a distinct rule (modes, matching, coverage levels, quota). It is nonetheless dense and parenthetical-heavy, with asides like the '10 h / 1 month' example that add length without changing how the tool is called.

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 two-mode domain tool with zero required parameters, the definition covers input selection, ambiguous-match handling, output field meanings (matchType, coverage, fullRating, fleetSearchModels), and cost. An output schema exists, so the extra return detail is bonus rather than a gap.

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 documents the parameters, but the description adds mode dispatch the schema cannot express: q/com/cnpj select mode 1, model selects mode 2, and model slugs come from jt_model_search or fleetSearchModels. It stops short of explaining the uf narrowing or mixed-identifier precedence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: what a Brazilian RBAC 145 maintenance shop is rated by ANAC to work on, from its Operations Specifications (airframes, engines, propellers, equipment). It then names two distinct modes so an agent can tell the shop-lookup mode apart from the model-lookup mode 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?

It explicitly routes: 'Use this when a lead is a maintenance shop', explains why jt_company_search only finds the CNPJ, and excludes jt_owner_fleet as the wrong market basis. It also constrains each call to a single mode, and instructs how to handle ambiguous name matches (offer up to 5 candidates and let the user pick).

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

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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive), while the description adds substantial behavior an agent cannot get elsewhere: the 100-tail cap with fleetTruncated, the 90-day CVA/idle-day vulnerability window, the explicit no-CPF guarantee, and that a brand spanning multiple CNPJs collapses into ONE group. It also explains the found:false outcome, which is critical for interpreting misses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the bulk is one ~150-word run-on sentence with nested parentheticals, and much of it re-enumerates return fields that an output schema already documents. It is dense rather than padded, yet the structure is heavy to parse and partly duplicates structured data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex Brazilian registry tool, the definition covers identifier handling, group aggregation, truncation, privacy limits and the not-found case, and safety is already carried by annotations with return shape by the output schema. Remaining gaps (e.g. what 'dominant RBAC' entails beyond the output schema) are minor.

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 for the single query parameter is already 100%, so the baseline is 3. The description still adds value by restating and expanding the accepted formats (brand/URL slug as in /operadores/<slug>, 14-digit CNPJ vs 8-digit root) and by clarifying that a spelling or CNPJ-root mismatch yields found:false.

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 precise verb+resource (company-side profile behind a Brazilian operator/owner group) and maps it to the public /operadores page, then enumerates exactly what the payload contains, which cleanly separates it from siblings like jt_owner_group, jt_operators_stats and jt_company_search. An agent can tell what it returns 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?

The accepted query forms (slug, commercial/legal name, CNPJ or 8-digit root) strongly imply this is the identifier-based lookup, and the found:false note gives a failure condition. However, there is no explicit when-to-use/when-not statement and no sibling is named as the alternative for adjacent questions (e.g. individual owner fleets), so guidance stays implicit.

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/idempotent/non-destructive/closed-world, so the description's added value is real: it discloses that this aggregate never names operators (a privacy constraint), defines the RBAC 91/135 scope filter, and describes as_of and source.url. It stops short of discussing caching, pagination, or freshness beyond the snapshot date.

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 what the aggregate contains, then the name-vs-aggregate contrast and alternative tools. Dense but each clause carries information; only the parenthetical scope definition is slightly cluttered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still usefully names key fields. Combined with the scope definition, the no-names behavior, and the sibling routing, an agent has enough to call this correctly; only explicit prerequisites or error behavior are absent.

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 only one parameter (slug) and the schema documents it at 100% coverage with length constraints, so the schema carries the burden. The description implies the slug identifies the model, but adds no format or lookup guidance beyond that, matching the baseline for fully-covered schemas.

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 (aggregated statistics) and resource (operators of a model, in Brazil), and enumerates the exact dimensions returned (distinct operators by CNPJ root, RBAC 91/135 split, concentration by state, average fleet age). This clearly separates it from sibling stats tools like jt_fleet_stats or jt_operator_profile.

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 explicitly names the alternatives jt_fleet_search and jt_owner_fleet and states the condition that distinguishes them: those tools return operator names, this one never does. That is a clear routing signal, though there is no explicit 'use this when' phrasing or stated exclusions beyond that contrast.

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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: the role semantics (owner vs operator), the fields returned (status, segment, lien, co-owners), and the important caveat that an empty list is a legitimate answer.

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, front-loaded with the resource and matching rule, then item contents, then the empty-result caveat. Every sentence carries information; only the parenthetical could be trimmed, but it is genuinely clarifying.

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 detailed, yet the description still summarizes the item shape (role, status, segment, lien, co-owners). Combined with the matching rule and empty-result note, an agent has enough to call and interpret it correctly; explicit sibling routing is the only missing piece.

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%, which sets a baseline of 3. The description earns above that by explaining how the cnpj parameter actually behaves (matched on the 8-digit root, so a branch does not exclude the parent company's aircraft), a matching nuance the schema does not state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: aircraft in the Brazilian registry linked to a company CNPJ. It further disambiguates from siblings by defining the matching rule (8-digit company root) and the scope (branch does not hide parent company aircraft), which clearly separates it from jt_fleet_search and jt_global_fleet_search.

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 CNPJ-based scoping and the note that an empty list is valid, which helps the agent interpret a null result. However, it never explicitly names when to prefer this over jt_fleet_search, jt_fleet_stats, or jt_owner_group, leaving alternatives 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 cover safety (readOnly, idempotent, openWorld=false, non-destructive), and the description goes well beyond them: the 50-member cap, the meaning of each confidence tier, the aircraftTotal vs aircraftTotalConfident distinction, and a caveat that links are public-record hints rather than a legal structure.

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 resource and scope, but the long inline enumerations of basis types and confidence rules re-explain return values that the output schema already carries, bloating what could be a tighter description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex economic-group tool with an output schema, the description supplies everything else an agent needs: member cap, confidence semantics, counter definitions, and the legal-structure caveat that sets expectations for interpreting results.

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 cnpj, registration and limit are already documented; the description adds only the framing that the CNPJ may be a 14-digit number or 8-digit root and the registration resolves to the first owner. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (companies linked to a CNPJ/owner forming an economic group) with the exact basis types returned, so an agent can tell this apart from jt_owner_fleet or jt_company_search without opening 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?

Explains the rationale for using this tool ('The RAB splits a group into many CNPJs... this gives the whole set in one call'), which tells the agent when this tool beats repeated single-company calls. It stops short of explicit when-not-to-use or naming a sibling alternative.

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

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

Beyond the readOnly/idempotent annotations, it discloses behavior an agent would otherwise have to discover: total is always returned, the list defaults to 20 and caps at 50, results are ordered OEM and curated first, and calls consume the daily records quota. Quota cost and ordering are exactly the kind of operational detail annotations cannot express.

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 what the tool is and what it returns, then packs search semantics and quota notes into a tight block with no filler sentences. It is dense — several clauses compressed into one paragraph — but 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?

An output schema exists, so return-shape explanation is unnecessary; the description still covers quota cost, ordering, default and cap, and the fields searchable via q. For a read-only directory lookup with 5 optional params, nothing an agent needs 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?

Schema coverage is 80% and the schema already documents q, uf, layer and country, so the baseline is 3. The description adds real value on top: the exact fields q searches, that accents are ignored, sample queries, and the 20/50 limit behavior — though it says nothing extra about uf or country 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?

States a specific resource (a directory of companies accredited/registered to make or sell aircraft parts) and enumerates the source layers it covers. The closing line "It is a directory, not a stock check" explicitly bounds the purpose against a plausible misinterpretation.

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: the free-text q is described by what it matches plus worked examples ("pneus", "PT6A", "Pratt"), and the quota/ordering behavior tells the agent what to expect per call. It does not name a sibling alternative (e.g. jt_mro_capabilities or jt_company_search), so routing is implied 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 readOnly, idempotent, closed-world, non-destructive behavior, so the bar is low. The description adds real value beyond them by disclosing that the data is 'curated' rather than live, that it includes a research date, and that a missing curve is signaled with found=false rather than an error.

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 with zero filler; the resource and key are front-loaded before the return contents and the found=false caveat. The packed list of returned fields is slightly heavy but each 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 an output schema present, return values need not be re-explained, and annotations cover the safety profile; the description still adds the found=false semantics and data provenance. The only gap is how an agent obtains a valid slug or when to prefer this over the sibling listing/spec tools.

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

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

Schema description coverage is 100% with a single parameter, so the schema already documents 'slug'. The description only restates '(by slug)' and adds no format, casing, or sourcing detail (e.g., that the slug comes from jt_model_search), which is the baseline 3 case.

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 (curated pre-owned price curve for a catalog model, keyed by slug) and enumerates exactly what it returns: median/min/max, history by year, 5-year residual, research date. It is clearly distinct from sibling tools like jt_market_listings and jt_model_specs, though it never explicitly contrasts itself with them.

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 statement and no routing guidance versus alternatives such as jt_market_listings (live asking prices) or jt_model_specs. The 'found=false means no curated curve' note is a result condition, not 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial context beyond them: data source is the RAB changelog since 2026-02-03, filters run in the database, pagination caps at 200 with cursor, and truncated/found/total are precisely defined. It also discloses real limitations of the company filter (rabNamesMatched=0, minority co-owner blind spot, rows can predate arrival).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key exclusion are front-loaded, but the single dense paragraph packs caveats (companyMatch, rabNamesMatched, sameAirframeAs, co-owner blind spot) with little structural separation, and the airport-movement exclusion is restated at the end. Every detail is useful, but the wall-of-text form hurts 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?

For a filtered, paginated, caveat-heavy analytics tool with 11 parameters, the description covers the data window, filtering semantics, pagination and result-count semantics, and the known data-quality traps. Nothing an agent needs in order to interpret results 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 the schema baseline applies, but the description adds cross-parameter behavior the schema does not: the segment default flips to 'all' when registrations or cnpj is set, and cnpj matching includes historical owner/operator names plus current aircraft. It stops short of explaining limit/cursor interplay beyond the max-200 note.

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+scope: registry (RAB) changes between two dates, enumerating the five change types (entry, exit, owner_change, operator_change, status_change). It explicitly says 'not airport movements', which cleanly separates it from siblings like jt_movements and jt_ground_events.

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 when-not guidance: registry changes are not airport movements and not sales (points to the caveat field), which prevents the most likely misuse. It does not name the sibling tools to use instead (e.g. jt_movements, jt_market_listings), so routing 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 mark it read-only and idempotent, but the description adds substantial behavior: verdict categories, RBAC 91 vs RBAC 135 regimes, landing vs takeoff runway references, LDA-as-conservative-floor handling, binding leg, and AISWEB data date. This is rich behavioral context 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?

The purpose question is front-loaded, followed by dense but largely relevant details. Some output-field explanations could be left to the output schema, but most sentences help interpret the verdict and runway comparisons.

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 domain-complex feasibility check, the description gives enough to understand inputs, verdicts, regime distinctions, and runway-data semantics. With an output schema present, return fields need not be fully explained here.

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%, documenting both required parameters including slug formats and airport query forms. The description restates that airportQuery accepts ICAO/city/name but adds little parameter-level meaning beyond the schema, so 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 question and operation: compares a model's takeoff/landing distances with an airport runway, accepting ICAO, city, or name. This clearly distinguishes it from generic model and airport lookup 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?

Opens with the exact decision question ('Can this model operate at this airport?'), giving clear context for when to use it. It does not name alternative tools or exclusions, but the intended usage 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 readOnly/idempotent/non-destructive, so the burden is lower; the description goes further by disclosing the scoring model's inputs, the evidence[]/coverage[] output structure, and the conditional nature of the internal predictor. It does not state latency, rate limits, or behavior when data is missing beyond coverage[], keeping it shy of a 5.

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?

Single dense paragraph that front-loads the definition, then enumerates contributing signals, then closes with the crucial scope caveat. It is on the long side and the middle signal list could be trimmed, but 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, return values need not be explained, yet the description usefully explains what the score means and how evidence[]/coverage[] should be read. It is complete enough to invoke correctly; only explicit sibling routing is missing.

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

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

Only one parameter, and the schema already documents it at 100% coverage including the Brazilian registration format and length bounds. The description adds no syntax or format detail beyond the schema, 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 a specific verb+resource ('Score 0-100 of how likely one registration is to reach the market') and then explicitly bounds the claim ('It is not a prediction of sale: it ranks who to contact first'). The siblings contain no direct duplicate, so the lack of a named alternative is a minor gap rather than a confusion risk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — the closing sentence ('ranks who to contact first') hints at lead-prioritization use, but there is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as jt_aircraft_lookup or jt_owner_profile for raw facts. An agent can infer intent but must reason about 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 readOnly/idempotent/non-destructive, so the description's value is in the data provenance and scope it adds: official open data sources, monthly granularity, YTD-vs-prior-year comparison, chapter 88 FOB USD, and the explicit bound of 'the 100 aerodromes it reports'. It stops short of noting lag, revision, or coverage caveats for the datasets.

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 sentence: scope, sources, sub-topics, then the YTD comparison and the commercial/military qualifier. It is long for a single sentence and would scan better broken into trade/fuel/airports clauses, but every clause carries information and nothing is redundant.

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 and annotations covering the safety profile, the description supplies what structured fields cannot: sources, units (FOB USD, units, volume), the 12-month country window, aerodrome coverage limits, and the YTD comparison basis. The main residual gap is that it gives no hint of data freshness or how the three topics are combined when topic is omitted.

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. The description adds meaning beyond the schema by tying icao to 'the monthly series of one aerodrome' and clarifying that topic selects the underlying source (Comex Stat / ANP / CGNA) while omission aggregates all three. The months parameter's role is only lightly restated from 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 resource (Brazilian aviation sector indicators) and enumerates the exact content: chapter-88 trade flows, fuel volumes by distributor/state, and CGNA/DECEA aerodrome movements, with named sources (Comex Stat, ANP, CGNA). It does not explicitly contrast itself with siblings like jt_airport_traffic or jt_fuel_prices, which likely cover similar domains internationally, so an agent must infer the differentiation.

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 rather than stated: 'monthly', 'Year to date against the same months of the prior year', and the note that icao applies 'only with topic=airports or no topic' give practical constraints. There is no explicit when-to-use/when-not-use guidance or named alternative for narrower questions (e.g., use jt_airport_traffic for a single airport's non-Brazil data).

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