Jet Tracker

Market listings for a model

jt_market_listings

Read-onlyIdempotent

For-sale listings of a catalog model (slug or alias, whole family) tracked by Jet Tracker: total and active count, priceStats (n, min, median, max) over active priced listings, and a sample with portal, listing URL, country/region, first and last seen and effectiveStatus (active, stale = not re-seen for 30+ days, expired = 60+ days). Listings the source portal marks as sale suspended are NOT active: they are left out of activeCount, priceStats and the sample and reported in suspendedCount (the seller withdrew the offer; it is not a sale). Prices as advertised by portals, not appraisals. Optional spec_filters (engine_program, no_damage_history, wifi, max_engine_hours, avionics, year_min) filter by the listing spec sheet, i.e. what the seller DECLARED in the ad, not verified by Jet Tracker: the result gains spec_matches (matching listings, cheapest first) plus withSpecsCount, the number of listings of the model that carry a spec sheet. A criterion only matches when the ad states it, so an empty spec_matches with a low withSpecsCount means unknown, not none.

Input Schema

Name	Required	Description	Default
`slug`	Yes	Slug do modelo (ex: embraer-phenom-300).
`spec_filters`	No	Filtros pela FICHA TÉCNICA do anúncio (o que o anunciante declarou). Opcional. Quando presente, a resposta ganha `spec_matches` com os anúncios que afirmam os critérios; anúncio que não informa fica de fora, então leia `withSpecsCount` antes de dizer "não há nenhum".

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 changedOct 9, 2026

addedInput schema / properties / spec_filters

Added value: +{
+  "description": "Filtros pela FICHA TÉCNICA do anúncio (o que o anunciante declarou). Opcional. Quando presente, a resposta ganha `spec_matches` com os anúncios que afirmam os critérios; anúncio que não informa fica de fora, então leia `withSpecsCount` antes de dizer \"não há nenhum\".",
+  "properties": {
+    "avionics": {
+      "description": "Trecho da suíte de aviônicos (ex: \"G1000\", \"Pro Line 21\").",
+      "maxLength": 40,
+      "minLength": 2,
+      "type": "string"
+    },
+    "engine_program": {
+      "description": "true = só anúncio que declara motor em programa (JSSI, ESP, MSP, TAP...).",
+      "type": "boolean"
+    },
+    "max_engine_hours": {
+      "description": "Teto de horas do motor mais rodado (desde a revisão geral quando informado, senão desde novo).",
+      "exclusiveMinimum": 0,
+      "maximum": 30000,
+      "type": "integer"
+    },
+    "no_damage_history": {
+      "description": "true = só anúncio que declara não ter histórico de dano.",
+      "type": "boolean"
+    },
+    "wifi": {
+      "description": "true = só anúncio que declara conectividade de cabine.",
+      "type": "boolean"
+    },
+    "year_min": {
+      "description": "Ano de fabricação mínimo.",
+      "maximum": 2100,
+      "minimum": 1950,
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

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

First observedSep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description layers on substantial semantics they cannot convey: the active/stale(30+ days)/expired(60+ days) definitions, the treatment of sale-suspended offers in activeCount, priceStats and the sample, and the caveat that prices are portal-advertised, not appraised. The declared-vs-verified distinction for spec filters is exactly the kind of behavioral caveat an agent needs.

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?

Front-loaded with the resource definition, then the status semantics, then the optional filter behavior — a logical order with no filler sentences. It is dense and sentence-heavy, packing several clauses per sentence, which costs some scannability but every clause carries a distinct rule.

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 tool with nested spec_filters and an output schema, the description supplies everything an agent needs to call and interpret it: counting rules, status thresholds, excluded populations, filter semantics and the withSpecsCount caveat. Return-value detail is largely carried by the output schema, so no gap remains.

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 description coverage is 100%, so the baseline is 3; the description earns more by clarifying that slug accepts an alias and covers the whole model family, and by re-framing spec_filters as filtering on what the seller DECLARED, with an explicit empty-result interpretation rule (unknown, not none). It adds meaning beyond the per-field schema text rather than restating it.

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 precise verb+resource — for-sale listings for a catalog model (slug or alias, whole family) — and immediately bounds the scope with what is and is not counted (suspended offers excluded). An agent can distinguish this from jt_price_history or jt_model_specs without opening any schema, because the description defines exactly which population and which fields are returned.

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?

Gives clear operational context: spec_filters are optional, only match what the seller declared, and when present the response gains spec_matches/withSpecsCount; it also instructs the agent to read withSpecsCount before concluding 'nothing exists'. It stops short of naming alternative tools (e.g. jt_price_history, jt_sale_propensity) or stating explicit when-not-to-use conditions.

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?