Windsock

Correct the facts on a portfolio aircraft

update_portfolio_aircraft

Change what is on file about one aircraft in a portfolio you own, whether it is still in the portfolio or has left it. Send only what changes. On an aircraft still in the portfolio, facts the valuation depends on (tail, year, hours, engine times, condition, location, the date it came in) re-price its history, which takes a minute or two (repricing is true in the reply). On one that has left, every change is recorded, and one that would have moved its value history (those facts, or an exit moved later) has that history priced again in place, up to the day it left: the reply says repricing and value_history_stale, and list_portfolio_archived_aircraft shows value_history_stale false once the new values are in (a minute or two). The entry price, asking price, notes and the exit facts (why it left, when, for how much) never affect values. Exit facts apply only to an aircraft that has left. This does not change an aircraft's make and model, and does not add, archive, restore or delete aircraft. Confirm the change with the user before calling.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "line_id": "<line_id>"
    },
    "name": "update_portfolio_aircraft"
  }
}

Input Schema

Name	Required	Description
`aftt`	No	Airframe total time, hours.
`year`	No	Model year.
`notes`	No	Free-text notes on the aircraft.
`reg_no`	No	Tail number, e.g. "N62WP".
`smoh_1`	No	Engine 1 hours since major overhaul.
`smoh_2`	No	Engine 2 hours since major overhaul (twins).
`line_id`	Yes	From list_portfolio_aircraft or list_portfolio_archived_aircraft.
`exit_date`	No	Archived aircraft only: YYYY-MM-DD it left.
`exit_note`	No	Archived aircraft only: a note on the exit. An empty string clears it.
`listed_on`	No	YYYY-MM-DD it was listed for sale.
`exit_value`	No	Archived aircraft only: USD it left for (the sale price, or the last asking price).
`exit_reason`	No	Archived aircraft only: why it left.
`asking_price`	No	Current (or last) asking price, USD.
`location_text`	No	Where it is based, e.g. "Portland, OR".
`acquisition_date`	No	YYYY-MM-DD: the day it came into the portfolio (bought, financed, or listed for sale).
`exterior_quality`	No	Exterior condition, a grade from 1 (worst) to 10 (like-new). A fraction below 1 is read on the legacy 0–1 scale.
`interior_quality`	No	Interior condition, a grade from 1 (worst) to 10 (like-new). A fraction below 1 is read on the legacy 0–1 scale.
`acquisition_value`	No	USD it came in at: the purchase price, or for an aircraft listed for sale the first asking price.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / reg_no / description

Previous value: -"Tail number, e.g. \"N7571T\"."New value: +"Tail number, e.g. \"N62WP\"."

Changed2 schema fields changedOct 18, 2026

changedInput schema / properties / exterior_quality / description

Previous value: -"Exterior condition, 1–10 (10 = like-new). Caution: values <= 1 are read on the legacy 0–1 scale, so a literal 1 means like-new, NOT the worst grade — send 0.1 for the worst."New value: +"Exterior condition, a grade from 1 (worst) to 10 (like-new). A fraction below 1 is read on the legacy 0–1 scale."

changedInput schema / properties / interior_quality / description

Previous value: -"Interior condition, 1–10 (10 = like-new). Caution: values <= 1 are read on the legacy 0–1 scale, so a literal 1 means like-new, NOT the worst grade — send 0.1 for the worst."New value: +"Interior condition, a grade from 1 (worst) to 10 (like-new). A fraction below 1 is read on the legacy 0–1 scale."

Changed2 schema fields changedOct 8, 2026

changedOutput schema / properties / data / properties / repricing / description

Previous value: -"A held aircraft is being valued again; values settle in a minute or two."New value: +"The aircraft is being valued again; values settle in a minute or two."

changedOutput schema / properties / data / properties / value_history_stale / description

Previous value: -"An archived aircraft's value history predates this correction."New value: +"An archived aircraft's value history predates this correction until the re-valuing lands."

AddedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the read-only/destructive/open-world profile; the description goes well beyond by disclosing that valuation-relevant edits trigger repricing that takes a minute or two, that the reply surfaces repricing and value_history_stale, how to confirm completion via list_portfolio_archived_aircraft, and precisely which fields never affect values. This is unusually rich consequence disclosure for a mutation tool.

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?

Every sentence carries information and the purpose is front-loaded, with no filler. It is a dense single block of prose covering many conditional rules, so it could be easier to scan if split into active-vs-archived structure, but nothing is redundant.

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 an 18-parameter mutation tool with annotations and an output schema, the description covers the pieces an agent still needs: partial-update semantics, asynchronous repricing and its evidence in the reply, archived-only field scoping, and hard exclusions. Return-value details are correctly delegated to the output schema.

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 per-field meaning is already documented and the baseline would be 3. The description earns above baseline by grouping parameters semantically (valuation-driving facts vs. entry price, asking price, notes, and exit facts) and by tying exit_reason/exit_date/exit_value to the archived-only condition, which the schema states per field but the description frames as a rule.

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 opens with a specific verb and resource: change what is on file about one aircraft in a portfolio you own, and immediately scopes it to both active and departed aircraft. It then explicitly excludes the neighboring operations (does not change make/model, does not add, archive, restore or delete), which cleanly separates it from siblings like list_portfolio_archived_aircraft and value_aircraft.

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?

It states when to use it (correcting facts on an owned aircraft, in or out of the portfolio), what to send (only what changes), and what it cannot do, plus a procedural precondition: confirm the change with the user before calling. Exit-fact applicability is explicitly limited to aircraft that have left, so misuse is hard.

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.