Stormworks MCP

Overview Schema Source Related Servers Discussions Admin

repair_vehicle

Destructive

Apply selected repair findings from a vehicle repair plan to a draft, previewing changes first or committing them as one undo step. Reject stale plans and conflicting fixes.

Instructions

Apply chosen fixes from plan_vehicle_repairs to a draft; previews by default, with overlays and a before/after preflight. commit=true applies the batch as one undo step; rerun preflight_vehicle afterwards. Stale revisions or plans and conflicting repairs are rejected. Manual findings need a design choice and are never applied here.

Input Schema

Name	Required	Description
`commit`	No	false (default) previews without changing the draft; true applies it as one undo step.
`design`	Yes	Stored draft name (from import_vehicle, create_land_vehicle, store_design or save_hull; see list_designs).
`plan_id`	Yes	plan_id returned by plan_vehicle_repairs.
`revision`	Yes	Revision returned by plan_vehicle_repairs.
`finding_ids`	Yes	Ids of findings with repair_status=available to apply together.

Output Schema

Name	Required	Description	Default
`after`	Yes
`before`	Yes
`revision`	Yes
`committed`	Yes
`base_revision`	Yes
`resolved_finding_ids`	Yes
`remaining_finding_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.0Oct 30, 2026

addedInput schema / properties / commit / description

Added value: +"false (default) previews without changing the draft; true applies it as one undo step."

addedInput schema / properties / design / description

Added value: +"Stored draft name (from import_vehicle, create_land_vehicle, store_design or save_hull; see list_designs)."

addedInput schema / properties / finding_ids / description

Added value: +"Ids of findings with repair_status=available to apply together."

addedInput schema / properties / plan_id / description

Added value: +"plan_id returned by plan_vehicle_repairs."

addedInput schema / properties / revision / description

Added value: +"Revision returned by plan_vehicle_repairs."

Addedv0.1.1Oct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description adds real context beyond them: dry-run by default, the batch lands as a single undo step, stale plan/revision inputs are rejected rather than coerced, and manual findings are out of scope. That is substantive disclosure about safety, atomicity and failure modes.

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

Conciseness5/5

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

Four short sentences, front-loaded with what the tool does and the preview-by-default behaviour, then commit semantics, then follow-up and rejection rules. No restatement of the name and no filler.

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 destructive, non-idempotent batch mutation with an output schema, the description covers the safety profile, atomicity, required follow-up and rejection conditions. Return values are already documented by the output schema, so nothing an agent needs to call this correctly is missing.

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 the baseline is 3, but the description earns extra credit by defining the failure semantics of plan_id/revision (stale values are rejected) and by tying 'design' to the manual-findings design-choice requirement. It stops short of explaining finding_ids selection criteria beyond what the schema already 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?

States a specific verb+resource ('Apply chosen fixes from plan_vehicle_repairs to a draft') and names the upstream sibling it consumes output from. It also separates itself from the neighbouring preflight_vehicle and from manual-finding handling, so an agent can place it precisely in the workflow.

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?

Explicitly says the default is a preview and that commit=true is the write path, plus a required follow-up ('rerun preflight_vehicle afterwards'). It also names when the call will fail (stale revisions or plans, conflicting repairs) and what it will never do (apply manual findings), which is exactly the when/when-not guidance an agent needs.

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

Deploy Server