Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

preview_vehicle

Read-onlyIdempotent

Render a stored Stormworks vehicle draft to an image with installed components, adjustable camera views, and a components layer for inspecting seats, tanks, and powertrain.

Instructions

Render a draft (imported, land or edited hull) with installed component meshes and return the image plus notes. yaw/pitch/zoom/focus give a close-up; layer=components hides bodywork to inspect seats, tanks and powertrain. Hull specs use preview_hull and vehicles in the game folder use preview_game_vehicle. Paint and wheel poses are approximate; the image is not an in-game screenshot. Read-only.

Input Schema

NameRequiredDescriptionDefault
yawNoCamera heading in degrees (0 = side, 90 = front); default is a 3/4 view.
zoomNo1 = whole vehicle, 2-6 = close-up.
focusNo[fx, fy, fz] fractions of the bounding box to centre on (x across, y up, z stern to bow), e.g. [0.5, 0.3, 0.9] = low on the bow.
layerNo"all", "components" (hides bodywork to show seats, tanks, powertrain) or "structure".all
pitchNoCamera degrees above (+) or below (-) the horizon; -30 shows the bottom.
designYesStored draft name (from import_vehicle, create_land_vehicle, store_design or save_hull; see list_designs).
rendererNo"auto" (default) lights the scene like the game, on the GPU when available; "gpu"/"cpu" force one; "flat" is fastest and unlit, with block outlines for counting blocks.
door_stateNoShow manual doors closed or open.closed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.0
    • 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 / door_state / description
      Added value: +"Show manual doors closed or open."
    • addedInput schema / properties / focus / description
      Added value: +"[fx, fy, fz] fractions of the bounding box to centre on (x across, y up, z stern to bow), e.g. [0.5, 0.3, 0.9] = low on the bow."
    • addedInput schema / properties / layer / description
      Added value: +"\"all\", \"components\" (hides bodywork to show seats, tanks, powertrain) or \"structure\"."
    • addedInput schema / properties / pitch / description
      Added value: +"Camera degrees above (+) or below (-) the horizon; -30 shows the bottom."
    • addedInput schema / properties / renderer
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "auto",
+        "gpu",
+        "cpu",
+        "flat"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "\"auto\" (default) lights the scene like the game, on the GPU when available; \"gpu\"/\"cpu\" force one; \"flat\" is fastest and unlit, with block outlines for counting blocks.",
+  "title": "Renderer"
+}
    • addedInput schema / properties / yaw / description
      Added value: +"Camera heading in degrees (0 = side, 90 = front); default is a 3/4 view."
    • addedInput schema / properties / zoom / description
      Added value: +"1 = whole vehicle, 2-6 = close-up."
  2. Addedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the trailing "Read-only" adds nothing. What the description does add is genuinely useful: paint and wheel poses are approximate and the output is not an in-game screenshot, which sets expectations for a render tool. It stops short of covering render cost, resolution or the format of the returned notes.

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?

Four short sentences, front-loaded with the core action and output, then routing, then fidelity caveats. The trailing "Read-only." is redundant with annotations and is the one phrase that doesn't earn its place.

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?

Covers what it renders, what it returns (image plus notes), how to steer the camera, how to inspect internals, which sibling to use for other design sources, and the fidelity limits. With no output schema, the brief "image plus notes" note is enough to set expectations for an agent calling an 8-parameter render tool.

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% with per-parameter descriptions including camera angle conventions, so the baseline is 3. The description adds use-case semantics the schema doesn't — that yaw/pitch/zoom/focus are meant to be combined for a close-up and that layer=components hides bodywork to expose seats, tanks and powertrain.

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 ("Render a draft ... with installed component meshes and return the image plus notes") and scopes the accepted design types (imported, land, edited hull). It explicitly distinguishes itself from preview_hull and preview_game_vehicle, so an agent can pick the right preview tool 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?

Names two alternatives with the exact condition that selects each: hull specs go to preview_hull, vehicles in the game folder go to preview_game_vehicle. It also gives an in-tool routing hint for close-ups via yaw/pitch/zoom/focus and layer=components for hiding bodywork.

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

Deploy Server

Other Tools