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: newest-first ordering, 200-per-call cap with nextCursor paging, partial coverage with a status model (never_seen/active/lost), arrivalConfidence values, and the caveat that roughly a third of flights end at strips without ground coverage. That is exactly the behavioral context an agent needs to interpret 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?

A single dense paragraph that front-loads the resource and period before enumerating return fields, confidence values, coverage states and paging. Every clause carries information, though the parenthetical lists make it slightly heavy to scan.

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

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

With an output schema present, return values need not be re-explained, yet the description still supplies the coverage caveat and confidence vocabulary. The only soft spot is the dangling 'see the caveat' reference, which points at guidance that is only partially spelled out in the description itself.

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 adds meaning the schema does not carry: the default and maximum window length (default 90 days, max 365) is stated in prose only, and it clarifies cursor pagination intent. Date and limit syntax remain schema-owned.

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: tracked flights of one Brazilian registration within a period, with the fields returned (departure, arrival, arrivalConfidence, duration). The scope 'one Brazilian registration' is precise, but no sibling tool is named to anchor the contrast with jt_aircraft_history or jt_movements.

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 intended use (flight history for a single aircraft) is implied by the description and the Italian-registration scope, but there is no explicit when-to-use guidance or when-not condition relative to jt_aircraft_history, jt_movements, or jt_ground_events. The agent must infer the selection.

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?

Annotations already cover read-only/idempotent safety, and the description adds genuinely new behavior: deterministic ordering by registration, nextCursor pagination, a 100-row cap, a daily quota that may truncate results (quotaTruncated), the counted-once semantics of sameAirframeAs, and the entitlement fallback when the account cannot list. That is substantial disclosure beyond the 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?

Front-loaded with purpose and the filter inventory, then limits/pagination. The single long enumerative sentence is dense but purposeful; the sentence describing row payload (ownerRecords, ownerRole, riskFlags, sameAirframeAs) is partly redundant against the existing output schema, which is the only real waste.

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

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

For a 24-parameter, zero-required search tool with an output schema, the description covers the dimensions an agent actually needs: how filters compose, sensible defaults, result caps, pagination token, quota behavior, and a documented limitation. Nothing needed 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 baseline is 3, but the description adds real meaning: it explains that 'model' and 'models' are alternatives (single vs union of up to 30), that category accepts either a coarse group or a fine category, and that segment 'all' pulls in airliners and general aviation. Most other filters merely restate the schema, keeping it out of the 5 band.

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 Brazilian-registered aircraft by COMPOSED filters'), which immediately separates it from the global sibling jt_global_fleet_search and from single-aircraft tools like jt_aircraft_lookup. The scope (one call per question, composed filters) tells an agent exactly what class of question it answers.

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: 'one call per question' with composed filters, the default executive segment, and the explicit exclusion 'Filtering by a person's name is not available' plus the fallback 'preview.total still says how many aircraft match'. It does not, however, name a sibling alternative (e.g. use jt_global_fleet_search for non-Brazilian registrations), so routing is inferred rather than stated.

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

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

Annotations already declare 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?

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 carry readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: pagination via offset/nextOffset, the returned field set, and the caveat "Zero results is not proof of absence" — a subtle but valuable caveat about incomplete matching.

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 primary search inputs before category, then pagination and return fields. Every clause carries information; it is slightly packed but never padded or 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?

An output schema exists, so return values needn't be enumerated, yet the description still names the key fields and adds the pagination contract and zero-result caveat. Combined with the annotation safety profile and full schema coverage, an agent has enough to call this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds value by translating the Portuguese enum values (jato = jet, helicoptero = helicopter, turboelice = turboprop, pistao = piston) into English meaning, and by clarifying that offset continues from the previous page's nextOffset. This exceeds what the terse schema descriptions convey.

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

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

