Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

preview_hull

Read-onlyIdempotent

Builds a hull and returns preview images plus a text summary of size, part counts, deck heights, flotation, bench fit, and warnings for comparing against a brief and iterating before saving.

Instructions

Build a hull and return a preview image (3/4 views from above and below, front, side, top) plus a text summary: size, part counts, deck heights, flotation estimate, bench fit and warnings. This is the design loop: preview, compare the image with the player's brief, adjust, repeat, then save_hull. Use inspect_view for one large close-up from any angle and preview_interior for rooms. Nothing is written. Spec sources apply in order: preset or design, spec_path, spec, patch.

Input Schema

NameRequiredDescriptionDefault
specNoHull spec, partial or full (fields: hull_design_guide topic=spec); merged over preset or design. Lengths in metres.
patchNoJSON-Patch ops applied last, e.g. [{"op": "replace", "path": "/superstructure/bridge/height", "value": 2.5}]; list items can be named instead of indexed.
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.
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.
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. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / design / description
      Added value: +"Stored design to start from instead of a preset; names from list_designs."
    • 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 / 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 / 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."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered; the description reinforces it with "Nothing is written" but adds little beyond that. It does add genuine behavioral context by describing the returned image views and text-summary fields and the spec-source precedence order, though it omits cost/latency expectations for rendering (e.g., whether gpu/flat trade-offs matter for iteration speed beyond the schema's own note).

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?

Three sentences, each carrying distinct load: what it returns, how it fits the design loop with named alternatives, and the no-write/spec-precedence facts. Purpose and return content are front-loaded; nothing is repeated from the schema verbatim.

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, but the description compensates by enumerating the returned views and summary fields. With all 6 parameters documented and the precedence order stated, the remaining gap is small: it doesn't say what happens when no spec source is supplied at all (default preset? error?).

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 detailed per-parameter descriptions (spec merging, patch JSON-Patch example, design/preset name sources, renderer modes), so the baseline is 3. The description adds value by stating the precedence rule as an ordered chain — "preset or design, spec_path, spec, patch" — which lets an agent reason about override behavior without inferring it from individual field docs.

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?

Specific verb+resource ("Build a hull and return a preview image") plus an explicit enumeration of what the output contains (5 views, size, part counts, deck heights, flotation, bench fit, warnings). It clearly distinguishes itself from inspect_view (single close-up) and preview_interior (rooms), so an agent can route without opening schemas.

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?

States the workflow explicitly ("This is the design loop: preview, compare the image with the player's brief, adjust, repeat, then save_hull") and names the alternatives with the condition that selects them (inspect_view for one large close-up from any angle, preview_interior for rooms). When-to-use, when-to-use-something-else, and the terminal action are all covered.

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