Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

inspect_view

Render a pointable camera view of a hull or saved Stormworks vehicle to inspect details fixed previews hide, with adjustable angle, zoom, focus, and highlights.

Instructions

Render one large view of a hull design or saved vehicle from any angle, like a camera you can point. Use it to check details the fixed previews hide.

name: a vehicle in the player's vehicles folder, or pass spec/preset/design(+patch). yaw: 0 = side view with bow to the right, 90 = from the bow, 180 = other side, 270 = stern. pitch: degrees above (+) or below (-) the horizon; -30 shows the hull bottom. zoom: 1 = whole vehicle, 2-6 = close-up. focus: [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. highlight: a superstructure box name (designs only): painted magenta and labelled, and its position is reported 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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yawNo
nameNo
specNo
zoomNo
focusNo
patchNo
pitchNo
designNo
presetNo
sourceNovehicles
body_idNo
highlightNo
spec_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it explains the camera model, the meaning of each angle/zoom/focus input, and what the render adds (magenta-labeled superstructure, spec/metre rulers, keel/transom reference). It never explicitly states the operation is side-effect free, which is the main gap.

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?

Purpose is front-loaded in the first sentence, then parameter semantics follow compactly. Dense but each line adds real meaning; only the trailing ruler note is slightly tangential.

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

Completeness3/5

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

For a 13-parameter render tool with no annotations and no output schema, the description covers the viewing behavior and output additions well but omits several input parameters and any explicit statement of side effects or prerequisite for the various source modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 0% schema description coverage the description must compensate, and it documents the key viewing parameters richly (yaw orientation, pitch sign, zoom ranges, focus fractions, highlight). However source, body_id, and spec_path are left undocumented and spec/patch/design/preset are only name-dropped, so coverage is partial.

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 from any angle') and contrasts it with the fixed previews, letting an agent distinguish it from siblings like preview_hull/preview_vehicle 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use it to check details the fixed previews hide' gives a clear context for selecting this over the fixed-preview siblings. It stops short of naming the specific alternatives or stating exclusions, so it is not a full 5.

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