Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

import_vehicle

Copies an existing single-body Stormworks vehicle into a new editable draft without changing the source, enabling part edits and saving under a different name.

Instructions

Copy an existing single-body vehicle (data version 3) into a new editable draft; the source file is never changed. Use it to modify a vehicle the player already has, then query_parts/edit_parts, preview_vehicle, and save_vehicle under a different name. Configured and wired parts are protected. Fails when the draft name exists, the vehicle has several bodies or it uses an older data version. Returns the part count.

Input Schema

NameRequiredDescriptionDefault
nameYesVehicle file name without .xml in the player's vehicles folder (see list_game_vehicles); with source=workshop, the numeric Steam Workshop item ID.
designYesName for the new draft; must not exist yet (see list_designs).
sourceNo"vehicles" (default) reads the player's vehicles folder; "workshop" reads an installed Workshop item by numeric ID.vehicles

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.0
    • addedInput schema / properties / design / description
      Added value: +"Name for the new draft; must not exist yet (see list_designs)."
    • addedInput schema / properties / name / description
      Added value: +"Vehicle file name without .xml in the player's vehicles folder (see list_game_vehicles); with source=workshop, the numeric Steam Workshop item ID."
    • addedInput schema / properties / source / description
      Added value: +"\"vehicles\" (default) reads the player's vehicles folder; \"workshop\" reads an installed Workshop item by numeric ID."
  2. Addedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only flag non-read-only, non-destructive, non-idempotent. The description goes well beyond: source is never mutated, configured/wired parts are protected, three specific failure modes (draft name exists, multi-body, older data version), and that it returns the part count. That is rich behavioral context an agent could not infer from annotations.

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?

The core action and the source-unchanged guarantee are front-loaded, followed by workflow, constraints, and return value. Dense but every clause carries information; nothing repeats the schema or annotations.

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?

Output schema exists and the description still states the return ('part count'). Combined with the failure conditions and workflow, an agent has everything needed to call this correctly and interpret the result.

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 description coverage is 100%, so name, design, and source are already fully documented, including the Workshop ID alternative and the list_designs cross-reference. The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

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 ('Copy an existing single-body vehicle (data version 3) into a new editable draft') plus the key invariant that the source file is never changed. This cleanly separates it from sibling tools like create_land_vehicle or save_vehicle.

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?

Explicitly names the use case ('modify a vehicle the player already has') and lays out the follow-on workflow (query_parts/edit_parts, preview_vehicle, save_vehicle under a different name). It also enumerates failure conditions, which tells the agent when not to bother calling it.

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