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.

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"
+]

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.3/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower; the description adds real behavioral context beyond them: tracked-flights-only scope, default 90-day window, 365-day max, 100-per-call cap, cursor paging, and the meaning of coverageGap=true and departure=null/ongoing=true. The dangling 'see the caveat' reference adds no information.

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?

Dense but front-loaded: the core definition leads, then event fields, then use cases, then limits. Every sentence carries information, though the paragraph is long enough that a reader must work through it to reach the operational constraints.

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?

With annotations, a full input schema, and an existing output schema, the description supplies what's needed: the at-least-one-param rule, defaults, caps, and the coverageGap caveat semantics. The unexplained 'see the caveat' pointer is the only loose end.

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 baseline is 3, but the description adds meaning the schema cannot express: it surfaces that at least one of registration or icao is required (the schema lists zero required params) and restates the default period and record cap. It doesn't clarify the segment default switch beyond what the schema says.

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 states a precise verb+resource: stays of 7+ days at an airport without a following tracked departure, scoped to one registration or one airport. It also enumerates what each event contains (airport, arrival, departure, days, atHub, coverageGap), making it clearly distinguishable from siblings like jt_movements or jt_maintenance_signal.

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 names concrete use cases ('where an aircraft spends long periods away from home (often a maintenance shop)' and 'which aircraft are parked at a given airport') and states the cardinality constraint that at least one of registration/icao is required. It does not, however, point to an alternative sibling when the agent wants a different view (e.g. maintenance-specific signals).

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?