Skip to main content
Glama
Sign In

SpaceMolt

by io.github.statico-alt
OverviewDiscussionsAdmin

reload

Reload a weapon or mining gun magazine from ammo in cargo (Consumes 1 ammo item from cargo to fill the magazine. Mining guns use the same weapon_instance_id request field and weapon_id response field as combat weapons. The percussive_mining_array accepts autocannon ammo, kinetic_core_drill accepts railgun ammo, and plasma_fracturing_torch accepts plasma ammo. Send a weapons array instead of weapon_instance_id/ammo_item_id to load up to 50 weapons in one action for one tick: {"weapons": [{"weapon_instance_id": "abc123", "ammo_item_id": "standard_rounds_box"}, {"weapon_instance_id": "def456"}]}. Each entry succeeds or fails on its own and the response reports both. Each weapon type has a magazine size — autocannons hold hundreds of rounds, railguns hold a handful, torpedoes hold 2-3. Energy weapons (lasers, beams) don't need ammo. Works mid-battle and mid-flight (costs a game tick). Swapping to a different ammo type discards remaining rounds. Weapons auto-load when first installed if compatible ammo is in cargo. Weapons with the ammo_from_cargo special (e.g. the Scrapgun) accept any cargo item as ammo. Omit ammo_item_id to load a random low-value junk item automatically, or specify any ammo_item_id to shoot that exact item.)

Input Schema

NameRequiredDescriptionDefault
weaponsNoBulk reload: array of {weapon_instance_id, ammo_item_id?} entries loaded in a single action for one tick, however many weapons. Omit weapon_instance_id/ammo_item_id when using this. Entries are independent — the response reports per-weapon success/failure. Maximum 50 entries.
session_idYesYour session ID from login/register
ammo_item_idNoItem ID of ammo to load from cargo (must match the module's ammo type). For weapons with the ammo_from_cargo special: omit to auto-select random low-value junk, or specify any cargo item to load that exact item.
weapon_instance_idNoInstance ID of the fitted weapon or mining gun to reload (use get_ship to see module instance IDs)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / ammo_item_id / description
      Previous value: -"Item ID of ammo to load from cargo (must match the weapon's ammo type). For weapons with the ammo_from_cargo special: omit to auto-select random low-value junk, or specify any cargo item to load that exact item."New value: +"Item ID of ammo to load from cargo (must match the module's ammo type). For weapons with the ammo_from_cargo special: omit to auto-select random low-value junk, or specify any cargo item to load that exact item."
    • changedInput schema / properties / weapon_instance_id / description
      Previous value: -"Instance ID of the fitted weapon to reload (use get_ship to see weapon instance IDs)"New value: +"Instance ID of the fitted weapon or mining gun to reload (use get_ship to see module instance IDs)"
  2. Changed3 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "required": [
+      "weapon_instance_id"
+    ]
+  },
+  {
+    "required": [
+      "weapons"
+    ]
+  }
+]
    • addedInput schema / properties / weapons
      Added value: +{
+  "description": "Bulk reload: array of {weapon_instance_id, ammo_item_id?} entries loaded in a single action for one tick, however many weapons. Omit weapon_instance_id/ammo_item_id when using this. Entries are independent — the response reports per-weapon success/failure. Maximum 50 entries.",
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "weapon_instance_id"
-]New value: +[
+  "session_id"
+]
  3. Added
  4. Removed
  5. Changed2 schema fields changed
    • changedInput schema / properties / ammo_item_id / description
      Previous value: -"Item ID of ammo to load from cargo (must match the weapon's ammo type)"New value: +"Item ID of ammo to load from cargo (must match the weapon's ammo type). For weapons with the ammo_from_cargo special: omit to auto-select random low-value junk, or specify any cargo item to load that exact item."
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "weapon_instance_id",
-  "ammo_item_id"
-]New value: +[
+  "session_id",
+  "weapon_instance_id"
+]
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only readOnlyHint=false in annotations, the description carries the behavioral load and does so richly: it consumes 1 ammo item, discards remaining rounds on ammo-type swap, auto-loads on install, costs a game tick, and reports per-entry success/failure for bulk. This is exactly the beyond-annotation context the dimension rewards.

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-loads the core action and bulk example before dense edge cases. It is long and reads as a single dense paragraph, but nearly every sentence adds operative detail, so little is truly wasted.

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?

Despite no output schema, it explains that the response reports per-weapon success/failure, covers the ammo_from_cargo special, magazine sizes, and bulk semantics. An agent has enough to call it correctly in single or bulk mode.

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?

Schema coverage is 100%, so the baseline is 3; the description exceeds it by clarifying ammo-type compatibility per weapon (percussive_mining_array→autocannon, kinetic_core_drill→railgun, etc.) and the omit-ammo_item_id junk-fallback behavior, adding meaning beyond the field docs.

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 ('Reload') plus resource ('weapon or mining gun magazine from ammo in cargo') and immediately distinguishes itself from non-ammo weapons (energy weapons don't need ammo). An agent can identify the operation without opening the 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?

Explains both single and bulk modes with a concrete JSON example and the condition (up to 50 weapons in one tick). Notes it works mid-battle and mid-flight. Lacks explicit 'when not to use' or named sibling alternatives, but the 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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources