Jet Tracker

Brazilian aircraft by registration, in batch

jt_aircraft_lookup_batch

Read-onlyIdempotent

Same profile as jt_aircraft_lookup for up to 25 registrations in one call (compact detail by default). Each item is found:true with the profile, or found:false with the reason. Debits one lookup per registration from the daily quota.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`detail`	No	Default compact.
`registrations`	Yes	Brazilian registrations, with or without hyphen, any case. Invalid items come back as found:false with error invalid_registration; duplicates (PR-TBL and prtbl) count once.

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 / registrations / description

Previous value: -"Brazilian registrations, with or without hyphen."New value: +"Brazilian registrations, with or without hyphen, any case. Invalid items come back as found:false with error invalid_registration; duplicates (PR-TBL and prtbl) count once."

changedInput schema / properties / registrations / items / maxLength
```
Previous value: -7New value: +20
```
changedInput schema / properties / registrations / items / minLength
```
Previous value: -5New value: +1
```
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.5/5.0

Behavior5/5

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

Beyond the annotations, which already mark the operation as read-only and non-destructive, the description discloses per-item found:true/found:false behavior, compact detail as the default, and the quota cost of one lookup per registration. These are meaningful operational traits that an agent needs to predict behavior and avoid surprises.

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

Conciseness5/5

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

Three sentences, no filler, and the most important scoping information (same profile, max 25, compact default) is front-loaded. The later sentences cover result shape and quota impact, each earning its place.

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?

With a high-coverage schema, an output schema, and annotations covering safety and idempotency, the description only needs to add batch-specific context. It provides the limit, result semantics, and quota effect, making the tool fully actionable for an agent.

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?

The schema already provides 100% parameter coverage, including the registrations array format, validation behavior, duplicate handling, and the compact/full enum. The description adds little beyond restating the default compact detail and the maximum batch size, which are already present in the 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?

The description names a specific action (batch aircraft lookup), a specific resource (Brazilian aircraft registrations), and a clear batching limit. It also explicitly frames itself as the batch counterpart to jt_aircraft_lookup, which distinguishes it from that sibling tool without requiring schema inspection.

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?

"Same profile as jt_aircraft_lookup for up to 25 registrations in one call" clearly indicates this tool is for batch lookups, implicitly setting the alternative as the single-registration tool. It does not explicitly say "use jt_aircraft_lookup for a single registration," but the contrast is strong enough to guide selection.

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?