States a specific verb and resource ("Search Jet Tracker aircraft models") and enumerates the exact text inputs accepted — manufacturer, model, ICAO designator — plus a category filter. This clearly distinguishes it from siblings like jt_model_specs (spec detail) and jt_fleet_search (ownership/fleet), which an agent could otherwise confuse.

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 patterns via query examples ("piper", "meridian", "E55P") and maps category enums to English meanings, which tells the agent how to construct calls. It also signals this is the entry point by noting "The slug is the model id the other tools accept", but never explicitly names an alternative tool or a when-not-to-use condition.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: it explains that matchedBy reports how the slug was resolved, exposes costModelVersion, and pins the cost figures to the Jet Tracker model page and jt_compute_tco assumptions.

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

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

One dense sentence but front-loaded with the primary resource and outputs, followed by the cost detail and consistency claim. Every clause carries information, though the packing is heavy enough that a reader must parse carefully.

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 shapes need not be enumerated, and the description still names the key distinguishing fields (matchedBy, costModelVersion). It is complete enough to call correctly; the only gap is the missing routing guidance relative to jt_model_search and jt_compute_tco.

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% (baseline 3), and the description goes beyond the schema by stating that the slug accepts a slug, family slug, slug with or without manufacturer prefix, or a name—an important input-flexibility detail the schema 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 (technical specs of a catalog model) plus the bundled operating-cost outputs (variable cost/hour, fixed cost/year, total at 400 h/yr, acquisition curve). An agent can tell it apart from jt_model_search and jt_compute_tco, though it never explicitly contrasts itself with those siblings—it only claims numeric consistency 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?

Usage is implied by the content (need specs and canonical cost numbers for one model), and the mention that the numbers match jt_compute_tco assumptions hints at the relationship. However there is no explicit when-to-use / when-not guidance, no statement of when to prefer jt_model_search or jt_compute_tco instead.

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

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

Annotations 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?

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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description goes well beyond them: the data source's start date (2026-02-03), that filters run in the database, that 'found:false' means zero across the whole period, that 'truncated' means more pages via nextCursor, the 200-row cap, and the sameAirframeAs de-duplication rule. This is exactly the operational context 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?

Information-dense with no filler sentences, and the core scope ('registry changes, not movements') is front-loaded. It is a long single block that could be split for scanability, but every clause carries a distinct constraint.

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

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

With an output schema present, the description need not explain return values, and it still supplies the pagination model, count semantics, de-duplication caveat, and the sale-versus-registry distinction. Nothing an agent needs to call or interpret 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 description coverage is 100%, so the schema already documents every parameter including the enum meanings and the default executive segment. The description restates the filter set and default without adding syntax or format beyond 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 and resource ('Changes in the Brazilian REGISTRY (RAB) between two dates') and immediately enumerates the resource scope (entry/exit/owner_change/operator_change/status_change). It explicitly distinguishes itself from siblings by declaring it is 'not airport movements', which an agent can use to separate it from jt_movements 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?

Gives explicit exclusions that route the agent to alternatives: 'not airport movements' and 'A registry change is NOT a sale (see the caveat field)'. Combined with the enumerated change types and the note that filters default to executive, the agent knows both when to use this and when to reach for a different 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 cover the safe-read profile (readOnly, idempotent, non-destructive). The description adds genuinely non-obvious behavior: the RBAC 91 vs RBAC 135 60% landing-factor distinction and the split verdictByRegime. It stops short of disclosing input-matching behavior or error/unknown 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?

Front-loads the core question, then compresses distance comparison, verdict values, and regime breakdown into a short block. Slightly dense with output-enum detail, but no filler 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?

The tool has an output schema, so the description is not obligated to explain return values, yet it usefully explains what verdict values mean. For a two-param, read-only feasibility check, the agent has everything needed to invoke and interpret it.

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

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

Schema description coverage is 100%, so both slug and airportQuery are already documented in the schema, including the ICAO/city/name acceptance. The description restates that airportQuery can be 'ICAO, city or name' but adds no format or matching guidance beyond the schema.

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

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

