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.