Jet Tracker

Search the world fleet (off-market prospecting)

jt_global_fleet_search

Read-onlyIdempotent

List aircraft across every registry Jet Tracker indexes (BR, US, CA, AU, NZ, MX, AT, CH, GG, IE, IM, KY, LU: Brazil RAB, US FAA and national registries) by model (catalog slug, family or name, up to 30) or category, plus year range, countries, status, owner kind and offMarket (true = no active listing linked by Jet Tracker). Built for off-market prospecting such as "Global 6000 2014-2016 not listed, worldwide". Each row carries: model with match quality (catalog, inferred_by_serial, designation), year (from the registry or inferred from the same airframe in another registry, with the source mark), owner kind and name (natural persons are never named; US registrant address with how many aircraft share it, which exposes trust companies), market.listedNow, sampled worldwide ADS-B activity (adsb.lol: days seen, last callsign, operator designator and name), Brazil-only signals (tracked flights, sale propensity score), last owner change in the registry changelog, sameAirframeAs (count once) and factual signals. unknownYear counts matches left out of a year filter because no year is known. Deterministic order (country, registration); paginate with nextCursor; max 100 per call; the daily plan quota may truncate (quotaTruncated). Brazilian detail (owner QSA, contact, CVA) is not in these rows.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Default 25.
`model`	No	Catalog slug (global-6000), family slug or name ("g550", "king air 360").
`cursor`	No	nextCursor from a previous page.
`models`	No	Several models at once (union). Up to 30.
`status`	No	Default: operational + reserve.
`yearTo`	No	Latest year of manufacture (inclusive).
`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). Model or category is required.
`yearFrom`	No	Earliest year of manufacture (inclusive). Uses the registry year, or the inferred one when the registry has none.
`countries`	No	ISO2 codes of the registries to search, uppercase. Default: all indexed registries.
`offMarket`	No	true = only aircraft with no active listing linked by Jet Tracker; false = only listed ones. Omit for both.
`ownerKind`	No	company, trust_or_lessor (bank, lessor or trustee), government, individual, unknown.
`includeUnknownYear`	No	Include rows with unknown year even when yearFrom/yearTo is set (default false: unknownYear counts what the year filter left out). Each row carries year.confidence: registry, inferred or unknown.

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.

Changed9 schema fields changedSep 16, 2026

addedInput schema / properties / includeUnknownYear

Added value: +{
+  "description": "Include rows with unknown year even when yearFrom/yearTo is set (default false: unknownYear counts what the year filter left out). Each row carries year.confidence: registry, inferred or unknown.",
+  "type": "boolean"
+}

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"
+}
```

AddedSep 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark this as read-only and idempotent, lowering the bar, yet the description adds substantial behavior: deterministic ordering, nextCursor pagination, max 100 per call, daily quota truncation, privacy rules ('natural persons are never named'), and the unknownYear counting semantics. There is no contradiction with the annotations.

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 long, but every sentence carries a non-obvious operational detail, such as quota truncation, sameAirframeAs being counted once, and the Brazilian detail exclusion. It is front-loaded with purpose and filters before output caveats, which is appropriate for a 12-parameter tool.

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?

Given 12 parameters, a full output schema, and rich annotations, the description is more than complete: it covers pagination, ordering, quota behavior, privacy constraints, and exclusions that are not present in the schema or annotations. An agent can accurately select and invoke this tool without further external documentation.

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%, so the baseline is 3. The description mostly summarises filters and output fields rather than adding new parameter-level meaning; the offMarket and unknownYear clarifications largely mirror the schema descriptions. The concrete example is helpful context but not additional parameter semantics.

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 aircraft across every registry Jet Tracker indexes', and further narrows scope with 'Built for off-market prospecting'. It gives a concrete example query ('Global 6000 2014-2016 not listed, worldwide') that clearly distinguishes it from sibling fleet-search tools by emphasizing global registries and the off-market angle.

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?

The 'Built for off-market prospecting' phrase gives a clear, explicit use case, and the closing note that 'Brazilian detail ... is not in these rows' is a useful exclusion. However, it never explicitly names an alternative tool for when the user needs that detail, nor does it say when to prefer this over jt_fleet_search or jt_cross_registry.

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?