The description opens with a precise question ('Can this model operate at this airport?') and then states the actual operation: comparing model takeoff/landing distances against the airport runway. No sibling tool in the list performs runway feasibility, so the agent can route here unambiguously.

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

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

The stated question frames the use case clearly, and the verdict enumeration tells the agent what situation this tool resolves (private vs air-taxi feasibility). It does not name an alternative or a when-not condition, so it falls short of the top band.

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 readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description adds genuine context by disclosing that callable tools are scoped to the API key and that quota has used/remaining/resetAt in UTC. It does not state whether calls are counted against quota or any auth/permission requirements beyond the key, leaving a small 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?

A single sentence, front-loaded with the core purpose ("Health of the Jet Tracker data behind the tools"). The long parenthetical list of sources is dense but ordered and scannable; slightly more than needed given the enumeration is also implied by the 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 description need not explain return values, and it correctly focuses on scope and the identity of the data sources. The only shortfall is the absence of usage guidance (when to call it relative to other tools), which a status tool would benefit from.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what is already implied. No parameter meaning is missing because none exist.

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: reports the health/freshness of the Jet Tracker dataset behind the tools. It enumerates the concrete payload (per-source last sync and lag, coverage, callable tools, quota) so an agent can immediately distinguish this meta/status tool from the 39 data-querying siblings.

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

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

Usage is only implied: an agent can infer it should be called to check freshness or remaining quota before/around data calls, but the description never says when to use it versus alternatives or any precondition. No exclusions or alternatives are named.

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 the safe read/idempotent profile, and the description adds real behavioral detail beyond them: the cost basis distinction (owned models yield variable cost only), the inclusion of distance and block time in the result, and the degenerate_route error when origin equals destination. It does not cover casing/normalization of city names or rate/unit behavior, keeping it 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?

Two compact sentences with the core purpose front-loaded and the error condition placed at the end where it belongs. The middle clause listing the three model categories makes it slightly dense but every phrase carries information.

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

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

With an output schema present, the description needn't explain return shape, yet it still names the key outputs; parameters and annotations are covered. For a 4-parameter read tool this is nearly complete, with only the cross-tool selection guidance and parameter-format details missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the description largely restates them (ICAO or city names, full cost profile model). It adds marginal value — the 'variable cost only' caveat for owned models — but does not explain the roundTrip default or naming/alias semantics beyond what the schema shows. Baseline 3.

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

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

The description states a specific verb and resource — 'cost of a trip origin to destination' — and enumerates the model categories (charter, fractional, owned) plus the returned metrics (distance, block time). It is clearly distinguishable from generic lookup siblings. It stops short of a 5 because the sibling relationship is only implied via the alias reference to jt_compute_tco rather than an explicit contrast of scope.

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 wording (compute a route cost for a model with a full cost profile) and the error precondition 'origin equal to destination returns error degenerate_route' is a useful guard. However, there is no explicit guidance on when to choose this over jt_compute_tco or jt_fractional_fit, which share cost-profile territory.

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

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

Goes well beyond the annotations by disclosing partial-success semantics (invalid[] and alreadyWatched[] arrays), the 500-registration capacity ceiling, and the auth requirement (OAuth or account key, not a system key). The additive behavior is consistent with destructiveHint=false and idempotentHint=true, so there is no annotation contradiction. It stops short of describing ordering or exactly how many succeed per call.

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 semantic (additive, unlike jt_watch_set) and then layers failure modes, capacity, and auth in three compact clauses with no filler. The heavy parenthetical and dense punctuation make it slightly harder to scan than an ideal definition, but 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?

Covers the sibling distinction, the mutation's additive scope, auth prerequisites, capacity limits, and partial-failure outcomes, even though an output schema exists to document the return arrays. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema coverage is 100% and the single parameter's format notes (hyphen-optional, any case) live in the schema already. The description only reinforces the parameter indirectly via the 500-item cap, which mirrors maxItems. Baseline 3 is appropriate when the schema carries the parameter detail.

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

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

