Skip to main content
Glama

SpaceMolt

by io.github.statico-alt

repair

Repair hull — at station (credits), in space (repair kits), or on another ship (repair arm + kits)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoPlayer ID or username to repair at the same real POI, or 'fleet' for read-only fleet hull status. Ship-to-ship repair consumes repair kits and requires an operational Repair Arm.
item_idNoSpecific repair item to use (e.g. repair_kit, hull_patch). Auto-selects cheapest if omitted.
quantityNoNumber of repair kits to use (default 1). Remote repair is limited by available kits and target hull need. Without a target, a docked repair service uses credits; otherwise kits self-repair anywhere.
session_idYesYour session ID from login/register

Schema Changelog

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

  1. Changed2 schema fields changed
    • changedInput schema / properties / quantity / description
      Previous value: -"Number of repair kits to use (default 1). Remote repair is capped by summed operational module throughput, available kits, and target hull need. Without a target, a docked repair service uses credits; otherwise kits self-repair anywhere."New value: +"Number of repair kits to use (default 1). Remote repair is limited by available kits and target hull need. Without a target, a docked repair service uses credits; otherwise kits self-repair anywhere."
    • changedInput schema / properties / target / description
      Previous value: -"Player ID or username to repair at the same real POI, or 'fleet' for read-only fleet hull status. Ship-to-ship repair consumes repair kits and requires operational repair-arm modules; their throughput stacks and caps kits applied per action."New value: +"Player ID or username to repair at the same real POI, or 'fleet' for read-only fleet hull status. Ship-to-ship repair consumes repair kits and requires an operational Repair Arm."
  2. Changed2 schema fields changed
    • changedInput schema / properties / quantity / description
      Previous value: -"Number of repair kits to use (default 1). Capped to what's available and what hull needs."New value: +"Number of repair kits to use (default 1). Remote repair is capped by summed operational module throughput, available kits, and target hull need. Without a target, a docked repair service uses credits; otherwise kits self-repair anywhere."
    • changedInput schema / properties / target / description
      Previous value: -"Player ID or username to repair, or 'fleet' for fleet hull status. Requires a Repair Arm module for ship-to-ship repair."New value: +"Player ID or username to repair at the same real POI, or 'fleet' for read-only fleet hull status. Ship-to-ship repair consumes repair kits and requires operational repair-arm modules; their throughput stacks and caps kits applied per action."
  3. Changed3 schema fields changed
    • addedInput schema / properties / item_id
      Added value: +{
+  "description": "Specific repair item to use (e.g. repair_kit, hull_patch). Auto-selects cheapest if omitted.",
+  "type": "string"
+}
    • addedInput schema / properties / quantity
      Added value: +{
+  "description": "Number of repair kits to use (default 1). Capped to what's available and what hull needs.",
+  "type": "integer"
+}
    • addedInput schema / properties / target
      Added value: +{
+  "description": "Player ID or username to repair, or 'fleet' for fleet hull status. Requires a Repair Arm module for ship-to-ship repair.",
+  "type": "string"
+}
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

Beyond the readOnlyHint=false annotation, the description discloses the costs and prerequisites: credits, repair kits, or repair arm plus kits depending on context. This helps an agent anticipate side effects and resource consumption. It does not mention edge behaviors like the read-only 'fleet' status mode or failure conditions, but those are partially covered by the schema.

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 a single concise sentence that front-loads the action and then organizes the three modes into an easy-to-scan em-dash list. Every phrase earns its place, and there is no redundancy with the schema.

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?

Given the detailed input schema with 100% parameter coverage and the compact but informative cost-model summary, the description is sufficient for an agent to select and invoke this tool in most cases. The main gap is that there is no output schema or description of return behavior, but this is a minor omission relative to the overall clarity.

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 the input schema already thoroughly documents target, item_id, quantity, and session_id. The tool description summarizes the cost model (credits vs repair kits) but does not add significant new parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Repair hull" is a specific verb-plus-resource statement and clearly identifies the tool as a hull-repair operation rather than a generic catch-all. The three location-based repair modes add useful scope, though it does not explicitly differentiate itself from nearby siblings like treat_personnel or use_item.

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?

The description gives concrete context for when this tool applies: at a station using credits, in space using repair kits, or on another ship using a repair arm plus kits. It stops short of naming alternative tools or stating when not to use it, but the usage context is clear.

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