Jet Tracker

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description adds genuine algorithmic context: the midnight-counting definition, the ongoing-stay edge case (ongoing=true, counts up to now), the overnightEvents threshold, and the confidence heuristic scaled by nights tracked. The 'three facts can disagree' disclosure is distinctive and prevents an agent from over-trusting inferredBase.

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

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

Every named term earns its place — each is an output field the agent will encounter — and the purpose is front-loaded. However, it is one dense run-on paragraph with multiple nested parentheticals, which hurts readability; splitting the field definitions into separate sentences or lines would make it substantially clearer.

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 format is already documented elsewhere. The description fills in what the schema cannot: the counting algorithm, the ongoing-stay edge case, confidence semantics, and the honesty caveat about disagreeing facts. Minor terms like 'share' are mentioned without elaboration, relying on the output schema, which is acceptable.

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

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

Schema description coverage is 100%: registration already has format and length bounds, days already has range and default. The description echoes 'default 365' and 'one registration' but contributes no new meaning 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 states a specific deliverable — 'Overnight ranking of one registration over N days' — and enumerates the output facts (nights, overnightEvents, hubIcao, owner city, inferredBase, confidence). The 'where is this aircraft based' framing clearly separates it from movement-focused siblings like jt_aircraft_flights and jt_aircraft_history.

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

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

The description explicitly declares the question it answers ('Answers "where is this aircraft based"') and even warns that the three facts can disagree, giving an agent clear context for when to invoke it. However, no sibling alternative is named and no when-not-to-use exclusion is stated, so it falls short of a 5.

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

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

Adds substantial behavior beyond the read-only/idempotent annotations: newest-first ordering, max 200 per call, pagination via nextCursor, and a notable data-quality caveat about partial coverage and flights ending at strips without ground coverage. This gives the agent important expectations about result completeness.

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

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

The description is dense but well-organized: core scope first, then output highlights, then pagination/limits, then a caveat. Every sentence adds value and there is no filler or repetition of annotations.

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 paginated list tool with a rich output schema, the description covers all essential operational details: defaults, maximums, ordering, pagination, and data reliability caveats. An agent can call this correctly and interpret results accurately without further hunting.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter context on top: the 90-day default and 365-day maximum range, the per-call limit of 200, and the pagination mechanism tied to nextCursor. These details go beyond what the schema itself states.

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 uses a specific verb and resource: 'Tracked flights of one Brazilian registration in a period', with a clear list of returned fields. It does not explicitly contrast itself with sibling tools like jt_aircraft_history, so it misses the top score for sibling differentiation, but the purpose is unmistakable.

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 clearly defines when the tool applies: one Brazilian registration, a date range, with default and maximum boundaries, ordering, and pagination. It does not name alternatives or exclusion conditions, but the context is explicit and actionable enough for an agent to select 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?

The annotations already mark the tool as read-only and idempotent, but the description adds substantial behavioral nuance: timeline entries represent monthly RAB snapshots where ownership/operator changed, the first entry is a marker rather than an event, dates are observation dates rather than exact change dates, and FAA country matching requires both N-number and serial. It also discloses that natural-person names may appear while CPF numbers never will. This goes well beyond the annotations and prevents misinterpretation of returned data.

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

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

The description is dense but every sentence earns its place: main purpose is front-loaded, followed by critical data-currency caveats and provenance constraints. Despite its length, it is efficiently structured with semicolons and parentheticals, and it avoids repeating schema or annotation 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?

For a single-parameter, read-only historical tool with an output schema present, the description covers all essential contextual gaps: what timeline[] contains, how first_seen works, how dates should be interpreted, when foreignOrigin and country are populated, and privacy behavior. An agent has enough to call the tool correctly and interpret results reliably.

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

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

The input schema has one parameter, registration, and its description fully covers format, hyphen/case flexibility, and examples. The tool description does not need to repeat those details and does not add parameter-level semantics, so the baseline of 3 is appropriate since the schema carries the full burden.

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 specific verb and resource: it returns an ownership/operator timeline for a Brazilian-registered aircraft by matricula, plus foreign-origin and accident/incident data. This clearly separates it from the many sibling lookup/fleet/registry tools, which focus on current data, searches, or aggregates.

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

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

The description makes it obvious this is the historical-timeline tool: 'Ownership/operator timeline' is placed first and the content is framed around historical snapshots and provenance caveats. It does not explicitly name alternatives or say 'do not use for current registry data', but the context is clear enough for an agent to choose it over current-state lookup 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 cover read-only, idempotent, and non-destructive behavior, so the description rightly focuses on additional context. It adds valuable behavioral details: the RAB has no base city or airport, the owner city is found in owner.rfb.municipio, and the value-reference confidence is based on vintage or model_range. No contradiction with annotations.

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

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

The description is long but front-loaded with the core purpose and then a dense, relevant list of profile fields. The second sentence is a necessary caveat about the RAB's lack of a base city. It could be slightly tightened, but every clause contributes useful information.

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

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

Given the tool's high output complexity, the description covers all major return domains and an important data caveat. An output schema exists, so detailed return structure is already provided elsewhere. Nothing essential for invoking the 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 baseline is 3. The description reinforces the registration format with prefix examples (PR-XXX, PT-XXX, PP-XXX, PS-XXX) and the term matricula, but the schema already documents hyphen/case flexibility and the detail enum. No significant new parameter meaning is added 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 'Full profile of a Brazilian-registered aircraft by its registration mark', naming a specific resource and lookup action. It enumerates the profile contents (RAB status, model, owner set, operator, lien, airworthiness, flight activity, market presence, value reference) and the valid registration prefixes, clearly distinguishing it from US lookup, fleet search, and batch siblings.

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

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

Usage is implied rather than explicit: the description says this is a full profile by registration mark, so an agent can infer it is for a single known Brazilian registration. However, it does not state when to prefer this over jt_aircraft_lookup_batch, jt_aircraft_base, jt_aircraft_history, or jt_us_aircraft_lookup, nor does it give exclusion criteria.

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

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

Beyond the annotations, which already mark the operation as read-only and non-destructive, the description discloses per-item found:true/found:false behavior, compact detail as the default, and the quota cost of one lookup per registration. These are meaningful operational traits that an agent needs to predict behavior and avoid surprises.

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, no filler, and the most important scoping information (same profile, max 25, compact default) is front-loaded. The later sentences cover result shape and quota impact, each earning 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 a high-coverage schema, an output schema, and annotations covering safety and idempotency, the description only needs to add batch-specific context. It provides the limit, result semantics, and quota effect, making the tool fully actionable for an agent.

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 schema already provides 100% parameter coverage, including the registrations array format, validation behavior, duplicate handling, and the compact/full enum. The description adds little beyond restating the default compact detail and the maximum batch size, which are already present in 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 names a specific action (batch aircraft lookup), a specific resource (Brazilian aircraft registrations), and a clear batching limit. It also explicitly frames itself as the batch counterpart to jt_aircraft_lookup, which distinguishes it from that sibling tool without requiring schema inspection.

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?

"Same profile as jt_aircraft_lookup for up to 25 registrations in one call" clearly indicates this tool is for batch lookups, implicitly setting the alternative as the single-registration tool. It does not explicitly say "use jt_aircraft_lookup for a single registration," but the contrast is strong enough to guide 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?

The description adds substantial behavior beyond the readOnly/idempotent annotations: it explains the exact ranking order, how rankingReason and alternatives[] resolve ambiguous matches, the Brazil-first bias, and warns about missing data for small strips. This is exactly the kind of operational context an agent needs.

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

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