States a specific verb and resource ("add registration(s) to this account's watch list") and immediately distinguishes itself from jt_watch_set, the sibling that replaces the whole list. An agent can route between the two without opening either schema.

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

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

Explicitly names the alternative (jt_watch_set) and the condition that selects this tool over it: additive vs. whole-list replacement. It also states the account-connection prerequisite, so preconditions are covered rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the auth requirement (OAuth or account key, explicitly not a system key) and the fact that this list gates which registrations trigger webhook changes. Return format is not described, but the output schema exists.

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

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

Two sentences, front-loaded with the identity of the resource and followed by the auth constraint; no filler. It is slightly dense (the parenthetical field list is compressed) 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?

For a no-parameter, read-only list tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: what the list contains, why it matters (webhook gating), and the non-obvious connection requirement. 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?

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. Nothing in the description is needed to clarify inputs, and nothing contradicts the empty object 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 precisely what the tool returns ('Registrations this account watches') and explains the role of the list in the webhook flow, which is more than a restatement of the name. It does not, however, explicitly distinguish itself from the near-name sibling jt_watch_rules_list, leaving an agent to infer that 'rules' and 'watched registrations' are different collections.

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 through the webhook explanation ('the webhook delivers a change ... only for tails in this list') plus a clear connection prerequisite, so an agent understands the context in which this list matters. But there is no explicit when-to-use/when-not statement and no routing to siblings such as jt_watch_rules_list or jt_watch_add/jt_watch_remove for modifying the list.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is covered. The description adds genuinely new behavior: partial-failure semantics ('Invalid registrations come back in invalid[]') and the auth requirement (account connection via OAuth/account key, not a system key).

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 short sentences, front-loaded with the action and its scoping guarantee, then the failure-mode note, then the prerequisite. No sentence 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 annotations covering safety/idempotency, an output schema covering returns, and 100% parameter coverage, the description supplies exactly the missing pieces: auth requirements, non-clobbering scope, and partial-failure handling. Nothing an agent needs 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 description coverage is 100% for the single parameter, including format and min/max constraints, so the schema carries the load. The description adds no format or syntax detail beyond it, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Remove registration(s) from this account's watch list') and scopes it precisely with 'WITHOUT touching the rest', which distinguishes it from whole-list siblings like jt_watch_set and jt_watch_add.

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 'WITHOUT touching the rest' clause implicitly tells the agent to prefer this over a set/replace operation when removing a subset, and the auth sentence establishes the connection prerequisite. It stops short of naming jt_watch_set or jt_watch_remove_rule as the explicit 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, and the description adds genuinely new behavior: what happens when all filters are null (whole live fleet), what dryRun does ('only returns preview.count ... without saving'), the exact deliverable events, and a real auth constraint (account connection, not a system key). This is substantive disclosure beyond the 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?

A single dense paragraph that is front-loaded with the purpose, then filter semantics, dryRun behavior, and the auth prerequisite, with no filler sentences. It is slightly packed with semicolon-separated clauses, which costs it the top mark but nothing is wasted.

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

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

An output schema exists, so return values need not be detailed, yet the description still explains the one meaningful response mode (dryRun returning preview.count). Combined with the null-filter behavior, event list, and auth requirement, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot express: every field is optional, null means no filter, and at least one of the four filter fields should be set. It also enumerates the valid eventTypes inline. The per-parameter descriptions already carry the field-level meaning, so it is not a full 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 ('Create a watch rule by profile') and its scope (profile-based rather than aircraft-based), which implicitly separates it from jt_watch_add. However, no sibling is named, so an agent must infer the distinction from the 'by profile' phrasing rather than being told.

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: at least one of modelFamily/uf/category/rbac should be set or the rule watches the whole live fleet, and it explicitly notes the account-connection prerequisite ('OAuth or an account key, not a system key'). It does not explicitly route between this and jt_watch_add / jt_watch_set, so it stops short of the top score.

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 destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is covered structurally. The description adds real value beyond that: the mutation is narrow (profile rules only, not explicit registrations) and requires an account connection/OAuth rather than a system key, which is an auth constraint 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 short sentences, front-loaded with the core action and scope, then the non-effect, then the auth requirement. No filler or restatement of the title.

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

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

