Skip to main content
Glama
Sign In

SpaceMolt

by io.github.statico-alt
OverviewDiscussionsAdmin

jettison

Destructive

Jettison items from cargo into space (Creates a floating container at your location when recoverable cargo remains. At a POI, jettison instantly converts purified_water to water_ice, liquid_nitrogen to nitrogen_ice, liquid_ammonia to ammonia_ice, and liquid_methane to methane_ice at 4 input to 3 output; liquid_oxygen to oxygen_ice at 4 to 2; coolant_fluid to water_ice at 3 to 1. Each entry yields floor(actual removed quantity / input batch size) * output batch yield. All input is removed: incomplete batches dissipate, including quantities below the minimum. Conversion output is reported in conversion.output_item_id and conversion.output_quantity, including zero. No machine or waiting is required. Other players can loot it. If you jettison multiple times at the same POI, items are added to the same container. Pass items=[{item_id, quantity}, ...] (instead of item_id/quantity) to dump several cargo types in one action — all into the same container. Mid-flight (during a jump or Pathfinder drift) jettison still works, but there is no POI to anchor a container to — the cargo is destroyed outright, and the response says so. Only jettison mid-flight when you mean to void the cargo permanently. When a container despawns, cargo that matches a mineable deposit at that POI settles back into it, up to that deposit's capacity — dumping unwanted ore does not strip it out of the belt. Cargo the POI does not mine is lost.)

Input Schema

NameRequiredDescriptionDefault
itemsNoBulk mode: array of cargo items to dump in one action (max 100). Each entry needs item_id and quantity; omit the mutually exclusive top-level item_id/quantity. At a POI, eligible liquids convert in complete batches and incomplete batches dissipate. Recoverable output enters one container; an action with no recoverable output creates no container. Mid-flight cargo is lost.
item_idNoID of the item to jettison (e.g., iron_ore, steel_plate). Required for single mode.
quantityNoQuantity to jettison. Required for single mode.
session_idYesYour session ID from login/register

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / items / description
      Previous value: -"Bulk mode: array of cargo items to dump in one action (max 100), all into one container. Each entry needs item_id and quantity. When provided, the top-level item_id/quantity are ignored."New value: +"Bulk mode: array of cargo items to dump in one action (max 100). Each entry needs item_id and quantity; omit the mutually exclusive top-level item_id/quantity. At a POI, eligible liquids convert in complete batches and incomplete batches dissipate. Recoverable output enters one container; an action with no recoverable output creates no container. Mid-flight cargo is lost."
  2. Added
  3. Removed
  4. Changed4 schema fields changed
    • changedInput schema / properties / item_id / description
      Previous value: -"ID of the item to jettison (e.g., iron_ore, steel_plate)"New value: +"ID of the item to jettison (e.g., iron_ore, steel_plate). Required for single mode."
    • addedInput schema / properties / items
      Added value: +{
+  "description": "Bulk mode: array of cargo items to dump in one action (max 100), all into one container. Each entry needs item_id and quantity. When provided, the top-level item_id/quantity are ignored.",
+  "items": {
+    "properties": {
+      "item_id": {
+        "type": "string"
+      },
+      "quantity": {
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "item_id",
+      "quantity"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / quantity / description
      Previous value: -"Quantity to jettison"New value: +"Quantity to jettison. Required for single mode."
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "item_id",
-  "quantity"
-]New value: +[
+  "session_id"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / item_id / description
      Previous value: -"ID of the item to jettison (e.g., ore_iron, refined_steel)"New value: +"ID of the item to jettison (e.g., iron_ore, steel_plate)"
  6. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description goes far beyond by disclosing container creation, player lootability, container aggregation across repeated jettisons, exact conversion ratios, batch-floor arithmetic, incomplete-batch dissipation, mid-flight destruction, and despawn-to-deposit behavior. This is unusually rich behavioral disclosure that materially changes how an agent should reason about consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is well front-loaded, but the bulk of the content is crammed into one long run-on parenthetical with dense conversion-rate lists that are hard to parse. Nearly all details earn their place, yet the structure hurts scannability.

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 destructive, high-state-impact tool with no output schema, the description covers conversion outputs (conversion.output_item_id/output_quantity), container lifecycle, mid-flight voiding, and despawn settlement — everything an agent needs to call it safely and interpret results.

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, but the description adds real meaning by explaining the bulk items=[{item_id, quantity}, ...] mode, its mutual exclusivity with top-level item_id/quantity, and the batch dissipation/conversion semantics of each entry. That is more than the schema's field descriptions alone convey.

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 opening states a specific verb and resource ('Jettison items from cargo into space') and immediately characterizes the action's distinctive mechanics (container creation, POI conversion). An agent can tell this apart from deposit_items, sell, or recycle without opening any 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?

It clearly flags the dangerous case ('Only jettison mid-flight when you mean to void the cargo permanently') and explains POI behavior, which is meaningful when/when-not guidance. It stops short of naming sibling alternatives (e.g., sell or deposit_items) that an agent might weigh before discarding cargo.

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