The description is dense but well-organized: it front-loads the core function and outputs, then presents ranking and caveats in order of importance. Every sentence carries real information and nothing is padding.

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

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

There is an output schema, so return details are covered, and the description fills in the remaining operational context: query types, ranking logic, ambiguity handling, and data completeness. For a one-parameter read-only lookup, this is complete enough for reliable use.

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 schema already covers the query parameter well, but the description adds meaning by spelling out the full accepted forms (ICAO, IATA, city, name) and by explaining how ambiguous queries are ranked. This goes beyond the schema's single example and improves selection of the right query string.

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 specific verb and resource: 'Find an airport by ICAO code, IATA code, city or name' and lists the returned fields. This clearly separates it from sibling tools focused on aircraft, fleets, or runway checks, even without naming 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?

The description makes the intended use obvious through accepted query types and the ranking behavior, including a caveat that many small strips lack ICAO or runway data. It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the agent already knows it's safe. The description adds valuable behavioral details: data source (ADS-B/FR24), partial coverage (explicitly noted), definition of nights, overnightEvents, relation categories, ordering logic, and pagination. It doesn't contradict annotations and enriches the agent's understanding of what the call will return and its limitations.

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

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

The description is a single dense paragraph that packs many details (data source, metrics, ordering, pagination, coverage caveat, differentiation). While every sentence carries useful information, the structure is not front-loaded beyond the opening question, and the dense phrasing could be improved with bullet points or clearer segmentation. It's acceptable but not a model of conciseness.

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

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

Given the tool's complexity (6 parameters, output schema exists, annotations cover safety), the description covers all essential aspects: data source, coverage limitations, metric definitions, ordering, pagination, and the conceptual scope. The only minor gap is that it references 'the caveat' but doesn't fully explain the caveat's content within the description. Otherwise it's thorough enough for an agent to know how to call and interpret 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% – every parameter has a clear description. The tool description doesn't add per-parameter semantics beyond what the schema already gives (e.g., date ranges, ICAO format, limit max). The description mentions defaults and max but these are also in the schema. Baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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 pair: 'Which aircraft arrived at or departed from an airport (ICAO) in a period'. It then enumerates the exact metrics (arrivals, departures, nights, relation, etc.) and explicitly contrasts with lookup tools by saying it answers 'who flies to my region' not 'who is registered in my city'. This makes the tool's purpose unambiguous and distinct from the many sibling tools like jt_aircraft_lookup or jt_owner_fleet.

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

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

The description provides concrete usage context: default period, max range, ordering, pagination, and a coverage caveat. It indirectly differentiates from alternatives by stating what question it answers, though it doesn't name specific sibling tools or list explicit when-not-to-use scenarios. The guidance is clear enough for an agent to select it appropriately.

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, and non-destructive, and the description adds extensive behavioral detail: ranking by confidence, matchReason in Portuguese, coverage limitation, hasAircraft field, conditional economic group inclusion, and ignoring personal email domains. It also notes max 10 candidates. No contradiction with annotations.

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

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

The description is moderately long but every sentence contributes essential information: purpose, coverage scope, ranking details, and limitations. It is front-loaded with the core function and then layers specific constraints. It could be slightly more compact, but the density is justified by the tool's complexity.

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

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

Given the tool's complexity (6 optional parameters) and the presence of an output schema (so return format is covered), the description covers all necessary aspects: input types, matching behavior, ranking, coverage constraints, and conditional outputs. It even explains the economic group dependency on a plan. No critical gaps remain for an agent to correctly invoke the tool.

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

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

The input schema already provides descriptions for all six parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema: it explains that accents, case, and legal suffixes are ignored for the name query, and that personal email domains are ignored for the domain parameter. It also clarifies that q can be a CNPJ/8-digit root for direct lookup. This adds value, but not exhaustive elaboration on every parameter.

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

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

The description clearly states the tool's function: it returns candidate Brazilian companies (CNPJ) given a company name or email/website domain, ranked by confidence. It distinguishes itself from the many aircraft-focused siblings by explicitly focusing on company identification for leads. The coverage limitation (only aircraft-linked companies) is also specified, which is a critical differentiator.

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 states when to use this tool: 'Built for leads that give a company name or a corporate email but no CNPJ.' It also provides an exclusion: coverage is limited to aircraft-linked companies, so an empty list indicates no known aircraft link, implying it's not for general Brazilian company lookup. This gives clear context for choosing this tool over others.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description adds substantial behavioral detail: sign convention for cashflows, output components (average annual/hourly cost, NPV, year-by-year cashflows), assumptions sourced from the same engine as jt_model_specs, fractional hours included, currency, and default Brazilian opportunity rate. No contradiction with annotations.

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

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

The description is three dense sentences with no filler. It front-loads the core purpose and outputs, then packs assumptions, aliases, and currency/default details efficiently. Every clause earns its place.

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

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

Given the tool's complexity, the description covers inputs, outputs, assumptions, sign convention, currency, defaults, and alias resolution. An output schema exists for return shape, so the description does not need to repeat return fields. Nothing essential for selecting or invoking the 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 baseline is 3. The description adds value beyond the schema by giving concrete alias examples (phenom-300, embraer-phenom-300e, hawker 400xp), noting that comparadorProfiles in jt_model_search lists the five profiles, and clarifying that the model must have a full cost profile.

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 specific verb and resource: 'Total cost of ownership across FIVE operating models' and enumerates exactly what is computed. It also distinguishes itself from siblings by naming jt_model_specs as the canonical cost engine and jt_model_search as the source for the five profiles, so an agent can tell it apart from related lookup/spec tools.

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

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

The description gives clear context for when this tool is appropriate: it requires a model with a full cost profile and accepts catalog slugs or aliases, with jt_model_search listing the five profiles. It does not explicitly state when not to use it or name direct alternatives, but the references to jt_model_specs and jt_model_search provide enough routing guidance.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: it matches by serial plus compatible manufacturer/model, and warns that serial numbers repeat across models. This is meaningful context for interpreting 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?

Three sentences with no filler. Input scope, matching behavior, and the critical caveat are each given one sentence, with the most decision-relevant information front-loaded.

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 tool with an output schemacans available, the description covers accepted inputs, country scope, matching logic, and the serial-repetition caveat. The only slight gap is that 'see the caveat' is referenced without the full caveat being spelled out, though its substance is effectively stated in the preceding clause.

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 schema already describes 'query' as a registration mark or serial number, so the baseline is 3. The description adds value by enumerating accepted formats (Brazilian PR-/PT-, US N-number, CA/AU/NZ/MX) and explaining that serial matching is qualified by manufacturer/model compatibility.

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 uses a specific verb ('find'), names the resource ('same airframe in the other registries'), and explicitly lists the six covered registries. It also distinguishes itself from single-registry lookups by focusing on cross-registry matching, making it difficult to confuse with siblings like jt_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?

The description clearly states the intended use case: tracing an aircraft between countries by registration or serial. It does not explicitly name alternatives or say when not to use it, but the cross-registry scope and matching caveat provide clear context for when it is appropriate.

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, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: deterministic order by registration, pagination via nextCursor, max 100 per call, daily plan quota may truncate (quotaTruncated), and the preview.total behavior when the plan blocks the list. It also discloses the default segment and the meaning of segment 'all'. This is rich, non-obvious behavior that an agent needs to interpret results correctly.

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

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

