Windsock

Search aircraft by description

suggest_aircraft_search

Read-only

Describe the aircraft (and owners) you want in plain words, e.g. "Cirrus SR22s in Texas bought in the last two years" or "twin pistons near Denver with an autopilot that haven't flown in a year", and get back search filters (make/model, type, place, year, avionics, flying, ownership, accidents, market balance and more) with a one-line reading of the request and anything that couldn't be expressed. Set execute=true to also get the matching aircraft. To page or re-run, send the returned filters back without a prompt (no new model call). The filters use a wider vocabulary than search_aircraft, so run them here. One call per second.

PRO FILTERS (marked pro: true; need Windsock Pro or a paid API plan to run): avionics (avionics_categories, standardized_avionic_ids), owner profile (pilot_type, pilot_level, med_class, end_of_career_pilot), ownership timing (current_owner_start_date, inferred_sale_date: estimated from the first new-owner FAA registration date minus the 30-day median processing lag, not a verified closing date; num_unique_faa_registrants, avg_owner_hold_years: average years each owner on record has kept it), registration status (registration_pending, up_for_renewal_soon, expiration_date), flying activity (last_airborne_at, flight_hours_last_year, adsb_signal_strength, and last_seen_state / last_seen_near: where ADS-B last saw it, as opposed to state / location_point, where it lives; utilization_vs_peers: low, typical or high days flown in the last year against similar aircraft; utilization_trend: down for a lasting recent drop against its own usual flying, or steady), market_balance, and the score levels sale_likelihood (how likely to sell in the next few months) and dealflow (how quickly it would sell at its value) — each is high, medium or low, thirds of US aircraft — and estimated_value (Windsock's weekly preliminary value in US dollars; gt, gte, lt or lte). Without Pro, the answer still shows them but lists them under locked with an upgrade link and does not run the search: tell the user which filters need Pro, or drop them and re-run with the rest.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "suggest_aircraft_search"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Rows per page when executing, 1–200 (default 25).
`offset`	No	Pagination offset when executing (default 0).
`prompt`	No	What you're looking for, up to 600 characters. Omit to run `filters` from an earlier answer.
`execute`	No	Also run the search and return matching aircraft (default false).
`filters`	No	Filters from an earlier answer, run as given. Ignored when `prompt` is sent.
`sort_field`	No	Overrides the suggested sort.
`sort_direction`	No

Output Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedOutput schema / properties / data / properties / filters / items / properties

Added value: +{
+  "condition": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "field_name": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "label": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "pro": {
+    "description": "A Pro filter: runs only with Windsock Pro or a paid API plan.",
+    "type": [
+      "boolean",
+      "null"
+    ]
+  },
+  "value": {}
+}

addedOutput schema / properties / data / properties / locked

Added value: +{
+  "description": "Present when Pro filters are in the set and the caller lacks Pro: the search was not run.",
+  "properties": {
+    "filters": {
+      "items": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "message": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "upgrade_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

AddedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare this a non-destructive open-world read; the description goes well beyond them by disclosing the rate limit, the no-new-model-call replay path, and the non-obvious behavior that non-Pro filters are returned under `locked` with an upgrade link and the search does not run. It also flags estimation caveats, e.g. inferred_sale_date is derived from registration dates minus a median lag rather than a verified closing date.

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

Conciseness3/5

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

The core workflow is front-loaded in the first four sentences and earns its place, but the PRO FILTERS block is a dense paragraph of reference material that is long relative to what an agent needs to select and invoke the tool. Some of it is genuinely useful disambiguation (last_seen_state vs state, utilization_trend), while other entries are verbose definitions that dilute the actionable instructions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema, a 7-parameter schema and solid annotation coverage, the description is largely complete: workflow, pagination, replay, rate limit and Pro gating are all covered. The gaps are structural rather than missing content — the huge filter enumeration crowds out a crisp statement of how prompt and filters interact in practice and what happens to leftover locked filters when execute=true.

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 coverage is 86%, so the schema already explains limit, offset, prompt, execute and filters, including that filters is ignored when prompt is sent. The description adds value by naming the filter vocabulary (make/model, avionics, utilization_vs_peers, sale_likelihood, estimated_value, etc.) that the opaque field_name field does not expose, but it does not document sort_field/sort_direction behavior beyond 'overrides the suggested sort'.

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 verb and resource: turns a plain-language aircraft description into structured search filters, optionally executing the search. It also explicitly differentiates from the sibling search_aircraft, directing agents to run these wider-vocabulary filters here rather than through that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Covers when to set execute=true versus filter-only, how to page or re-run by sending filters back without a prompt (no new model call), and the one-call-per-second limit. It adds concrete Pro handling instructions: surface the locked filters to the user or drop them and re-run with the rest.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Windsock 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.