Jet Tracker

Search the Brazilian fleet

jt_fleet_search

Read-onlyIdempotent

List Brazilian-registered aircraft by COMPOSED filters, one call per question: models (array of catalog slugs, families or names, up to 30) or a single model, category (jet, turboprop, helicopter, piston or a fine category), base state (uf), owner city (municipio, from the Receita Federal record), owner CNAE prefix (cnaePrefix: 3316 maintenance, 5111 air taxi, 64 financial), owner size (porte), status, RBAC (91 private, 135 air taxi, 121 airline, 137 agricultural), year range, lien (gravame), owner type (pj/pf), CVA window (cva + cvaDays), tracked hours in 365 days (hours365Min/Max), days since last tracked flight (idleDaysMin/Max) and inferred hub (hub). Each row carries ownerRecords (Receita record per owner CNPJ: city, CNAE, size, contact), ownerRole (what the owner company is), airworthiness (CVA/CA), flightActivity (tracked summary), riskFlags and sameAirframeAs (other live registrations of the same physical aircraft: count once). Deterministic order by registration; paginate with nextCursor. Max 100 per call; the daily plan quota may truncate (quotaTruncated). Default segment executive; segment "all" includes airliners and general aviation. When the plan blocks the list, preview.total still says how many aircraft match. Filtering by a person's name is not available.

Input Schema

TableJSON Schema

Name	Required	Description
`uf`	No	Base state (UF), e.g. SP, MG, PR.
`cva`	No	CVA (airworthiness certificate) window: expired, expiring (within cvaDays, default 90), valid, unknown (RAB has no date).
`hub`	No	Inferred home airport (ICAO) from tracking, e.g. SBBR.
`rbac`	No	91, 91k (shared/fractional: ANAC CF_OPERACIONAL 91K or aircraft operated by a certified RBAC 91K program, see program field), 135 (air taxi), 121 (airline), 137 (agricultural).
`limit`	No	Default 25.
`model`	No	Catalog slug (embraer-phenom-300), family slug, slug with or without manufacturer prefix, ICAO type code (BE40) or free text ("citation", "king air"). Free text matches whole words: "hawker 400" does not match Hawker 4000.
`porte`	No	Owner size at the Receita: ME, EPP or DEMAIS.
`scope`	No	family (default): a model resolves to its whole family (Hawker 400XP = Beechjet 400 family, same total from any alias). variant: only the exact variant matched.
`cursor`	No	nextCursor from a previous page.
`models`	No	Several models at once (union), e.g. the models of a maintenance rating. Up to 30.
`status`	No	Default: operational + reserve + suspended (cancelled never returns).
`yearTo`	No	Latest year of manufacture (inclusive), e.g. 2020.
`cvaDays`	No	Window in days for cva=expiring. Default 90.
`gravame`	No	true = has a registered lien; false = no lien.
`segment`	No	Default executive.
`category`	No	Group (jet, turboprop, helicopter, piston) or fine category (vlj, light, midsize, super_midsize, large, ultra_long_range, turboprop_single, turboprop_twin_light, turboprop_twin_medium, heli_piston, heli_light_turbine, heli_medium_turbine, heli_heavy_turbine, piston_single, piston_twin).
`yearFrom`	No	Earliest year of manufacture (inclusive), e.g. 2008.
`municipio`	No	Owner city as registered at the Receita Federal (accent/case insensitive): "Luís Eduardo Magalhães", "Sao Paulo". Only companies (CNPJ) have a city.
`ownerType`	No	pj = company (CNPJ), pf = natural person.
`cnaePrefix`	No	Owner main CNAE prefix at the Receita: 3316 maintenance shops, 5111/5112 air transport, 64 banks and lessors, 6462 holdings.
`hours365Max`	No	Maximum tracked flight hours in the last 365 days.
`hours365Min`	No	Minimum tracked flight hours in the last 365 days.
`idleDaysMax`	No	Maximum days since the last tracked flight (e.g. 7 = flew in the last week, as far as tracking sees).
`idleDaysMin`	No	Minimum days since the last tracked flight (e.g. 30 = parked a month or more, as far as tracking sees).

Output Schema

TableJSON 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.

Changed11 schema fields changedSep 16, 2026

changedInput schema / properties / model / description

Previous value: -"Catalog slug (embraer-phenom-300), family slug or free text (\"citation\", \"king air\")."New value: +"Catalog slug (embraer-phenom-300), family slug, slug with or without manufacturer prefix, ICAO type code (BE40) or free text (\"citation\", \"king air\"). Free text matches whole words: \"hawker 400\" does not match Hawker 4000."

changedInput schema / properties / rbac / description

Previous value: -"91, 91k (shared/fractional), 135 (air taxi), 121 (airline), 137 (agricultural)."New value: +"91, 91k (shared/fractional: ANAC CF_OPERACIONAL 91K or aircraft operated by a certified RBAC 91K program, see program field), 135 (air taxi), 121 (airline), 137 (agricultural)."

addedInput schema / properties / scope

Added value: +{
+  "description": "family (default): a model resolves to its whole family (Hawker 400XP = Beechjet 400 family, same total from any alias). variant: only the exact variant matched.",
+  "enum": [
+    "family",
+    "variant"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / _meta / properties / asOf / description
```
Added value: +"Alias of sourceUpdatedAt (kept for compatibility)."
```

addedOutput schema / properties / _meta / properties / generatedAt

Added value: +{
+  "description": "When this response was produced (ISO 8601).",
+  "type": "string"
+}

addedOutput schema / properties / _meta / properties / observedAt

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Last event actually observed in the data returned (last flight, last arrival, last listing sighting)."
+}

addedOutput schema / properties / _meta / properties / sourceUpdatedAt

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Last sync of the underlying source (RAB snapshot, registry import, listing scan). Never in the future."
+}

addedOutput schema / properties / _meta / properties / validUntil

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Expiry of the fact returned, when it has one (CVA validity, period end)."
+}

addedOutput schema / properties / code

Added value: +{
+  "description": "Machine-readable error code (INTERNAL, TIMEOUT, INVALID_ARGUMENT, NOT_FOUND, TOOL_FAILED, ACCOUNT_KEY_REQUIRED).",
+  "type": "string"
+}

addedOutput schema / properties / requestId
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / retryable
```
Added value: +{
+  "type": "boolean"
+}
```

First observedSep 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?