The description is a single dense paragraph that front-loads the core purpose and then enumerates filters. It is long, but the tool has 24 parameters and complex semantics (quota truncation, preview.total, segment defaults), so the length is justified. It could be slightly better structured with separators, but every sentence earns its place and the most important operational facts (one call per question, max 100, pagination, quota truncation) are present.

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

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

Given the tool's complexity (24 parameters, output schema present, annotations covering safety), the description is nearly complete. It covers the composed-filter model, pagination, quota truncation, defaults, and exclusions. The output schema exists, so return values need not be described. Minor gaps: it doesn't explain the 'program field' referenced in the rbac schema description, and it doesn't detail how multiple filters combine (AND vs OR), though 'COMPOSED filters' implies conjunction. These are small relative to the overall completeness.

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 24 parameters. The description adds some semantic value by grouping filters into a composed-query mental model and clarifying the 'one call per question' usage, plus a few cross-parameter hints (e.g., cva + cvaDays, hours365Min/Max, idleDaysMin/Max). However, most parameter-level meaning is already in the schema, so the description's added value is modest. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List Brazilian-registered aircraft by COMPOSED filters, one call per question.' It enumerates the filter dimensions and distinguishes this tool from siblings like jt_global_fleet_search and jt_us_aircraft_lookup by the 'Brazilian-registered' scope. The title 'Search the Brazilian fleet' is expanded into a precise, actionable statement.

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

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

