Stormworks MCP

by macery12

Overview Schema Source Related Servers Discussions Admin

Python

Local

open_in_viewer

Idempotent

Launches a vehicle or design in an interactive 3D browser viewer so the player can orbit and inspect it directly.

Instructions

Open a vehicle or design in the interactive 3D viewer in the player's web browser so they can orbit and inspect it themselves. You cannot see that window: use inspect_view or the preview tools to look yourself. Writes one temporary HTML page, replaced on each call, and changes nothing else. Uses installed component meshes with explicit fallbacks; articulated vehicles show the largest body alone unless body_id is given.

Input Schema

Name	Required	Description	Default
`name`	No	Saved vehicle, or numeric Workshop item with source=workshop.
`spec`	No	Hull spec, partial or full (fields: hull_design_guide topic=spec); merged over preset or design. Lengths in metres.
`patch`	No	JSON-Patch ops applied last, e.g. [{"op": "replace", "path": "/superstructure/bridge/height", "value": 2.5}]; list items can be named instead of indexed.
`design`	No	Stored hull, land or imported draft to show.
`preset`	No	Built-in hull preset to start from, e.g. 'runabout'; names from list_hull_presets.
`source`	No	"vehicles" (default) reads the player's vehicles folder; "workshop" reads an installed Workshop item by numeric ID.	vehicles
`body_id`	No	unique_id of one body of a multi-body vehicle; default is the largest body. Saved vehicles only.
`spec_path`	No	Path to a .json file holding a spec or a stored design, read before spec and patch.
`diagnostics`	No	Overlay preflight faults and steering arrows; needs design alone.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.2.0Oct 30, 2026

addedInput schema / properties / body_id / description

Added value: +"unique_id of one body of a multi-body vehicle; default is the largest body. Saved vehicles only."

addedInput schema / properties / design / description

Added value: +"Stored hull, land or imported draft to show."

addedInput schema / properties / diagnostics / description

Added value: +"Overlay preflight faults and steering arrows; needs design alone."

addedInput schema / properties / name / description

Added value: +"Saved vehicle, or numeric Workshop item with source=workshop."

addedInput schema / properties / patch / description

Added value: +"JSON-Patch ops applied last, e.g. [{\"op\": \"replace\", \"path\": \"/superstructure/bridge/height\", \"value\": 2.5}]; list items can be named instead of indexed."

addedInput schema / properties / preset / description

Added value: +"Built-in hull preset to start from, e.g. 'runabout'; names from list_hull_presets."

addedInput schema / properties / source / description

Added value: +"\"vehicles\" (default) reads the player's vehicles folder; \"workshop\" reads an installed Workshop item by numeric ID."

addedInput schema / properties / spec / description

Added value: +"Hull spec, partial or full (fields: hull_design_guide topic=spec); merged over preset or design. Lengths in metres."

addedInput schema / properties / spec_path / description

Added value: +"Path to a .json file holding a spec or a stored design, read before spec and patch."

Changed3 schema fields changedv0.1.1Oct 7, 2026

addedInput schema / properties / body_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Body Id"
+}

addedInput schema / properties / diagnostics

Added value: +{
+  "default": false,
+  "title": "Diagnostics",
+  "type": "boolean"
+}

addedInput schema / properties / source

Added value: +{
+  "default": "vehicles",
+  "title": "Source",
+  "type": "string"
+}

First observedv0.1.0Oct 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare a non-read-only, idempotent, non-destructive write; the description explains exactly what that write is ('one temporary HTML page, replaced on each call, and changes nothing else'), which confirms and sharpens the annotation profile. It additionally discloses rendering behavior an agent could not otherwise know: installed component meshes with explicit fallbacks, and that articulated vehicles render only the largest body unless body_id is set.

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, each carrying distinct information: what it does, why the agent must delegate viewing, the exact write side effect, and the rendering/articulation caveat. Nothing is repeated from the schema or wasted.

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 9-parameter tool with full schema coverage, an output schema, and supporting annotations, the description supplies the remaining context an agent needs: the invisible-to-caller nature of the viewer, the precise mutation footprint, and the articulation/mesh defaults. Nothing material 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; the description goes beyond it by explaining the articulation default ('largest body alone unless body_id is given') and the mesh/fallback sourcing. It doesn't add detail on source/spec_path/patch interplay, so it is strong rather than exhaustive.

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 target ('Open a vehicle or design in the interactive 3D viewer in the player's web browser') plus the outcome ('so they can orbit and inspect it themselves'). It explicitly names the sibling it is not ('use inspect_view or the preview tools to look yourself'), so an agent can distinguish it without opening a 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?

Explicitly says the agent cannot see the rendered window and names the alternatives (inspect_view, preview tools) with the condition that selects them. It also states which condition requires body_id, giving concrete when-to-use routing for the main optional parameter.

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

Deploy Server