Stormworks MCP

Overview Schema Source Related Servers Discussions Admin

apply_vehicle_assembly

Destructive

Wire reusable vehicle control assemblies—engine start/idle, clutch, brake/reverse, or lights—to current part IDs, replacing existing drivers atomically in one undo step.

Instructions

Configure and wire a reusable control set-up (starter and idle, clutch, brake/reverse or lights) using explicit current part ids, instead of wiring each link with edit_connections. Existing drivers of the target inputs are replaced atomically. Clutch needs its own gate, separate from the idle throttle gate. Starter is manual/hold; idle is open-loop, and reverse must be selected while stopped. engine_start_idle takes one engine id or a list (twins share the throttle gate and starter). Returns the operations and a compact preflight (detail=true for all of it, preview=true for the diagnostic image); commit=true creates one undo step. Tune behaviour in game.

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).
`detail`	No	true lists every check and each finding's repair operations; false (default) lists only faults, each once.
`options`	No	Idle throttle, clutch deadband and hotkeys; defaults suit most builds.
`preview`	No	true also returns the rendered preview image and the full build notes; false (default) returns a compact list of what changed, warnings and the new revision.
`assembly`	Yes	Assembly to wire; list_vehicle_assemblies explains each.
`bindings`	Yes	Current part ids from query_connections: driver seat, and the engine, gates, clutch, gearbox, wheels, lights or battery the assembly needs.
`revision`	Yes	The draft's current revision from query_parts or query_connections; a stale one is rejected.

Output Schema

Name	Required	Description	Default
`assembly`	Yes
`bindings`	Yes
`revision`	Yes
`committed`	Yes
`preflight`	Yes
`operations`	Yes
`verification`	Yes
`base_revision`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.2.0Oct 30, 2026

changedInput schema / $defs / AssemblyBindings / properties / engine / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / assembly / description

Added value: +"Assembly to wire; list_vehicle_assemblies explains each."

addedInput schema / properties / bindings / description

Added value: +"Current part ids from query_connections: driver seat, and the engine, gates, clutch, gearbox, wheels, lights or battery the assembly needs."

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 / detail

Added value: +{
+  "default": false,
+  "description": "true lists every check and each finding's repair operations; false (default) lists only faults, each once.",
+  "title": "Detail",
+  "type": "boolean"
+}

addedInput schema / properties / options / description

Added value: +"Idle throttle, clutch deadband and hotkeys; defaults suit most builds."

addedInput schema / properties / preview

Added value: +{
+  "default": false,
+  "description": "true also returns the rendered preview image and the full build notes; false (default) returns a compact list of what changed, warnings and the new revision.",
+  "title": "Preview",
+  "type": "boolean"
+}

addedInput schema / properties / revision / description

Added value: +"The draft's current revision from query_parts or query_connections; a stale one is rejected."

Addedv0.1.1Oct 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructive=true and non-idempotent, and the description adds the crucial detail that existing drivers of the target inputs are replaced atomically, plus that commit=true creates a single undo step and stale revisions are rejected. That is genuine value beyond the annotations, though the return-behaviour sentences largely restate schema parameter descriptions rather than adding new behaviour.

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 purpose and the edit_connections contrast are front-loaded, but the middle collapses into a run-on chain of build rules and flag semantics that mirror the schema, and the trailing 'Tune behaviour in game' earns little. It could be split into short usage and returns lines without losing content.

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

Completeness4/5

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

With annotations, an output schema and fully described parameters carrying the structured load, the description supplies what's missing: assembly preconditions, replacement atomicity, and the preview/commit workflow. An agent has enough to call it correctly; only explicit failure modes (beyond stale revisions) are absent.

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?

With 100% schema description coverage the baseline is 3, but the description adds real semantics: the engine field accepts one id or a list (twins share throttle gate and starter) and the clutch gate must be distinct from the idle throttle gate. These are cross-parameter constraints the schema cannot express.

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?

Opens with a specific verb and resource ('Configure and wire a reusable control set-up') and enumerates exactly which sub-assemblies are covered. It also explicitly contrasts itself with the sibling edit_connections, so an agent can pick between them without opening either schema.

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?

States the alternative ('instead of wiring each link with edit_connections') and the precondition (explicit current part ids from query_connections). It also gives per-assembly constraints — clutch needs its own gate, starter is manual/hold, reverse must be selected while stopped — which steers correct invocation.

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

Deploy Server