Jet Tracker

Long stays on the ground

jt_ground_events

Read-onlyIdempotent

Stays of 7+ days (minDays) at an airport without a following tracked departure, for one registration or for one airport (at least one is required). Each event says the airport, arrival, departure (null and ongoing=true if still there), days, whether it is the aircraft hub (atHub), and coverageGap=true when the next departure was seen from a different airport (the aircraft moved unseen: not a real stay). Useful to see where an aircraft spends long periods away from home (often a maintenance shop) and which aircraft are parked at a given airport. Default period: last 90 days; max 365. Max 100 per call. Tracked flights only (see the caveat).

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (default: today).
`from`	No	Start date YYYY-MM-DD (default: 90 days ago).
`icao`	No	One airport (ICAO): aircraft that stayed there minDays or more.
`atHub`	No	true = only stays at the aircraft inferred hub (home parking); false = only stays AWAY from hub (maintenance prospecting: use false). Omit for both.
`limit`	No	Default 25.
`cursor`	No	nextCursor from a previous page.
`minDays`	No	Minimum stay in days. Default 7.
`ongoing`	No	true = only stays still in progress (aircraft is there now, as far as tracking sees); false = only finished stays. Omit for both.
`segment`	No	Default executive for an airport, all for a registration.
`registration`	No	One Brazilian registration (PR-CON).

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.

Changed10 schema fields changedSep 16, 2026

addedInput schema / properties / atHub

Added value: +{
+  "description": "true = only stays at the aircraft inferred hub (home parking); false = only stays AWAY from hub (maintenance prospecting: use false). Omit for both.",
+  "type": "boolean"
+}

addedInput schema / properties / ongoing

Added value: +{
+  "description": "true = only stays still in progress (aircraft is there now, as far as tracking sees); false = only finished stays. Omit for both.",
+  "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"
+}
```

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 readOnly/idempotent annotations, the description explains the key behavioral nuance: coverageGap=true means the aircraft moved unseen and the event is not a real stay. It also discloses tracking limitations ('Tracked flights only'), default/max period, max results, and how ongoing stays are represented (departure null, ongoing=true).

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 dense but efficient, front-loading the core definition before output fields, use cases, and limits. Every sentence contributes something; the only minor issue is that 'see the caveat' is a dangling reference.

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?

For a 10-parameter read-only tool with an output schema, the description covers required filters, defaults, limits, and output semantics. It is slightly incomplete about pagination flow and the referenced caveat, but the schema's cursor parameter and output schema fill most of the remaining gap.

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 the baseline is 3. The description adds value by stating that at least one of registration/airport is required (not enforced in schema), explaining the minDays default, and clarifying the meaning of coverageGap. It doesn't need to repeat every parameter.

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 query concept – stays of 7+ days at an airport with no following tracked departure – and scopes it to one registration or one airport. It clearly distinguishes this from generic movement or history tools by emphasizing the 'no following tracked departure' and coverageGap semantics.

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 gives concrete use cases: finding where aircraft spend long periods away from home (maintenance shops) and which aircraft are parked at a given airport. It also states the required filter (registration or airport). It does not explicitly name alternative sibling tools or say when not to use it, but the context is clear enough.

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?