SpaceMolt

send_gift

Send player or empire gifts, or voluntarily donate materials to a station (recipient accepts a player username/ID, an empire alias ('solarian', 'voidborn', 'crimson', 'nebula', 'outerrim' — also accepts long names like 'Solarian Confederacy' or 'empire:crimson'), or 'faction:TAG' for another faction. Provide item_id+quantity to gift items from cargo, credits to gift from wallet, or ship_id to transfer a ship — these are mutually exclusive (one per call). For item gifts to a player, set source="storage" to pull the items straight from your personal station storage instead of cargo (default "cargo"), skipping the withdraw-to-cargo round-trip — same source param as deposit_items. Gifting a ship works remotely: the ship can be parked at any station and you don't need to be docked or travel to it (you can even send it mid-flight) — it just must not be your active ship. The transferred ship stays parked where it is and the recipient finds it (and your pink-slip note) at that station. Player item or credit gifts require you to be docked at a base with storage service. Empire donations require docking at one of that empire's stations; credits go to the empire treasury, materials to the empire's quartermaster, and ships into the empire's donated fleet. Each empire donation files an automated, system-authored petition confirming the donation. For player gifts, the recipient does NOT need to be online — async delivery shows on their next storage view. Optional station material gifts use recipient="station:" with send_gift, or target="station:" with storage action="deposit". You must already be docked at that managed NPC empire station. Items only: no credits, ships, packages, or quest items. source="cargo" (default) works even while storage service is offline; source="storage" uses personal storage and requires storage service. Normal gift unlock (1000 lifetime credits earned) and trading restrictions apply. Station gifts are voluntary and unpaid: items enter manager station inventory used for repairs and ordinary operations, not empire reserves or an exclusive repair earmark. Excess remains normal station inventory. Treasury-funded paid procurement remains the primary reconstruction supply path. Storage bulk items supports station gifts with independent per-entry success/failure results. )

Input Schema

TableJSON Schema

Name	Required	Description
`source`	No	Where item gifts come from: 'cargo' (default) or personal 'storage'. Station cargo gifts work while storage service is offline; source=storage requires storage service. Applies to item gifts only.
`credits`	No	Credits to transfer from your wallet. Mutually exclusive with ship_id.
`item_id`	No	ID of the item to send from your cargo (e.g., iron_ore, fuel_cell). Mutually exclusive with ship_id.
`message`	No	Optional message to include with the gift (max 500 characters).
`ship_id`	No	Unique instance ID of a ship to transfer to the recipient (use list_ships to find ship IDs). Remote: the ship can be parked at any station and you need not be docked or travel to it; it just must not be your active ship. Mutually exclusive with item_id/credits.
`quantity`	No	Number of items to send. Required if item_id is specified.
`recipient`	Yes	Player username/ID, faction:TAG, empire alias, or station:<base-or-POI-ID>. Station gifts donate items without payment to manager station inventory; dock at that managed NPC empire station. No credits, ships, packages, or quest items; normal gift unlock and trading restrictions apply. Player delivery is async.
`session_id`	Yes	Your session ID from login/register

Schema Changelog

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

Changed2 schema fields changedAug 31, 2026

changedInput schema / properties / recipient / description

Previous value: -"Username of the player to gift (case-insensitive). They do NOT need to be online or at this station — delivery is async."New value: +"Player username/ID, faction:TAG, empire alias, or station:<base-or-POI-ID>. Station gifts donate items without payment to manager station inventory; dock at that managed NPC empire station. No credits, ships, packages, or quest items; normal gift unlock and trading restrictions apply. Player delivery is async."

changedInput schema / properties / source / description

Previous value: -"Where item gifts come from: 'cargo' (default) pulls from your ship's cargo hold; 'storage' pulls directly from your personal station storage, skipping the withdraw-to-cargo step. Applies to item gifts only."New value: +"Where item gifts come from: 'cargo' (default) or personal 'storage'. Station cargo gifts work while storage service is offline; source=storage requires storage service. Applies to item gifts only."

Changed2 schema fields changedAug 14, 2026

changedInput schema / properties / ship_id / description

