Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

edit_parts

Destructive

Apply atomic batches of part operations to a Stormworks draft—add, fill, remove, move, rotate, paint, copy, mirror, or configure—then preview or commit changes.

Instructions

Add, remove, move, rotate, paint or copy parts in a draft as one atomic batch. Pass the revision from query_parts. Ops: add(part/parts), fill(bounds,color), remove/replace/move/rotate/paint/copy/mirror/repeat. Selection ops need select={ids/bounds/name/definition}. move/copy/repeat use delta in blocks; repeat count is additional copies; rotate uses a local-to-world matrix or r string and pivot; mirror uses axis and plane. replace needs part; paint needs color. Added parts use definition, position in blocks, rotation, optional mirror (1=x, 2=y, 4=z), color, name and scalar settings. Placement rotation accepts an effective mirrored matrix; use that or proper rotation plus mirror. Prebuilt engines default to max_force_scale=1 (100%). Returns what changed (added parts with their new ids, such as edit:0:0, next to the names you gave), warnings and the new revision; preview=true adds the image and full notes. commit=true keeps one undo step (undo_edits). Wires and pipes use edit_connections and route_connections.

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 operations applied in order as one atomic batch; see the description.

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 operations applied in order as one atomic batch; see the description."
    • 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.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds real context on top: atomic batch ordering, stale revisions rejected, preview=true returns image plus full notes, commit=true yields exactly one undo step (undo_edits), and what the response contains including newly assigned ids like edit:0:0.

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 core action and one atomic-batch framing, and nearly every clause carries information an agent needs for a 10-variant operation union. The middle section is a dense run-on paragraph, so some op semantics are harder to scan than they could be, but little is filler.

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?

For a complex, highly-branching mutation tool with no output schema, the description covers the operation list, required inputs per op, return contents, and preview/commit behavior. Minor gaps remain: the units/format of bounds, whether an empty selection means 'all parts', and how multiple ops interact within a batch beyond ordering.

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?

Schema coverage is 100%, so 3 would be the baseline, but the description goes well beyond the schema, which has almost no per-property prose: it explains delta in blocks, that repeat's count is *additional* copies, that rotate takes a local-to-world matrix or 'r' string plus pivot, mirror's axis/plane, mirror bitmask values (1=x, 2=y, 4=z), selection shapes for selection ops, and the max_force_scale=1 default for prebuilt engines.

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 set and resource plus scope: 'Add, remove, move, rotate, paint or copy parts in a draft as one atomic batch.' It also explicitly routes non-part edits away ('Wires and pipes use edit_connections and route_connections'), so an agent can distinguish it from the connection-editing siblings 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?

States the prerequisite 'Pass the revision from query_parts' and names the alternative tools for wires/pipes, plus commit/undo semantics. It does not spell out when a repair/validation workflow should be preferred over direct part editing, but the operating context is clear.

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