Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

route_connections

Destructive

Lay physical pipe routes between transmission faces in a Stormworks draft, preserving structure and access while minimizing length and bends; preview or commit additions and removals.

Instructions

Lay physical pipes between transmission faces in a draft, preserving access and structure. Wires use edit_connections instead. Each route: {from:{part_id,surface_index},to:{part_id,surface_index},bounds?:[[lo],[hi]], waypoints?:[[x,y,z],...],name?:str,pipe_style?:auto|exposed|enclosed,through_blocks?:[part_id,...], color?:RRGGBB}. Bounds/waypoints use integer blocks. Routes minimize length, then bends. Default auto uses enclosed pipes for explicitly selected through_blocks; other cells use exposed pipes. through_blocks replaces only selected unconfigured/unlinked 01_block parts, retaining paint. Exposed pipes are colour-coded by contents (ISO 14726: fuel brown, cooling/fresh water blue, sea water green, exhaust black, air maroon, oil orange; shafts orange); color overrides it. Enclosed pipes keep the colour of the hull around them. All selected blocks must lie on the route (use waypoints if needed); removal restores them. Other structure and access are preserved; routes never join unrelated pipe networks. Clutch/gearbox ports may use several routes; create an explicit T-piece for a branch. Remove an added route with {op:'remove',route_id} from query_connections, then reroute. Returns the pipes added per route, warnings and the new revision; preview=true adds the image and full notes. commit=true keeps one undo step.

Input Schema

NameRequiredDescriptionDefault
commitNofalse (default) previews without changing the draft; true applies it as one undo step.
designYesStored draft name (from import_vehicle, create_land_vehicle, store_design or save_hull; see list_designs).
routesYes1-100 routes to add or {op:'remove',route_id} entries; see the description.
previewNotrue also returns the rendered preview image and the full build notes; false (default) returns a compact list of what changed, warnings and the new revision.
revisionYesThe draft's current revision from query_parts or query_connections; a stale one is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.0
    • addedInput schema / $defs / Route / properties / color
      Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[0-9A-Fa-f]{6}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Color"
+}
    • addedInput schema / properties / commit / description
      Added value: +"false (default) previews without changing the draft; true applies it as one undo step."
    • addedInput schema / properties / design / description
      Added value: +"Stored draft name (from import_vehicle, create_land_vehicle, store_design or save_hull; see list_designs)."
    • addedInput schema / properties / preview
      Added value: +{
+  "default": false,
+  "description": "true also returns the rendered preview image and the full build notes; false (default) returns a compact list of what changed, warnings and the new revision.",
+  "title": "Preview",
+  "type": "boolean"
+}
    • addedInput schema / properties / revision / description
      Added value: +"The draft's current revision from query_parts or query_connections; a stale one is rejected."
    • addedInput schema / properties / routes / description
      Added value: +"1-100 routes to add or {op:'remove',route_id} entries; see the description."
  2. Addedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds substantial context: routes minimize length then bends, through_blocks only replace unconfigured/unlinked 01_block parts while retaining paint and restore on removal, routes never join unrelated pipe networks, and commit=true keeps one undo step. That is exactly the mutation-impact detail an agent needs beyond the hints.

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 purpose and the sibling alternative, and nearly every sentence carries unique rules (colour table, block restoration, revision/return behavior). It is a dense wall of prose, though, and would read better as short grouped clauses rather than one block.

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

Completeness5/5

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

There is no output schema, yet the description covers returns (pipes added per route, warnings, new revision), the preview flag's effect on return payload, and the stale-revision rejection rule. Nothing needed to invoke a 5-parameter mutation tool correctly is missing.

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

Parameters5/5

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

Even at 100% schema coverage, the description adds meaning the schema cannot: bounds/waypoints are integer block coordinates, pipe_style auto resolves to enclosed for through_blocks and exposed elsewhere, color overrides the ISO 14726 content colour-coding, and the remove op shape is spelled out. This substantially exceeds the baseline.

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?

Opens with a specific verb and resource: "Lay physical pipes between transmission faces in a draft," plus scope constraints (preserving access and structure). The second sentence explicitly sets it apart from the sibling edit_connections, which handles wires.

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?

Explicit routing rules: wires go to edit_connections, removal goes through query_connections with {op:'remove',route_id} then reroute, and branches on clutch/gearbox ports require an explicit T-piece rather than multiple route entries. When-to-use and when-to-use-something-else are both stated.

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