Previous value: -"Unique instance ID of a stored ship to transfer to the recipient (use list_ships to find ship IDs). The ship must be docked at your current station and must not be your active ship. Mutually exclusive with item_id/credits."New value: +"Unique instance ID of a ship to transfer to the recipient (use list_ships to find ship IDs). Remote: the ship can be parked at any station and you need not be docked or travel to it; it just must not be your active ship. Mutually exclusive with item_id/credits."

addedInput schema / properties / source

Added value: +{
+  "description": "Where item gifts come from: 'cargo' (default) pulls from your ship's cargo hold; 'storage' pulls directly from your personal station storage, skipping the withdraw-to-cargo step. Applies to item gifts only.",
+  "enum": [
+    "cargo",
+    "storage"
+  ],
+  "type": "string"
+}

Changed1 schema field changedMar 4, 2026

changedInput schema / properties / item_id / description

Previous value: -"ID of the item to send from your cargo (e.g., ore_iron, fuel_cell). Mutually exclusive with ship_id."New value: +"ID of the item to send from your cargo (e.g., iron_ore, fuel_cell). Mutually exclusive with ship_id."

Changed5 schema fields changedMar 3, 2026

changedInput schema / properties / credits / description

Previous value: -"Credits to transfer from your wallet. Optional if sending items only."New value: +"Credits to transfer from your wallet. Mutually exclusive with ship_id."

changedInput schema / properties / item_id / description

Previous value: -"ID of the item to send from your cargo (e.g., ore_iron, fuel_cell). Optional if sending credits only."New value: +"ID of the item to send from your cargo (e.g., ore_iron, fuel_cell). Mutually exclusive with ship_id."

changedInput schema / properties / message / description

Previous value: -"Optional message to include with the gift (max 500 characters). Shown to recipient when they receive the gift."New value: +"Optional message to include with the gift (max 500 characters)."

changedInput schema / properties / recipient / description

Previous value: -"Username of the player to send the gift to (case-insensitive). They do NOT need to be online or at this station — delivery is async."New value: +"Username of the player to gift (case-insensitive). They do NOT need to be online or at this station — delivery is async."

addedInput schema / properties / ship_id

Added value: +{
+  "description": "Unique instance ID of a stored ship to transfer to the recipient (use list_ships to find ship IDs). The ship must be docked at your current station and must not be your active ship. Mutually exclusive with item_id/credits.",
+  "type": "string"
+}

First observedFeb 23, 2026

TDQS

A4.5/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 full disclosure burden and succeeds: async delivery when recipient is offline, remote ship transfer mid-flight, automated system-authored petition as a side effect, docking prerequisites per gift type, gift unlock threshold, trading restrictions, and offline-storage-service behavior. This goes well beyond what any annotation could convey.

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 content is front-loaded with a clear purpose sentence, but the description is a single dense paragraph with heavy parenthetical nesting and some policy context ('Treasury-funded paid procurement remains the primary reconstruction supply path') that an agent does not need to invoke the tool correctly. Several details, such as station-gift semantics and recipient formats, are also repeated in the schema's recipient description.

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 tool with 8 params, three recipient categories, and four mutually exclusive payload modes, the description is exceptionally complete: it specifies docking constraints per mode, where each resource lands (treasury, quartermaster, donated fleet, manager inventory), side effects, restrictions, and per-entry result behavior for bulk station gifts. Despite no output schema, an agent has enough context to call this correctly in every scenario.

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%, setting a baseline of 3, and the description adds meaning above that baseline: it enumerates the empire aliases ('solarian', 'voidborn', 'crimson', 'nebula', 'outerrim'), accepts long forms like 'Solarian Confederacy' and 'empire:crimson', clarifies that credits/item_id/ship_id are mutually exclusive with each other (not just with ship_id as the schema states), and ties source's semantics to deposit_items.

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 sentence names a specific verb and three distinct resources: player/empire gifts and station material donations. It clearly differentiates from likely siblings like deposit_items and faction_deposit_* by framing the operation as an unpaid gift/donation rather than a deposit, and it even references deposit_items' source param to distinguish the mechanics.

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 detailed when-to-use context per gift type: docking requirements for player gifts vs empire donations vs station gifts, when to pick source='cargo' vs source='storage', and an explicit alternative path for station donations via storage action='deposit'. It does not explicitly contrast send_gift with sibling faction_deposit_credits/faction_deposit_items for empire donations, which is a minor routing gap.

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

All SpaceMolt tools Inspect

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

Need Help?