An output schema exists, so return values need no explanation. The description covers the action, the id source, the scope boundary versus sibling watch tools, and the auth requirement — everything needed to call this destructive one-param tool correctly.

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

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

Schema description coverage is 100% and the single id parameter is documented in the schema, so the description's mention that ids come from jt_watch_rules_list largely duplicates the schema text. 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 verb and resource ('Delete a watch-by-profile rule by id') and immediately scopes it against the neighboring concepts (explicit registrations from jt_watch_set/jt_watch_add). An agent can distinguish this from jt_watch_remove and jt_watch_rule_add 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?

Tells the agent where the required id comes from (jt_watch_rules_list) and explicitly what this tool does NOT affect (explicit registrations), which is the key routing distinction among several watch-related siblings. The auth prerequisite is stated as a condition on use.

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), and the description adds real behavior beyond them: the additive (never replacing) semantics relative to jt_watch_list, the 50-rule cap, retroactive matching of tails registered after rule creation, and the auth requirement (account OAuth/key, not a system key). Those are exactly the operational facts an agent cannot infer from 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?

One dense but well-ordered sentence that front-loads the core definition, then layers scope distinctions, cardinality limit, and auth prerequisite. Every clause 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?

With an output schema present (so return values need no explanation), zero parameters, and annotations covering safety, the description supplies the remaining essentials: what a rule matches, the 50-rule ceiling, the additive relationship to the explicit watch list, and the required credential type. Nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate — the baseline of 4 applies. The description correctly implies the account scope comes from the connection rather than an argument.

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 ('rules this account uses to watch aircraft BY PROFILE') and immediately enumerates the profile dimensions (model family, owner state, category, RBAC classification). It explicitly contrasts the scope with 'one registration at a time', which cleanly separates it from the sibling jt_watch_list.

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 that this complements rather than replaces jt_watch_list ('Adds to (never replaces) the explicit list from jt_watch_list'), which is exactly the routing information an agent needs. It also states the connection prerequisite. It stops short of saying when the tool should not be used or pointing to jt_watch_rule_add for rule creation.

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 destructive=true and idempotent=true; the description reinforces replace semantics and adds non-annotation context: OAuth/account-key auth requirement, the 500 cap, partial-failure behavior (invalid[] returned, rest saved), and the downstream webhook event catalogue. It does not detail reversibility or rate limits, but that is a minor gap against an otherwise rich disclosure.

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

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

Information-dense and front-loaded with the core replace semantics, then auth/limits/errors. It is a single very long sentence-chain, which slightly hurts scanability, but every clause carries real 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 and full annotations present, the description only needs to supply the operational extras — auth mode, cap, partial-failure handling, webhook consequences — and it does all of them. Nothing an agent needs to invoke this destructive bulk-set 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 is fully documented in the schema, so the baseline is 3. The description adds the 500-item ceiling and the fate of invalid entries, which is behavior rather than new per-parameter syntax, so it does not exceed the 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 specific verb (Replace) and resource (the account's whole watch list), with the scope word 'whole' making it clearly distinct from the additive jt_watch_add and subtractive jt_watch_remove siblings. An agent can route correctly 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?

Implies the right context (bulk-set semantics vs. incremental add/remove) and explicitly states the required account connection and that a system key will not work. It does not name an alternative tool or a when-not-to-use case, so it stops short of full routing guidance.

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