Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

edit_connections

Destructive

Add or remove typed control and electrical wires in a Stormworks draft, applying connect/disconnect operations atomically with revision checks and optional preview or commit.

Instructions

Add or remove typed control and electrical wires in a draft. Uses the query_connections revision. Ops: {op:'connect',from:{part_id,port},to:{part_id,port}} or {op:'disconnect',link_id}. Signal outputs connect to inputs; electricity is bidirectional. One driver per signal input. Pipes and shafts use route_connections; whole starter, clutch, brake or light set-ups use apply_vehicle_assembly. Original XML and settings stay lossless. Returns the wires added and removed, 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).
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.
operationsYes1-100 connect/disconnect operations applied as one atomic batch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • 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 / operations / description
      Added value: +"1-100 connect/disconnect operations applied as one atomic batch."
    • 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."
  2. Addedv0.1.1

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is mostly covered. The description adds genuinely useful context — original XML and settings stay lossless, stale revisions are rejected, and commit=true collapses the batch into one undo step — but it doesn't discuss failure modes for a partially invalid batch or rate/size limits beyond the schema's maxItems.

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 purpose and sibling routing in the first two sentences, then constraints, then return/commit behavior. Slightly dense and the operation shape listing duplicates the discriminated union in the schema, costing a little efficiency.

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 no output schema, the description carries the return contract and does so ('returns the wires added and removed, warnings and the new revision; preview=true adds the image and full notes'). For a destructive 5-parameter mutation, only batch failure/rollback semantics are left implicit.

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?

Schema coverage is 100%, so commit/preview/design/revision/operations are all documented in the schema and the description largely restates the op shapes. It does add real meaning the schema cannot express — signal outputs connect to inputs, electricity is bidirectional, one driver per signal input — which is why this sits above a pure restatement.

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 ('Add or remove typed control and electrical wires in a draft') and immediately scopes it against siblings, noting that pipes/shafts go to route_connections and whole assemblies to apply_vehicle_assembly. An agent can pick this over route_connections without opening either 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?

Explicit routing: pipes and shafts use route_connections, whole starter/clutch/brake/light set-ups use apply_vehicle_assembly. It also names the prerequisite ('Uses the query_connections revision') and states the domain rules for what may connect.

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