Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

inspect_view

Read-onlyIdempotent

Render a custom large view of a hull or vehicle from any angle to inspect details hidden by fixed previews; returns image with caption and optional highlight position and metre rulers.

Instructions

Render one large view of a hull design or saved vehicle from any angle, like a camera you can point, to check details the fixed previews hide. Returns the image and a caption; with highlight, the box's position in spec units and as game-metre heights above the keel. Views at pitch 0 or +-90 get metre rulers in spec units (z from the transom, y from the keel, x from the centreline). Use preview_hull for the standard set of views. Read-only.

Input Schema

NameRequiredDescriptionDefault
yawNoCamera heading in degrees: 0 = side with bow right, 90 = bow, 180 = other side, 270 = stern.
nameNoSaved vehicle to view; omit to build spec/preset/design instead.
specNoHull spec, partial or full (fields: hull_design_guide topic=spec); merged over preset or design. Lengths in metres.
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.
patchNoJSON-Patch ops applied last, e.g. [{"op": "replace", "path": "/superstructure/bridge/height", "value": 2.5}]; list items can be named instead of indexed.
pitchNoCamera degrees above (+) or below (-) the horizon; -30 shows the bottom.
designNoStored design to start from instead of a preset; names from list_designs.
presetNoBuilt-in hull preset to start from, e.g. 'runabout'; names from list_hull_presets.
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.
highlightNoSuperstructure box name to paint magenta, label and report the position of (designs only).
spec_pathNoPath to a .json file holding a spec or a stored design, read before spec and patch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 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 / design / description
      Added value: +"Stored design to start from instead of a preset; names from list_designs."
    • 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 / highlight / description
      Added value: +"Superstructure box name to paint magenta, label and report the position of (designs only)."
    • addedInput schema / properties / name / description
      Added value: +"Saved vehicle to view; omit to build spec/preset/design instead."
    • 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 / pitch / description
      Added value: +"Camera degrees above (+) or below (-) the horizon; -30 shows the bottom."
    • 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 / 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."
    • 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."
    • addedInput schema / properties / yaw / description
      Added value: +"Camera heading in degrees: 0 = side with bow right, 90 = bow, 180 = other side, 270 = stern."
    • addedInput schema / properties / zoom / description
      Added value: +"1 = whole vehicle, 2-6 = close-up."
  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, and the description's closing 'Read-only' merely restates them. It does add real behavioral detail beyond annotations: what is returned (image plus caption), that highlight yields box position in spec units and game-metre heights above the keel, and that pitch 0 or ±90 triggers metre rulers with defined axes.

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-loaded with the core action and its differentiator before the return-value and ruler details. Dense but mostly earns its space; the parenthetical axis definitions and the redundant 'Read-only' tail are the only mild padding.

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 14 optional parameters and no output schema, the description usefully documents the return shape (image plus caption, plus highlight coordinates) and one important rendering behavior. Gaps remain around failure modes and how source/workshop interplay with name, though the schema covers those fields well.

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 tying specific parameter values to observable output — the ruler behavior at pitch 0/±90 and the extra positional reporting when highlight is set. These are cross-parameter consequences the per-field schema text does not state.

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 one large view of a hull design or saved vehicle — with the framing 'like a camera you can point' that distinguishes it from fixed-angle preview tools. The contrast with 'the fixed previews' makes the scope unambiguous against siblings like preview_hull and preview_interior.

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 routes the agent: use this to inspect details the fixed previews hide, and use preview_hull for the standard set of views. That names the alternative and the condition that selects it, leaving little to inference.

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