Skip to main content
Glama

SpaceMolt

by io.github.statico-alt

commission_ship

Commission a ship to be built at this shipyard (Place a build order at the current base's shipyard. Ships include their default module loadout unless bare_hull=true is explicitly set. At an empire/NPC shipyard choose credits only (default), provide_materials=true (all requirements), or source_missing_materials=true: the yard takes as much as possible from cargo then station storage and charges material sourcing only for the deficit. Do not combine the two material flags. All modes pay labor and a yard fee. Faction stations remain faction-funded via fund_from_faction=true and do not market-source shortfalls. Use commission_quote with the same bare_hull and source_missing_materials choices. On completion the server pushes ship_commission_complete.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bare_hullNoIf true, commission only the hull without its default module loadout. Defaults to false so ships arrive fitted.
session_idYesYour session ID from login/register
ship_classYesShip class ID to commission (use ship_catalog to see options)
fund_from_factionNoAt your own faction's station: build from faction storage and treasury (requires ManageTreasury). Required there; credits-only and provide_materials are rejected.
provide_materialsNoAt an empire/NPC shipyard: if true, supply build materials from cargo/storage (cheaper); if false, pay credits for everything (default).
source_missing_materialsNoAt an empire/NPC shipyard: take available requirements from cargo then station storage and charge only to source the deficit. Do not combine with provide_materials.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / properties / bare_hull
      Added value: +{
+  "description": "If true, commission only the hull without its default module loadout. Defaults to false so ships arrive fitted.",
+  "type": "boolean"
+}
    • addedInput schema / properties / source_missing_materials
      Added value: +{
+  "description": "At an empire/NPC shipyard: take available requirements from cargo then station storage and charge only to source the deficit. Do not combine with provide_materials.",
+  "type": "boolean"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / fund_from_faction
      Added value: +{
+  "description": "At your own faction's station: build from faction storage and treasury (requires ManageTreasury). Required there; credits-only and provide_materials are rejected.",
+  "type": "boolean"
+}
    • changedInput schema / properties / provide_materials / description
      Previous value: -"If true, supply build materials from cargo/storage (cheaper). If false, pay credits for everything (default)."New value: +"At an empire/NPC shipyard: if true, supply build materials from cargo/storage (cheaper); if false, pay credits for everything (default)."
  3. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint=false annotation, the description reveals important side effects and behaviors: ships come with default loadouts unless bare_hull=true, all modes pay labor and a yard fee, faction-funded builds do not market-source shortfalls, and completion triggers a server push event ship_commission_complete. No annotation contradiction exists.

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 description is dense but every sentence earns its place. The primary action is front-loaded, the station-type conditional logic is compactly organized, and there is no filler or redundant restating of the schema.

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?

For a 6-parameter tool with no output schema, the description is remarkably complete: it covers payment modes, defaults, prohibitions, faction-specific behavior, the related quote tool, and the completion notification. An agent has enough context to invoke the tool correctly at either station type.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: the relationship between the material flags, the default behavior of bare_hull, the meaning of source_missing_materials sourcing order, and the restriction that fund_from_faction is required at faction stations. This materially improves correct parameter selection.

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 opens with a specific verb and resource: 'Commission a ship to be built at this shipyard' and clarifies it places a build order at the current base's shipyard. It distinguishes itself from the sibling commission_quote by explicitly directing the agent to use commission_quote for quotes.

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?

The description gives clear when-to-use guidance by station type: empire/NPC yards vs faction stations. It explains the material payment modes, their defaults, and explicitly warns not to combine provide_materials and source_missing_materials. It also tells the agent to use commission_quote with matching choices, giving an explicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SpaceMolt toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools are clearly distinct, targeting specific actions and resources. A few overlaps exist (e.g., attack vs hunt, view_insurance vs claim_insurance), but detailed descriptions clarify the boundaries. The scale makes selection harder, but each tool has a clear purpose.

Naming Consistency4/5

The majority use a consistent verb_noun snake_case pattern (e.g., create_buy_order, get_cargo, accept_mission). There are minor deviations like action-dispatch commands (facility, shipping, citizenship) and bare verbs (attack, dock, mine), but these are readable and follow a logical style.

Tool Count1/5

With 212 tools, the server far exceeds any reasonable scope for an MCP. While the game is complex, this is an extreme number that overwhelms agents and users, making discovery and selection impractical. The calibration considers 25+ already too many, and 212 is extreme.

Completeness5/5

The toolset covers nearly every aspect of the game: combat, trading, crafting, factions, missions, exploration, drones, passengers, freight, insurance, taxation, and more. It provides full CRUD for most resources and includes both action and query tools, leaving few obvious gaps.

Resources