Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

preview_game_vehicle

Read-onlyIdempotent

Render a saved or Workshop Stormworks vehicle to an image with size and part summary, optionally focusing on one body or detail for inspection.

Instructions

Render a vehicle from the player's vehicles folder or an installed Workshop item and return the image plus a size and part summary, e.g. to study the player's existing boats. Uses installed component meshes, reporting any footprint fallbacks. Articulated vehicles show the largest body alone unless body_id is given. inspect_view points a camera at one detail; drafts use preview_vehicle. Read-only.

Input Schema

NameRequiredDescriptionDefault
nameYesVehicle file name without .xml in the player's vehicles folder (see list_game_vehicles); with source=workshop, the numeric Steam Workshop item ID.
sourceNo"vehicles" (default) reads the player's vehicles folder; "workshop" reads an installed Workshop item by numeric ID.vehicles
body_idNounique_id of one body of a multi-body vehicle; default is the largest body. Saved vehicles only.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.0
    • 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 / name / description
      Added value: +"Vehicle file name without .xml in the player's vehicles folder (see list_game_vehicles); with source=workshop, the numeric Steam Workshop item ID."
    • 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 / source / description
      Added value: +"\"vehicles\" (default) reads the player's vehicles folder; \"workshop\" reads an installed Workshop item by numeric ID."
  2. Changed2 schema fields changedv0.1.1
    • addedInput schema / properties / body_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Body Id"
+}
    • addedInput schema / properties / source
      Added value: +{
+  "default": "vehicles",
+  "title": "Source",
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real behavior: meshes come from installed components, footprint fallbacks are reported, and articulated vehicles render only the largest body unless body_id is set. 'Read-only' merely repeats the annotation and the return-image details are thin, but the fallback and articulation notes are genuinely non-obvious.

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?

Front-loads the core action and output in the first sentence, then layers routing and caveats. The later sentences are semicolon-chained and slightly scattered ('inspect_view points a camera at one detail; drafts use preview_vehicle. Read-only.'), and 'Read-only' is redundant with annotations, but nothing is padded.

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?

No output schema exists, so the description must characterize the return value; it does ('the image plus a size and part summary'). Combined with fallback-reporting and articulation notes, this is nearly complete, though it says little about error cases (missing vehicle, unresolvable Workshop ID) for a tool that depends on external installed content.

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 baseline is 3; the description earns above that by explaining the runtime consequence of body_id (articulated vehicles default to the largest body alone) and by situating body_id in the study/inspection workflow. It does not add renderer or source semantics beyond the schema, keeping it from a 5.

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 vehicle') plus the two source scopes (player's vehicles folder, installed Workshop item) and the output (image plus size and part summary). It distinguishes itself from siblings by naming preview_vehicle (drafts) and inspect_view (single-detail camera) as different tools.

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?

Gives a concrete use case ('study the player's existing boats') and explicit routing: drafts go to preview_vehicle, single-detail framing goes to inspect_view. The condition selecting body_id (articulated vs. largest body) is also given, so the agent knows when to supply it.

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