Jet Tracker

Runway feasibility for a model

jt_runway_check

Read-onlyIdempotent

Can this model operate at this airport? Compares the model takeoff/landing distances with the runway of the airport (ICAO, city or name). verdict is the overall answer: ok, marginal, insufficient, unknown, or conditional (fits a private RBAC 91 flight but NOT an RBAC 135 air-taxi operation with the 60% landing factor). verdictByRegime gives private, taxi135Dry and taxi135Wet separately. Landing is checked against the declared LDA (landingRunwayM) and takeoff against min(TORA, ASDA) (takeoffRunwayM; takeoffRunwayKind=LDA means no TORA/ASDA published, so LDA is used as a conservative floor); bindingLeg says which one decides. runwayAsOf is the AISWEB data date.

Input Schema

Name	Required	Description	Default
`slug`	Yes	Modelo: slug do catálogo (ex: phenom-300), slug com fabricante (embraer-phenom-300) ou o nome ("Phenom 300"). A resposta diz em modelSlug qual modelo foi usado.
`airportQuery`	Yes	ICAO ou cidade/nome do aeroporto.

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 changedSep 28, 2026

changedOutput schema / properties / _meta / required

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

Changed8 schema fields changedSep 16, 2026

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

Changed1 schema field changedSep 12, 2026

changedInput schema / properties / slug / description

Previous value: -"Slug do modelo (ex: embraer-phenom-300). Use search_aircraft_catalog se não souber."New value: +"Modelo: slug do catálogo (ex: phenom-300), slug com fabricante (embraer-phenom-300) ou o nome (\"Phenom 300\"). A resposta diz em modelSlug qual modelo foi usado."

First observedSep 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, but the description adds substantial behavior: verdict categories, RBAC 91 vs RBAC 135 regimes, landing vs takeoff runway references, LDA-as-conservative-floor handling, binding leg, and AISWEB data date. This is rich behavioral context beyond structured fields.

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 purpose question is front-loaded, followed by dense but largely relevant details. Some output-field explanations could be left to the output schema, but most sentences help interpret the verdict and runway comparisons.

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 domain-complex feasibility check, the description gives enough to understand inputs, verdicts, regime distinctions, and runway-data semantics. With an output schema present, return fields need not be fully explained here.

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 description coverage is 100%, documenting both required parameters including slug formats and airport query forms. The description restates that airportQuery accepts ICAO/city/name but adds little parameter-level meaning beyond the schema, so baseline 3 is appropriate.

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?

States a specific question and operation: compares a model's takeoff/landing distances with an airport runway, accepting ICAO, city, or name. This clearly distinguishes it from generic model and airport lookup siblings.

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?

Opens with the exact decision question ('Can this model operate at this airport?'), giving clear context for when to use it. It does not name alternative tools or exclusions, but the intended usage is unambiguous.

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?