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), owner 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 quota may truncate (quotaTruncated). Segment: when omitted, a piston category means "all", a model with no aircraft in the executive cut switches to "all", otherwise executive; every answer says segmentApplied and outsideSegment (how many more match outside the cut). rbac 137 reads the agricultural fleet (Jet Tracker Agro cut) and returns operators with their fleet. When this account cannot list, preview.total still says how many aircraft match. Filtering by a person's name is not available.

Input Schema

Name	Required	Description
`uf`	No	Registered state (UF) of the owner, e.g. SP, MG, PR. Not where the aircraft is based: the RAB has no base.
`cva`	No	CVA window: expired, expiring (within cvaDays, default 90), valid, unknown (RAB has no date). CVA = Certificado de Verificação de Aeronavegabilidade, the airworthiness verification certificate (not the CA, Certificado de Aeronavegabilidade).
`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	Omit to let the filter decide (see segmentApplied in the answer). executive, geral (general aviation), comercial, militar or all.
`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

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.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / segment / description

Previous value: -"Default executive."New value: +"Omit to let the filter decide (see segmentApplied in the answer). executive, geral (general aviation), comercial, militar or all."

Changed1 schema field changedOct 7, 2026

changedInput schema / properties / uf / description

Previous value: -"Base state (UF), e.g. SP, MG, PR."New value: +"Registered state (UF) of the owner, e.g. SP, MG, PR. Not where the aircraft is based: the RAB has no base."

Changed1 schema field changedOct 7, 2026

changedInput schema / properties / cva / description

Previous value: -"CVA (airworthiness certificate) window: expired, expiring (within cvaDays, default 90), valid, unknown (RAB has no date)."New value: +"CVA window: expired, expiring (within cvaDays, default 90), valid, unknown (RAB has no date). CVA = Certificado de Verificação de Aeronavegabilidade, the airworthiness verification certificate (not the CA, Certificado de Aeronavegabilidade)."

Changed1 schema field changedSep 28, 2026

changedOutput schema / properties / _meta / required

Previous value: -[
-  "tool",
-  "tier",
-  "source",
-  "asOf",
-  "gated",
-  "via"
-]New value: +[
+  "tool",
+  "source",
+  "asOf",
+  "gated",
+  "via"
+]

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

Behavior5/5

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

The annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), and the description layers on non-obvious behavior the schema cannot express: max 100 per call, "the daily quota may truncate (quotaTruncated)", segment auto-selection with segmentApplied/outsideSegment, RBAC 137 returning operators with their fleet, and preview.total still reporting matches when the account cannot list. It also warns that sameAirframeAs lists other live registrations of the same physical aircraft and must be counted once — exactly the trap an agent would fall into.

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

Conciseness3/5

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

Every clause carries information, but it is delivered as one long undifferentiated paragraph with parenthetical asides, and the important segment fallback logic is buried mid-stream after the filter list. It would be considerably more usable as two or three front-loaded blocks (what it lists / how segment resolves / limits and gaps).

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

Completeness5/5

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

For a 24-parameter, zero-required search tool with an output schema, this covers the things an agent cannot get elsewhere: pagination via nextCursor, row shape (ownerRecords, ownerRole, airworthiness, flightActivity, riskFlags, sameAirframeAs), deterministic registration ordering, quota truncation, and the behavioral caveat about segmentApplied. Nothing needed to call it correctly is absent.

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 coverage is 100% and the description's parameter content largely restates what the schema already documents (CNAE prefixes 3316/5111/64, RBAC 91/135/121/137, cite lists). The one genuine addition is the segment fallback rule — piston category defaults to "all", a model absent from the executive cut switches to "all" — which is semantics of the segment parameter the schema does not state. Baseline 3 is appropriate for a fully documented schema.

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?

"List Brazilian-registered aircraft by COMPOSED filters" gives a specific verb, resource and geographic scope in the first clause, which separates it from jt_global_fleet_search and from single-entity siblings like jt_aircraft_lookup. The enumeration of filterable dimensions (owner state, CNAE, RBAC, tracked hours, hub) makes the tool's surface unambiguous.

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

Usage Guidelines4/5

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

It sets a clear usage mode ("one call per question", union through models up to 30, paginate with nextCursor) and states an explicit exclusion: "Filtering by a person's name is not available." What is missing is explicit routing to siblings — it never says to use jt_owner_fleet for an owner's full fleet or jt_global_fleet_search outside Brazil, so the agent must infer those boundaries.

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?