Skip to main content
Glama
macery12

Stormworks MCP

by macery12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_parts

Read-onlyIdempotent

Search the installed Stormworks part catalogue by definition ID or display name to locate parts and page through results with size and mass details.

Instructions

Search the installed Stormworks part catalogue by definition id or display name. Each row gives the id, display name, size in blocks and metres, and mass, with the total and next_offset for paging. Use it to find a definition id, then get_part_definition for surfaces and sealing or get_part_orientation for mounting axes. search_land_parts groups land-build families; query_parts lists the parts inside a draft. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoRows per page, 1-200.
offsetNoRows to skip, for paging; use next_offset from the previous page.
searchNoCase-insensitive text in the definition id or display name; empty lists every part.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.0
    • addedInput schema / properties / limit / description
      Added value: +"Rows per page, 1-200."
    • addedInput schema / properties / limit / maximum
      Added value: +200
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / offset / description
      Added value: +"Rows to skip, for paging; use next_offset from the previous page."
    • addedInput schema / properties / offset / minimum
      Added value: +0
    • addedInput schema / properties / search / description
      Added value: +"Case-insensitive text in the definition id or display name; empty lists every part."
  2. Addedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

While annotations cover the safety profile (readOnlyHint), the description adds crucial operational behavior not in the schema: specifying the returned data structure ('id, display name, size, and mass') and the pagination mechanism ('total and next_offset for paging').

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 text is highly dense but exceptionally efficient. Every sentence contributes to defining the scope, functionality, or placement within the broader toolset, avoiding filler while maintaining readability.

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?

The description is complete for a highly contextual tool. It covers what data is returned, how it is paginated, how it integrates into a multi-step workflow, and exactly which other tools it should or should not be used alongside.

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?

With 100% schema coverage, the description is not strictly required to detail parameters. However, it adds semantic clarity by explaining that the search is case-insensitive and can target either the definition ID or the display name, which adds value beyond the schema definition.

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?

The description clearly states the core function—searching the installed Stormworks part catalogue—and specifies the searchable criteria (definition id or display name). Furthermore, it differentiates the tool from siblings by noting it does not group land-build families and is not used to list parts in a draft.

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?

It provides clear, actionable guidance for agent workflow: use this tool to find a definition ID, then proceed to use `get_part_definition` or `get_part_orientation`. It explicitly rules out its use cases compared to `search_land_parts` and `query_parts`.

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