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

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

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

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

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

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

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

An output schema exists, so return-field explanation is unnecessary, and annotations cover the safety profile. The description supplies what those structured fields cannot: data provenance, unit conventions, the derived premium/PTAX outputs, and the wholesale-vs-into-plane limitation. Nothing an agent needs before calling is missing.

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

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

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

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

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

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

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

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

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

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