Jet Tracker

Aviation trade, fuel and airport traffic indicators for Brazil

jt_sector_indicators

Read-onlyIdempotent

Brazilian aviation sector indicators from official open data (Comex Stat and ANP), monthly: imports and exports of aircraft, parts and drones (chapter 88, FOB USD), aircraft imported by size class (units), top origin and destination countries over 12 months, jet fuel (QAV) and aviation gasoline (AVGAS) volume sold by distributors, with sales by state, and official general aviation traffic per aerodrome from CGNA/DECEA (landings and takeoffs at the 100 aerodromes it reports, national total, ranking, and the monthly series of one aerodrome when icao is given). Year to date against the same months of the prior year. Trade includes commercial and military aviation.

Input Schema

Name	Required	Description
`icao`	No	Aerodrome ICAO (SBJD) for its monthly CGNA series; only with topic=airports or no topic.
`topic`	No	trade (Comex Stat), fuel (ANP) or airports (CGNA); omit for all three.
`months`	No	How many recent months in the monthly series. Default 12.

Output Schema

Name	Required	Description
`code`	No	Machine-readable error code (INTERNAL, TIMEOUT, INVALID_ARGUMENT, NOT_FOUND, TOOL_FAILED, ACCOUNT_KEY_REQUIRED).
`_meta`	No
`error`	No
`found`	No
`gated`	No
`requestId`	No
`retryable`	No
`quota_exceeded`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

addedInput schema / properties / icao

Added value: +{
+  "description": "Aerodrome ICAO (SBJD) for its monthly CGNA series; only with topic=airports or no topic.",
+  "pattern": "^[A-Za-z]{4}$",
+  "type": "string"
+}

changedInput schema / properties / topic / description

Previous value: -"trade (Comex Stat) or fuel (ANP); omit for both."New value: +"trade (Comex Stat), fuel (ANP) or airports (CGNA); omit for all three."

changedInput schema / properties / topic / enum

Previous value: -[
-  "trade",
-  "fuel"
-]New value: +[
+  "trade",
+  "fuel",
+  "airports"
+]

AddedOct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's value is in the data provenance and scope it adds: official open data sources, monthly granularity, YTD-vs-prior-year comparison, chapter 88 FOB USD, and the explicit bound of 'the 100 aerodromes it reports'. It stops short of noting lag, revision, or coverage caveats for the datasets.

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

Conciseness4/5

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

One dense but well-ordered sentence: scope, sources, sub-topics, then the YTD comparison and the commercial/military qualifier. It is long for a single sentence and would scan better broken into trade/fuel/airports clauses, but every clause carries information and nothing is redundant.

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

Completeness4/5

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

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

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by tying icao to 'the monthly series of one aerodrome' and clarifying that topic selects the underlying source (Comex Stat / ANP / CGNA) while omission aggregates all three. The months parameter's role is only lightly restated from the schema.

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

Purpose4/5

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

The description states a specific resource (Brazilian aviation sector indicators) and enumerates the exact content: chapter-88 trade flows, fuel volumes by distributor/state, and CGNA/DECEA aerodrome movements, with named sources (Comex Stat, ANP, CGNA). It does not explicitly contrast itself with siblings like jt_airport_traffic or jt_fuel_prices, which likely cover similar domains internationally, so an agent must infer the differentiation.

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

Usage Guidelines3/5

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

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

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

All Jet Tracker tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?