Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

analyze_hull

Read-onlyIdempotent

Measure actual hull material, floor gaps, and partial-face seams at selected z stations to check depth and floor height before saving or to study an existing hull.

Instructions

Measure actual hull material, floor gaps and partial-face seams at z stations: keel, walking floor and rim separately, since a part's footprint is not its solid material. Use it before saving to check depth and floor height, or to study a saved hull. Procedural reports use the fixed build frame and include floor height above keel and drop from the rim; saved vehicles use their own body-local frame, so pick body_id when the largest body is not the hull. Read-only geometry, not a seal test (use check_seal).

Input Schema

NameRequiredDescriptionDefault
xNox column for the section, in integer blocks.
nameNoSaved vehicle to measure (one body at a time); omit to build spec/preset/design.
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.
sourceNo"vehicles" (default) or "backups" (data/backups/vehicles, e.g. name="autosave9").vehicles
body_idNounique_id of one body of a multi-body vehicle; default is the largest body. Saved vehicles only.
stationsNoz stations to report, in integer blocks; default picks representative ones.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 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 / name / description
      Added value: +"Saved vehicle to measure (one body at a time); omit to build spec/preset/design."
    • 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 / source / description
      Added value: +"\"vehicles\" (default) or \"backups\" (data/backups/vehicles, e.g. name=\"autosave9\")."
    • 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 / stations / description
      Added value: +"z stations to report, in integer blocks; default picks representative ones."
    • addedInput schema / properties / x / description
      Added value: +"x column for the section, in integer blocks."
  2. Addedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent, so the description correctly spends its words on non-obvious behavior: procedural reports use the fixed build frame while saved vehicles use body-local frames, and the largest body is the default rather than necessarily the hull. It does not discuss report shape or station defaults in prose, but an output schema exists.

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 measurement purpose before any caveats, and every sentence carries a distinct constraint (footprint vs material, source frames, body_id, seal-test exclusion). The middle sentence is dense and stacks two frame cases, costing a little readability.

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?

Covers the complexity of a 9-parameter, any-of-source analysis tool: which source to pick, which frame applies, and which sibling handles sealing. With an output schema present it needn't describe results, so the remaining gap is minor.

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 baseline by explaining the semantic consequence of body_id (pick it when the largest body is not the hull) and the frame difference between the name/spec/preset sources, which the schema 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 (measure) and precise resource (hull material, floor gaps, partial-face seams at z stations, split into keel/walking floor/rim), and explicitly frames it against the misconception that footprint equals solid material. Distinguishable from siblings like preview_hull and check_seal without opening any 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?

Gives explicit when-to-use (before saving to check depth and floor height, or to study a saved hull) and names the alternative for a different job: 'not a seal test (use check_seal)'. Also flags the body_id decision case for multi-body vehicles.

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