The description explicitly says 'one call per question' and lists the filter dimensions, which tells the agent when to use this tool: when the question is about Brazilian-registered aircraft and can be answered with a single composed query. It also states what is NOT available ('Filtering by a person's name is not available') and notes the default segment and the 'all' option, which helps the agent decide whether this tool fits. It doesn't name a specific alternative tool, but the sibling list provides context and the description's scope statement ('Brazilian-registered') is enough to route away from jt_global_fleet_search and jt_us_aircraft_lookup.

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

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

The description goes far beyond the annotations (read-only, idempotent) by explaining the semantics of the two rulers (registryTotal vs alive), deduplication by serial, and the meaning of byRbac splits and as_of/source/scope. It also clarifies 'Live count, not a survey,' adding behavioral nuance. No contradiction with annotations.

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

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

The description is dense but well-structured, starting with the purpose, then explaining the key metrics and fields. It is informative without redundancy, though slightly lengthy; given the complexity of the output, it's appropriate.

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 focuses on semantics. It covers all major aspects: the two counts, deduplication, splits, and metadata fields. It doesn't mention error conditions, but for a read-only stats tool with one parameter, this is sufficient. Very complete.

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

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

The schema only says 'Slug do modelo.' The description adds that the slug can be an alias, refers to the whole family, and that model.matchedBy indicates resolution. This adds meaning beyond the schema, exceeding the baseline of 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 resource: Brazilian fleet stats for a catalog model, with the verb implied (fetches/stats). It distinguishes itself from the global sibling by 'Brazilian' and clarifies the resolution mechanism (model.matchedBy) and output fields, making the purpose unmistakable.

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 context is clear—this is for Brazilian fleet stats—and the presence of jt_global_fleet_stats implies a distinction. However, it doesn't explicitly state when to use this vs alternatives or provide exclusions, relying on the 'Brazilian' qualifier and sibling naming.

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

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

Annotations already mark the tool as read-only and idempotent, and the description goes further by explaining that the score is a transparent sum of public-record evidence, that evidence[] carries per-fact weights, and that coverage[] documents missing inputs. It also adds the caveat that the result is heuristic and not an appraisal or offer, which accurately sets expectations beyond the structured annotations.

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

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

The description is compact but information-dense, front-loading the action and scope, then listing contributing factors, naming the output fields, and ending with limitations. Every sentence earns its place and there is no filler or duplication of the schema.

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

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

For a single-parameter read-only scoring tool, the description covers what the score means, which inputs feed it, what output fields to expect, and the key caveat. The existing output schema handles structured return details, so the remaining gaps such as explicit sibling routing are minor and already reflected in other dimensions.

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 parameter already has a clear format description ('Brazilian registration (PR-TBL).'). The description only refers generically to 'one registration' and adds no registration-specific constraints or format details, so it does not need to compensate for schema gaps.

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 specific verb and resource ('Score 0-100 of how well one registration fits...') and enumerates the input factors and output semantics. It is unmistakably about per-registration fit, but it does not explicitly contrast itself with sibling tools such as jt_fractional_market or jt_sale_propensity, so it stops short of full sibling differentiation.

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

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

The description implies the use case by saying it scores fit for fractional/shared-ownership and adds an exclusion ('It is a heuristic fit, not an appraisal or an offer'). It does not explicitly say when an agent should prefer this tool over sibling tools like jt_fractional_market, nor does it name alternatives. This is implied usage rather than explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description goes further by explaining the data provenance (EA from SEI documents authorizes models, not tails; fleet counts from RAB cross-referenced by CNPJ root) and the meaning of 'monitored' operators (never certified, certified:false). This adds valuable behavioral context about data limitations and the distinction between certified and monitored operators.

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

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

The description is detailed but efficient: it opens with a clear purpose, enumerates the views, explains the filtering mechanism, and clarifies data semantics. Every sentence adds value—the EA vs. RAB distinction and the monitored operator caveat are crucial for correct interpretation. The structure is well-organized, making it easy to scan for key information.

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

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

Given the tool's complexity (multiple views, pagination, data provenance, operator filtering), the description is remarkably complete. It explains the data sources, the distinction between EA and fleet counts, the certified/monitored flag, and the pagination mechanism for the aircraft view. With an output schema present (though not shown), the agent has everything needed to call the tool correctly without additional inference.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and their constraints. The description adds a little extra by clarifying the `operator` parameter accepts slug, brand, legal name, or CNPJ/root (though the schema also says this) and that `limit` and `cursor` are aircraft-only. Overall, the description does not significantly enhance parameter meaning beyond the schema, 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?

The description clearly states this is a market-level view of the Brazilian RBAC 91K fractional/shared ownership program, listing five distinct views (operators, aircraft, models, timeline, bases) and the data sources (EA, RAB). It distinguishes itself from general fleet tools by focusing on the fractional market and specifying the certified vs. monitored distinction, so an agent can easily tell it apart from siblings like jt_fleet_search 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?

The description explains what the tool does and how to use it (view selection, filtering by operator), but it does not explicitly state when to use this tool instead of alternatives. It implies usage for fractional market queries but does not mention excluded scenarios or direct comparisons to sibling tools, though the specificity of the domain largely removes ambiguity.

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

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

Annotations already mark this as read-only and idempotent, lowering the bar, yet the description adds substantial behavior: deterministic ordering, nextCursor pagination, max 100 per call, daily quota truncation, privacy rules ('natural persons are never named'), and the unknownYear counting semantics. There is no contradiction with the annotations.

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

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

The description is long, but every sentence carries a non-obvious operational detail, such as quota truncation, sameAirframeAs being counted once, and the Brazilian detail exclusion. It is front-loaded with purpose and filters before output caveats, which is appropriate for a 12-parameter tool.

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

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

Given 12 parameters, a full output schema, and rich annotations, the description is more than complete: it covers pagination, ordering, quota behavior, privacy constraints, and exclusions that are not present in the schema or annotations. An agent can accurately select and invoke this tool without further external documentation.

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 mostly summarises filters and output fields rather than adding new parameter-level meaning; the offMarket and unknownYear clarifications largely mirror the schema descriptions. The concrete example is helpful context but not additional parameter semantics.

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

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

The description opens with a specific verb and resource: 'List aircraft across every registry Jet Tracker indexes', and further narrows scope with 'Built for off-market prospecting'. It gives a concrete example query ('Global 6000 2014-2016 not listed, worldwide') that clearly distinguishes it from sibling fleet-search tools by emphasizing global registries and the off-market angle.

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 'Built for off-market prospecting' phrase gives a clear, explicit use case, and the closing note that 'Brazilian detail ... is not in these rows' is a useful exclusion. However, it never explicitly names an alternative tool for when the user needs that detail, nor does it say when to prefer this over jt_fleet_search or jt_cross_registry.

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

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

Annotations already mark readOnly, idempotent, and non-destructive. The description adds provenance (GAMA Shipment Report), time range, and the partial-current-year data caveat, which goes beyond the annotations without contradicting them.

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, well-organized sentence front-loads the core purpose, uses parenthetical lists for the views, and ends with a useful caveat. It is dense but not verbose, and every clause earns its place.

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

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

For a moderately complex tool with a fully documented schema, an output schema, and informative annotations, the description covers the essential context: data source, time coverage, view semantics, and the partial-year caveat. No significant gaps remain for an agent 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 coverage is 100%, so the baseline is 3. The description enriches the view parameter by explaining what each view returns in more detail than the schema, including the contents of the industry view and the filters for models. This adds genuine semantic value.

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: 'factory shipments from the GAMA Shipment Report' with a clear scope (worldwide, 2005–current quarter) and explicitly enumerates the four view modes. The closing note 'Deliveries, not fleet in service' clearly differentiates it from fleet-oriented sibling tools.

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

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

The description gives clear context that this returns shipments, not fleet in service, and warns that the current year is partial. This is an explicit when-not (do not use for fleet in service) and a data completeness caveat, but it does not name alternative tools for fleet data, so it stops short of a full 5.

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

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

Beyond the readOnly/idempotent annotations, the description explains the key behavioral nuance: coverageGap=true means the aircraft moved unseen and the event is not a real stay. It also discloses tracking limitations ('Tracked flights only'), default/max period, max results, and how ongoing stays are represented (departure null, ongoing=true).

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

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

The description is dense but efficient, front-loading the core definition before output fields, use cases, and limits. Every sentence contributes something; the only minor issue is that 'see the caveat' is a dangling reference.

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 10-parameter read-only tool with an output schema, the description covers required filters, defaults, limits, and output semantics. It is slightly incomplete about pagination flow and the referenced caveat, but the schema's cursor parameter and output schema fill most of the remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating that at least one of registration/airport is required (not enforced in schema), explaining the minDays default, and clarifying the meaning of coverageGap. It doesn't need to repeat every parameter.

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

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

The description names a specific query concept – stays of 7+ days at an airport with no following tracked departure – and scopes it to one registration or one airport. It clearly distinguishes this from generic movement or history tools by emphasizing the 'no following tracked departure' and coverageGap semantics.

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

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

It gives concrete use cases: finding where aircraft spend long periods away from home (maintenance shops) and which aircraft are parked at a given airport. It also states the required filter (registration or airport). It does not explicitly name alternative sibling tools or say when not to use it, but the context is clear enough.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, so no contradiction. The description adds substantial behavioral detail: pagination limits (max 60 per call, scans 200 reservations per page, nextCursor), airframe-level grouping (one signal per physical airframe with registrations[] and airframeCount vs registrationCount), and the caveat that it is a signal, not a completed transfer. This goes well beyond the annotations.

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

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

The description is dense but well-structured, front-loading the core definition before explaining grouping, pagination, and usage. It covers multiple nuances in a single paragraph without unnecessary fluff. It could be slightly more concise, but each sentence contributes meaningful information.

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

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

Given the output schema is present, the description need not cover return types. It covers matching criteria, grouping semantics, pagination limits, usage context, and the caveat. This is complete for an agent to call the tool correctly and interpret results. There are no apparent gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the meaning of limit (max 60 per call, pagination) and cursor (nextCursor for pagination), and clarifies that includeUnmatched defaults to false and relates to the foreign-twin matching. This enriches the schema definitions without redundancy.

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

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

The description clearly states what the tool does: it returns Brazilian mark reservations that match a foreign registry, representing an import signal. It details the matching criteria (serial number + compatible model) and the output grouping (one signal per airframe). While it doesn't name sibling tools, the purpose is specific and unambiguous, distinguishing itself from generic registry search tools.

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

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

The description provides context about the tool's usefulness ('useful for brokers, lenders and insurers') and clarifies that it is a signal, not a completed transfer. However, it does not explicitly say when to use this tool versus alternatives, such as jt_registry_changes or jt_cross_registry, nor when not to use it. The guidance is implied rather than explicit.

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

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

Annotations already establish a read-only, idempotent, non-destructive profile. The description adds valuable caveats beyond those: it states the tool 'never estimates an inspection due date or airframe hours' and warns that outputs are 'hints... not facts,' which meaningfully shapes how an agent should interpret the 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?

The description is compact and every sentence earns its place: it defines the composition, lists signal types, describes the signal shape, states explicit non-goals, and sets user expectations. The front-loaded verb and resource make the tool's purpose immediately visible.

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 tool with a rich output schema, the description covers scope, output content, interpretation caveats, and negative space. There is no documentation gap that would prevent an agent from deciding whether and how to invoke 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?

The schema already documents the only parameter, registration, with format and example (PR-TBL), so the description need not repeat it. It adds only the generic 'one registration' framing; no additional parameter behavior or input nuance is contributed beyond a 100%-covered 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 specific verb and resource: it 'composes what is known about one registration into maintenance signals' and enumerates the signal categories. It is unambiguous, but it does not explicitly name or reference a sibling alternative, so an agent must infer the boundary with tools like jt_import_signals.

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 first sentence makes the scope clear: this is for one registration, not a fleet or batch. The closing note that signals are 'hints to prioritise outreach' also gives a practical when-to-use context, though exclusions and alternatives are not explicitly 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?

Even with readOnlyHint and idempotentHint already present, the description adds substantial behavioral context: it defines effectiveStatus values with time thresholds (active, stale 30+ days, expired 60+ days), explains that priceStats is computed over active priced listings, and clarifies that prices are portal-advertised rather than appraisals. This goes well beyond what annotations alone convey.

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

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

The description is dense but purposeful: every clause carries operational meaning, and the core subject is front-loaded. It is one long sentence, which hurts readability slightly, but there is no filler or redundant restatement of the title.

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

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

For a single-parameter read-only listing tool, the description covers the data scope, output statistics, sample fields, status semantics, and a key data-quality caveat. An output schema exists for detailed return structure, so this description is sufficient for an agent to select and invoke 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?

The schema already documents 'slug' with an example at 100% coverage. The description adds meaning by stating that the slug can be a slug or an alias and that it addresses the whole model family, which is useful interpretive context not present in the schema field description.

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

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

The description names a specific resource ('catalog model') and a specific output ('total and active count, priceStats', sample listings). It also distinguishes the tool from potential siblings by emphasizing 'for-sale listings' tracked by Jet Tracker and explicitly noting 'Prices as advertised by portals, not appraisals', which separates it from appraisal-style tools.

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

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

The description implies the use case: when you need for-sale listings for a catalog model via slug or alias. It does not explicitly name alternative tools or state when not to use this tool, leaving some routing to inference. The 'not appraisals' caveat partially clarifies what it is not.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds pagination behavior and a zero-results caveat. However, 'Zero results is not proof of absence' directly contradicts openWorldHint=false, which signals a closed world where absence can be treated as definitive; this is an annotation contradiction.

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

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

Four dense sentences with the core search behavior first, then return fields, slug hand-off, and the zero-results caveat. Every sentence earns its place and there is no filler.

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

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

The description covers query semantics, category values, return fields, pagination, and model-id hand-off, which is complete for a read-only search tool with full parameter coverage and an output schema. The open-world contradiction is the only notable completeness flaw.

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 concrete query examples (piper, meridian, E55P/BE40), maps the Portuguese category enum to English meanings, and clarifies offset/nextOffset pagination, going beyond the raw 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 first sentence names a specific action ('Search Jet Tracker aircraft models') and clearly delimits the resource (model catalog) and query axes (text and category). It also ties the returned slug to 'the model id the other tools accept', helping distinguish this search tool from sibling lookup and fleet tools.

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

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

It gives clear usage context: search by manufacturer/model/ICAO text and category, with pagination and the returned slug used for subsequent tool calls. It never names alternatives like jt_aircraft_lookup or jt_model_specs nor states when not to use them, so it stops short of a full routing guide.

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, openWorldHint, and destructiveHint, lowering the bar. The description adds useful behavioral context beyond those hints: how the model is resolved (slug, family slug, prefix variations, name) via model.matchedBy, and that the returned numbers are canonical and consistent with another tool. No contradictions with annotations.

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

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

The description is a single dense sentence but every clause adds relevant detail: resolution options, cost components, costModelVersion, and consistency with other sources. It is front-loaded with the core resource and slightly run-on, but not bloated.

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

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

Given the output schema exists and annotations cover safety and idempotence, the description is largely complete: it explains the input flexibility, the resolution mechanism, and the cost model outputs. It could have been slightly more explicit about the relationship to jt_model_search, but nothing essential to calling the tool 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 schema covers the single slug parameter, and the description adds substantial meaning beyond it: the slug may be a catalog slug, family slug, slug with or without manufacturer prefix, or a name, and model.matchedBy indicates resolution. This directly helps an agent construct the parameter correctly.

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

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

The description clearly defines the resource as model technical specs plus a canonical operating cost engine, enumerating the exact cost outputs (variable cost per hour, fixed cost per year, total per hour at 400 h/year, acquisition curve, costModelVersion). It also differentiates from the sibling jt_compute_tco by explicitly stating these are the same numbers and that this is the canonical engine.

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

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

The description gives clear context: this is the canonical source for model specs and operating cost, and its numbers match the Jet Tracker model page and jt_compute_tco assumptions. It does not explicitly say when not to use it or name alternatives like jt_model_search, so it lacks explicit exclusions.

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

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

Annotations already mark it readOnly, idempotent, and non-destructive, so the description adds valuable behavior beyond safety: found:false means zero in the whole period, truncated only means more pages, total is exact for the filter, max 200 per call, and sameAirframeAs deduplication semantics. The RAB-changelog provenance also clarifies data scope.

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

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

The description is long but information-dense, covering deprecation, scope, filtering, pagination, and deduplication in compact clauses. The only minor redundancy is emphasizing 'not airport movements' near the start and again at the end, but for a tool named jt_movements that repetition is arguably deliberate.

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 9-parameter tool with output schema, the description supplies the missing context an agent needs: deprecated alias, exact filter semantics, pagination/limit behavior, sameAirframeAs caveat, and non-sale/non-movement exclusions. Nothing important needed for correct invocation is left out.

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 parameter semantics are already documented; the description need not restate them. It adds useful grouping and behavior around the filters ('applied in the database: total is the exact count...') and reminds about the default executive segment, which is a small but real increment over the schema.

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

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

The description opens by identifying the tool as the deprecated name of jt_registry_changes, then states its exact function: registry changes in the Brazilian RAB between two dates, not airport movements. The enumerated change types (entry, exit, owner_change, operator_change, status_change) give a precise resource and scope, so an agent can distinguish it from movement-related tools.

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

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

It explicitly names jt_registry_changes as the current counterpart with identical behavior, giving the agent a clear replacement when deprecation matters. It also states when not to use it: 'Aircraft arriving at or leaving an airport are not registry changes' and 'A registry change is NOT a sale', which routes away from airport-traffic and sale 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?

Beyond the readOnly/idempotent annotations, it discloses significant behavioral detail: the data is the same cut as the public /operadores page, groups are merged into one, fleet results are capped at 100 with fleetTruncated, CPFs are never exposed, and specific vulnerability thresholds are described. This far exceeds what annotations alone convey.

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

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

The description is dense but not padded; every clause contributes substantive detail. The single long, comma/semicolon-heavy sentence is harder to scan than structured bullets, but it is appropriately sized for the tool's broad output profile.

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

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

Given the tool's one-parameter input and existing output schema, the description covers the important operational behaviors: query matching, group aggregation, found:false, truncation, privacy limits, and the included vulnerability/regulatory data. An agent has enough context to invoke and interpret 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?

The schema already documents the single query parameter at 100% coverage. The description adds a concrete URL-slug example, explains the 8-digit CNPJ root usage, and clarifies that names/spellings may differ, which is valuable beyond the schema. This justifies a score above the high-coverage 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?

The description clearly identifies the resource as a company-side profile for Brazilian operator/owner groups and enumerates its contents. It does not explicitly contrast itself with siblings like jt_owner_group or jt_operators_stats, so it stops just short of fully differentiating from alternatives.

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

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

It gives thorough input guidance: accepted query forms, URL slug pattern, CNPJ root handling, grouping of multiple CNPJs into one group, and found:false semantics. However, it never states when to choose this tool over related siblings, so tool-selection guidance is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: the aggregate excludes operator names, uses RBAC 91/135 classification, includes an as_of snapshot date, and only marks reservations/tails in scope. This provides useful context without contradicting the annotations.

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

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

The description is front-loaded with the essential purpose and contains dense but relevant detail. The first sentence packs a large amount of useful information, and the second sentence efficiently disambiguates from sibling tools. It is slightly long due to enumerating many output facets, 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?

The description covers purpose, output facets, scope, and alternative tools, while the presence of an output schema and full parameter schema covers structural details. It could be slightly stronger with an explicit 'use when' statement, but given the annotation coverage and the clear sibling distinction, it is substantially complete.

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

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

There is only one parameter, slug, and the input schema already describes it ('Slug do modelo.') with 100% coverage. The tool description does not add fields to the slug semantics, but it does indirectly clarify that the slug refers to a model whose operator statistics are being requested. Since schema coverage is complete, the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as providing 'AGGREGATED operator statistics of a model in Brazil' and enumerates specific outputs: distinct operators by CNPJ root, RBAC 91 vs 135 split, concentration by state, and average fleet age. It also explicitly contrasts itself with siblings that return operator names, removing ambiguity about its role.

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 effectively routes usage by stating that this aggregate 'never names operators' and that 'jt_fleet_search and jt_owner_fleet do return names.' This gives an agent a clear signal to choose this tool for aggregate statistics and the named siblings when individual operator identities are needed.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to reiterate safety. It adds valuable behavioral context: the matching by 8-digit root (since CNPJ can be full or root), the meaning of roles (owner vs operator), and the fact that an empty list is a valid, informative result. This goes beyond the schema and annotations, though it doesn't detail response structure, which is partially covered by the output schema.

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

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

The description is concise (three sentences) and front-loads the core purpose and key matching logic, followed by essential behavioral notes. Every sentence adds value: purpose, matching detail, role semantics, and the empty-list caveat. No unnecessary fluff.

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

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

Given the tool's moderate complexity (with output schema and annotations), the description sufficiently covers all necessary aspects: what it does, how to interpret results (roles, status, lien), and edge cases (branch matching, empty list). The output schema handles return structure, so the description doesn't need to repeat it. The high schema coverage and annotations complement the description fully.

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

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

The schema already provides 100% coverage of both parameters, including descriptions for cnpj (accepts full or root, not CPF) and segment (enum with meaning). The description reinforces the cnpj semantics by explaining the 8-digit root matching logic, which is not in the schema. It also adds context about the role field in the output, but not directly about parameters. Since the schema is very descriptive, the description adds marginal value beyond it, but the root-matching clarification is useful.

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

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

The description clearly states the tool lists aircraft in the Brazilian registry linked to a company CNPJ, specifying the matching logic (8-digit root) and the role information (owner vs operator). It distinguishes itself from sibling tools like jt_fleet_search by focusing on company CNPJ and providing ownership/operator details.

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

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

The description explicitly explains the matching behavior (branch does not hide parent company aircraft) and notes that an empty list is a valid answer, preventing misinterpretation. It does not explicitly name alternatives, but the unique scope (company CNPJ with role details) implicitly differentiates it from sibling search tools, and the behavior clarifications serve as 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 indicate read-only, idempotent, non-destructive behavior. The description goes well beyond that by detailing confidence tiers, the distinction between aircraftTotal and aircraftTotalConfident, and the caveat that links are hints from public records rather than a legal structure, including the airport/hangar/accounting-office false-positive risk.

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

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

The description is long but dense and purposeful: each clause conveys distinct information such as link bases, confidence rules, shared partner data, the RAB multi-CNPJ context, the max member count, and the legal caveat. It is front-loaded with the core purpose and then layers supporting detail without repetition.

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 lookup tool, the description covers inputs, output concepts, confidence interpretation, member limits, and the legal caveat. Since an output schema exists, the description does not need to enumerate return fields; nothing essential is missing for an agent to select and invoke 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?

The input schema already documents all three parameters with 100% coverage, including CNPJ/root format, limit range, and registration alternative. The description adds group-level context and the 50-member maximum, but it does not meaningfully expand per-parameter semantics beyond what the schema already provides.

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

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

The description clearly defines the resource: companies related to a CNPJ or registration that own or operate live Brazilian aircraft. It also explains why members are linked and distinguishes the tool's group-level scope from single-company lookups by emphasizing that the RAB splits a group across many CNPJs.

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

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

It gives strong context for when to use it: 'this gives the whole set in one call so one conversation covers all of them,' addressing the multi-CNPJ group problem. It does not explicitly name sibling alternatives or provide when-not conditions, but the use case is clear enough.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful behavioral detail by explaining the found=false no-curve convention and mentioning the research date, which helps an agent understand sparse 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?

The description is a single compact sentence that front-loads the core purpose and then lists the key output components and the found=false result convention. Every clause contributes meaning, with no filler or redundancy.

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 one-parameter, read-only query with an output schema available, this description is complete. It covers the model identifier, the data returned, the research date, and the no-result case, which is the main agent-facing ambiguity. Nothing critical 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 only parameter, slug, is already fully described in the schema as 'Slug do modelo.' The description adds context that this slug identifies a catalog model for the price-curve lookup, but it does not introduce new format, constraints, or behavioral semantics beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description identifies a specific resource—the curated pre-owned price curve for a catalog model—and enumerates what it contains: current median/min/max, yearly history, 5-year residual, and research date. This is clearly distinct from sibling tools like jt_market_listings or jt_model_specs, which cover different data needs.

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 makes the tool's domain clear and even explains how to interpret found=false, which guides the agent when the model has no curated curve. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for an agent to select it for curated price data.

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

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

Even though annotations already signal readOnly, idempotent, and non-destructive behavior, the description adds substantial context: filters are applied in the database, total is the exact filtered count, found:false means zero in the period, truncated indicates more pages, and each row carries sameAirframeAs to explain deduplication. Max 200 per call and the changelog start date (2026-02-03) are also disclosed. This goes well beyond what annotations alone provide.

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

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

The description is a single dense paragraph where every sentence earns its place. It front-loads the core purpose and exclusions, then efficiently covers provenance, filtering behavior, pagination, and deduplication semantics. There is no filler, repetition, or vague phrasing.

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

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

For a tool with 9 parameters and an output schema, the description covers all critical operational behavior: what counts as a registry change, what does not, how filters affect totals, how pagination works, how to interpret found:false/truncated, and how airframe deduplication works. The presence of an output schema means return values need not be re-explained. An agent has enough context to select and invoke this tool correctly.

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

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

The input schema already describes all 9 parameters, so the baseline is 3. The description adds real value by explaining how filters (type, model, uf, rbac, segment) combine with database-side filtering, and by clarifying pagination semantics (found, truncated, nextCursor, max 200). It also defines the meaning of sameAirframeAs, which directly affects how results should be interpreted. This meaningfully complements the schema rather than merely restating it.

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

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

The description clearly identifies a specific resource (Brazilian REGISTRY/RAB changelog) and a precise operation: retrieving registration changes between two dates. It enumerates exactly which change types are included (entry, exit, owner_change, operator_change, status_change) and explicitly distinguishes the tool from airport movements. This makes its purpose unambiguous even among many sibling tools.

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

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

The description provides strong when-not guidance: 'not airport movements', 'Aircraft arriving at or leaving an airport are not registry changes', and 'A registry change is NOT a sale'. It clearly states that this tool is for registration-status changes rather than operational movements. However, it does not name a specific alternative tool to use for airport movements or sales, so it stops just short of the most explicit routing guidance.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, covering the safety profile. The description adds valuable behavioral context by explaining the conditional verdict for RBAC 91 vs 135 operations and the per-regime breakdown (private, taxi135Dry, taxi135Wet), which an agent would not derive from schema or annotations alone.

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

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

The description is two sentences, front-loading the purpose as a question and then enumerating the verdict outcomes. Each sentence contributes new information about scope or output, with no filler or redundancy.

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

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

With an output schema present and safe annotations, the description covers the essential behavioral and output semantics: the verdict scale, conditional RBAC distinction, and per-regime breakdown. It also clarifies input flexibility (model slug/name, airport ICAO/name), leaving no obvious gaps for correct invocation.

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

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

Both parameters (slug and airportQuery) have full descriptions in the input schema, covering accepted formats (slug vs. name; ICAO vs. city). The tool description repeats some of this ('ICAO, city or name') but does not add new parameter semantics beyond the schema's own documentation, 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 opens with a clear question ('Can this model operate at this airport?') and specifies the exact comparison of takeoff/landing distances against runway data. It names the inputs (model and airport query) and the output verdict categories, clearly distinguishing this specialized feasibility tool from sibling lookup tools like jt_airport_lookup or jt_model_specs.

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

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

The description explains what the tool computes and the meaning of the verdict values, but it never states when to choose this tool over alternatives (e.g., when you need runway specifications alone, use jt_airport_lookup). Usage context is implied rather than directed, with no explicit conditions, exclusions, or named alternatives.

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, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral value beyond that: the score is a transparent weighted sum, each contributing fact is disclosed in evidence[] with its weight, coverage[] reports which inputs existed, and the score is a prioritization ranking, not a probability of sale. There is no contradiction with the annotations.

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

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

The description is front-loaded with the core purpose and every sentence earns its place: purpose, methodology, and caveat. It is, however, dense — the factor list runs long and the final clause 'when the internal predictor has scored this tail, its probability' is grammatically convoluted, slightly hurting readability. Well-structured but not maximally crisp.

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 one-parameter tool with 100% schema coverage, full annotations, and an output schema in place, the description carries the full interpretive burden — and it does: what the score means, how it is computed, which inputs feed it, how evidence and coverage are conveyed, and what it should not be used for. Nothing an agent needs in order to select and invoke 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% — 'Brazilian registration (PR-TBL)' fully documents the only parameter, so the baseline of 3 applies. The description contributes only the marginal note that the tool scores 'one registration,' implying single-aircraft granularity. No syntax, format, or domain detail is added beyond what the schema already provides.

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 specific verb-resource-output: 'Score 0-100 of how likely one registration is to reach the market.' It also sharpens the purpose with an explicit boundary — 'It is not a prediction of sale: it ranks who to contact first' — which distinguishes it from siblings like jt_market_listings and jt_fleet_search. An agent can tell what this tool uniquely adds without opening any other schema.

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

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

The description gives clear context: use the score to rank who to contact first, and do not treat it as a sale prediction. The 'not a prediction of sale' clause is an explicit when-not boundary, and the evidence[]/coverage[] exposition implies the agent can inspect the reasoning before acting. However, no alternative sibling is named to route an agent away from, so the guidance stops short of a full 5.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context beyond these flags: it specifies which data sources are tracked for lag, reports UTC reset time for quota, and notes which tools the key can call. This gives a fuller behavioral picture without contradicting the annotations.

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

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

The description is a single, information-dense sentence with no filler. It front-loads the tool's purpose and then enumerates the meaningful status components; every detail from source categories to lag units, coverage, key access, and quota reset timezone 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 zero parameters and an output schema present, the description covers everything an agent needs: freshness per source, tracking coverage, accessible tools, quota usage, remaining quota, and reset time. No critical information is missing for deciding to call and interpreting this status tool.

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

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

The input schema is empty and there are no parameters, so the parameter-semantics burden is minimal. The description confirms the tool takes no inputs by focusing entirely on what the status response contains, which is appropriate for a zero-parameter tool.

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

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

The description clearly defines jt_status as a health/status endpoint for the Jet Tracker data layer, listing exact reports such as last sync per source, lag in hours, tracking coverage, key access, and daily quota. This differentiates it from the many sibling lookup/fleet/search tools by focusing on data freshness and quota rather than a specific data query.

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

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

Usage is implied rather than explicit: the phrase 'Health of the Jet Tracker data behind the tools' and the quota fields signal that an agent should call this to verify data freshness or available quota before relying on other jt_* tools. However, there is no explicit when-to-use or when-not-to-use statement, and no alternative tools 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 declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value beyond these by disclosing the degenerate_route error when origin equals destination and clarifying the cost scope across charter, fractional, and owned (variable cost only) models. No contradiction with annotations exists.

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

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

The description is compact and front-loaded: the first sentence states the core operation and scope, the second handles alias compatibility, and the third gives a key error condition. There is little waste, though the first sentence is somewhat dense and grammatically loose.

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 strong annotations and an output schema present, the description does not need to explain return values. It covers input formats, alias behavior, ownership-model scope, and a degenerate-route edge case. The main completeness gap is the lack of explicit guidance on when to choose this tool over 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 coverage is 100%, so the baseline is 3, but the description adds meaningful context by explaining the required cost profile and ownership modes for the slug parameter, and by confirming that both ICAO codes and city names are valid for origin/destination. This modestly enriches the schema's own parameter descriptions.

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

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

The description clearly names the resource: trip cost between origin and destination, with input formats (ICAO/city names), cost profile scope, and included metrics (distance, block time). It also mentions the degenerate_route error condition. However, it does not explicitly differentiate this tool from jt_compute_tco beyond noting shared aliases, so it stops short of full sibling distinction.

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

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

There is no explicit guidance on when to use jt_trip_cost instead of alternatives such as jt_compute_tco, nor any when-not-to-use conditions. The phrase 'Same aliases as jt_compute_tco' addresses alias compatibility, not tool selection, leaving the agent without a decision rule.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the bar. The description adds genuine context beyond that: 'Individuals are not named' discloses a privacy redaction the agent should expect, and the PR-/PT- mark reservation explanation clarifies how the Brazil cross-registry result should be interpreted. No contradiction with annotations.

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

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

Core scope is front-loaded and the privacy note is tersely effective. However, the description is a single dense run-on passage where the enumerated return fields partly duplicate what the output schema already provides, and the Brazil link sentence could be split for readability. Light restructuring would earn the top score.

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 one-parameter read-only lookup with an output schema and strong annotations, the description is largely complete: it covers scope, the distinctive cross-registry feature, and the privacy redaction. The main gaps are lack of sibling differentiation and no data-freshness caveat for FAA registry data, both minor at this complexity level.

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

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

Parameter schema coverage is 100%, and the schema already documents that registration accepts an N-number with or without the leading N (N123AB, 123AB). The description only confirms the parameter is the key into the FAA registry, adding little beyond the schema. Baseline 3 is appropriate since the schema carries the semantic weight.

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 identifies a specific resource — 'US-registered aircraft (FAA registry) by N-number' — and enumerates the returned fields (status, model, year, airworthiness date, registrant type, base city/state, ICAO24 hex). The FAA-only scope and N-number key distinguish it from siblings such as jt_aircraft_lookup and jt_aircraft_lookup_batch, and the Brazil cross-registry link adds a distinctive capability.

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

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

The description implies the tool is for US FAA registry data keyed by N-number, and the Brazil link note gives the agent a sense of the tool's unique value. However, it never explicitly says when to prefer this over overlapping siblings like jt_aircraft_lookup, jt_aircraft_lookup_batch, or jt_cross_registry, nor does it state exclusions for non-US registrations.

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

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

Beyond the annotations (readOnlyHint false, idempotentHint true), the description discloses how invalid registrations are handled ('come back in invalid[]'), how duplicates are handled ('already-watched ones come back in alreadyWatched[]'), the max capacity, and the authentication requirement. These are behavioral details not present in the structured annotations, and nothing contradicts them.

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 primary purpose and the key contrast with jt_watch_set. Every sentence contributes essential information: the action, the distinction, behavior on edge cases, the limit, and the access requirement. No fluff.

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-parameter schema, existing annotations, and likely output schema, the description covers the essential context an agent needs to call the tool correctly: what it does, how it differs from jt_watch_set, edge-case behavior, capacity limits, and authorization. The presence of an output schema means return details don't need to be repeated.

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

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

The input schema fully describes the 'registrations' parameter (format, case, hyphen, length). The description adds value by explaining what happens with invalid or duplicate entries, which directly informs how to interpret parameter results. This goes beyond the schema's static type description, though the core parameter semantics are already covered.

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

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

The description clearly states the action: 'Add registration(s) to this account's watch list' and explicitly distinguishes from jt_watch_set by noting it does so 'WITHOUT touching the rest'. The verb-resource pair is specific and the sibling contrast removes ambiguity about which watch-modifying tool to choose.

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 jt_watch_set as the alternative that replaces the whole list, implying this tool should be used when only adding to the existing list. It also states a prerequisite ('Requires an account key (Enterprise)') and the total limit of 500 watched registrations, giving clear guidance on when this tool applies and its constraints.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the description does not need to restate those. It adds valuable behavioral context: the webhook delivers changes only for tails in this list, and an account key is required. This goes beyond what the annotations convey.

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

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

Two sentences with no filler. The core identity is front-loaded, and the webhook/auth details earn their place without bloating the 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 zero-parameter read-only list with a rich output schema and annotations, this description is sufficient. It explains the account-specific scope, the Enterprise requirement, and the webhook relationship; nothing essential is missing.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter details to clarify, and the description correctly avoids inventing any.

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 identifies the resource as 'Registrations this account watches' and ties it to webhook delivery, which makes the purpose understandable. It is clear enough to be distinguished from watch_add/watch_remove/watch_set, though it never uses an explicit verb like 'list' or 'return'.

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

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

The description gives useful context about the webhook and the Enterprise account key requirement, which implies when this tool is relevant. However, it does not explicitly state when to use this tool over siblings like watch_rules_list, nor does it mention exclusions or alternative conditions.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true, and the description adds critical behavior: invalid registrations are returned in invalid[], and it requires an Enterprise account key. This goes beyond the structured fields and discloses edge-case behavior and auth prerequisites.

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

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

The description is a single concise sentence that front-loads the core action, then adds the key scoping and error-handling details. No wasted words; every clause contributes to understanding.

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

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

For a simple single-parameter tool with a full schema and output schema present, the description covers the action, scope, invalid input behavior, and auth requirement. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, and the parameter 'registrations' is fully documented with format constraints (Brazilian registrations, hyphen/case flexibility, length, count limits). The tool description does not add extra parameter semantics beyond what the schema already states, so a baseline 3 is appropriate.

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

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

The description clearly states the action (remove registrations from the watch list) and explicitly scopes it ('WITHOUT touching the rest'), distinguishing it from batch operations or list management tools. It also mentions invalid registration handling, which further clarifies its purpose.

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

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

The description implies usage context (selective removal from watch list) and notes the account key requirement, but it does not explicitly mention alternatives like jt_watch_set for bulk replacement or when not to use this tool. Still, the context is clear enough for an agent to route correctly.

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

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

Beyond the annotations, it discloses the critical dryRun side-effect (returns preview.count without saving), the account-key requirement, and the whole-fleet behavior when no filter is set. These are exactly the behavioral traits an agent needs, and the annotations do not carry them. There is no contradiction with the readOnly, idempotent, or destructive hints.

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

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

The description is compact, front-loaded, and every sentence adds information: scope, filter behavior, eventTypes, dryRun semantics, and auth. The event-type list is redundant with the schema but acceptable; there is no filler or fluff.

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 write tool with a full schema and output schema, it covers prerequisite auth, side-effect avoidance via dryRun, and the important whole-fleet edge case. It loses a point only for the 'every field optional' wording that needs reconciliation with the required eventTypes, and for not naming a sibling tool for comparison.

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 value by explaining the null-as-no-filter convention, the at-least-one-filter condition, and the dryRun preview semantics. The phrase 'every field is optional' is slightly loose because eventTypes is required by the schema, but the intent is clear for the filter fields.

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 specific verb-resource pair, 'Create a watch rule by profile', and clarifies the profile dimensions (modelFamily/uf/category/rbac). This makes it distinguishable from generic watch tools like jt_watch_add, which likely use a different subject. No meaningful ambiguity remains about what the tool does.

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

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

The description gives strong context for how the rule is scoped (null means no filter, no filters watches the whole live fleet) and adds the Enterprise account-key prerequisite. However, it never names an alternative or states when to prefer this over jt_watch_add or jt_watch_set; differentiation is only implied by the 'by profile' wording.

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

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

Annotations already mark destructiveHint=true and idempotentHint=true. The description adds meaningful behavioral context beyond that: the deletion is scoped to rules only, not explicit registrations, and an Enterprise account is required. This supplements the annotations without contradicting them.

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

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

The description is three short sentences, with the primary action front-loaded. Every sentence adds value: the action, the id source, the exclusion scope, and the authentication requirement. There is no filler.

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

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

For a single-parameter, destructive tool with full parameter schema, annotations, and an output schema, the description covers all essential operational details: what is deleted, how the id is obtained, what is not affected, and the required account level. 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 description coverage is 100%, and the schema already specifies the id as 'Rule id, from jt_watch_rules_list.' The description restates this id source but does not add significant new parameter semantics 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 states a specific verb and resource: 'Delete a watch-by-profile rule by id'. It also differentiates from siblings by explicitly noting it does not touch explicit registrations from jt_watch_set/jt_watch_add, so an agent can distinguish this from watch_remove 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 description includes a clear when-not condition ('Does not touch explicit registrations from jt_watch_set/jt_watch_add'), a prerequisite ('Requires an account key (Enterprise)'), and the source of valid ids (jt_watch_rules_list). This gives the agent enough context to decide when to use this tool over the watch removal siblings.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description adds valuable behavior: rules match dynamically, future registrations are included, rules complement explicit watches, max 50 rules, and an Enterprise account key is required. This goes well beyond the structured 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?

Every sentence earns its place: core purpose, behavioral nuance, relationship to sibling tool, limit, and auth requirement. It is front-loaded with the primary function and has 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?

For a zero-parameter, read-only list tool with an output schema and strong annotations, the description is complete. It explains semantics, dynamic behavior, limits, relationship to alternatives, and authentication requirements.

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

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

The input schema has no properties, so there are no parameter semantics to clarify; the description appropriately adds no parameter noise. The account-key requirement is useful context even though it is not a parameter.

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

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

The description clearly identifies the resource as 'rules this account uses to watch aircraft BY PROFILE' and distinguishes it from registration-based watching. It also explicitly contrasts with jt_watch_list, so an agent can tell them apart without inspecting schemas.

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

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

It gives clear context: profile-based rules apply to every matching tail and add to, never replace, the explicit watch list. It names jt_watch_list as the complementary tool, but does not explicitly spell out when not to use this tool or enumerate all alternatives.

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

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

Adds substantial behavior beyond annotations: idempotency (sending the same list twice changes nothing), the exact webhook event types and timing (registry.changed, cva_expiring at 30/7 days, etc.), invalid[] handling, max 500, and Enterprise account-key requirement. Annotations already indicate destructive/idempotent, but description enriches with concrete side effects and constraints. No contradiction with annotations.

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

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

Four short sentences, action and idempotency first, followed by event details, invalid handling, and requirements. No filler; each sentence adds operational information. The event list is detailed but relevant for an agent deciding whether this watch set serves its use case.

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 write/destructive tool with one parameter, the description covers what is replaced, idempotency, side effects (webhook events), partial-failure behavior (invalid[]), size limit, and auth requirement. Output schema exists, so return format needs no further explanation. Nothing essential 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 already documents the registrations array fully (100% coverage), including Brazilian registrations and max 500. Description adds that invalid registrations are returned in invalid[] and the rest are saved, which clarifies processing behavior. This is helpful but not necessary to understand the parameter type/constraints, so baseline 3 is appropriate.

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

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

States a specific verb ('Replace'), the exact resource ('the whole watch list of this account'), and distinguishes itself from siblings like watch_add/watch_remove by emphasizing whole-list replacement. The title reinforces the resource. No ambiguity about what operation it performs.

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?

Clear context: use when you need to replace the entire watch list for an account, not incremental additions/removals. It does not explicitly name alternatives (watch_add/watch_remove), but 'whole' and the sibling list make the intended use evident. No explicit exclusions, so not a 5.

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