SpaceMolt

unload_passenger

Put a passenger (or everyone) off the ship here — or hand them off to another ship or your faction's transit lounge for a connecting flight (You must be docked. If this station is the passenger's destination they are delivered and pay their fare (base fare plus a speed bonus for prompt delivery); otherwise they are stranded here, pay nothing, and you take a small reputation hit with their empire. Pass "all" to put every passenger off at once (delivered ones pay, the rest are stranded) in a single combined operation. CONNECTING FLIGHTS: pass target to hand passengers off mid-journey instead of debarking — target="lounge" checks them into your faction's Transit Lounge at this station (any faction member can board them onward with load_passenger; L2+ lounges also extend their fare deadline, once per journey), while target= transfers them straight onto that ship (docked here, owned by you or a faction mate, with free berths of an acceptable class). Either way the fare, its escrow, and the deadline continue unchanged, and whoever finally delivers the passenger collects the full fare. Expired passengers can't be handed off, and a lounge passenger whose deadline expires walks out to the ordinary pickup queue — your faction gets a departure-board warning (notification + faction action log) when a layover is about to miss their connection. Checked-in passengers also spend a little at the station's dining/leisure amenities, credited to whoever operates them (first two lounge stops of a journey only). Use 'list_passengers' to see who is aboard.)

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Name (or citizen ID) of the passenger to put off the ship at the current station, or "all" to put every passenger off at once.
`target`	No	Optional connecting-flight handoff: "lounge" checks the passenger(s) into your faction's Transit Lounge here, or a ship ID/name transfers them to that docked ship (yours or a faction mate's, needs free berths). Fares and deadlines continue unchanged. Omit for a normal delivery/strand.
`session_id`	Yes	Your session ID from login/register

Schema Changelog

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

AddedAug 14, 2026

TDQS

A4.9/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 burden of behavioral disclosure and does so richly. It covers outcomes (fare payment, speed bonus, reputation hit), the 'all' operation semantics, fare/escrow/deadline preservation on handoff, lounge expiry behavior, departure-board warnings, and even passenger spending in amenities—far exceeding what annotations provide and giving the agent essential knowledge of side effects.

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?

The description is long but front-loaded with the core action and immediately follows with critical conditions. It could be slightly more structured (e.g., bullet points for connecting flights), but every sentence earns its place by covering a distinct rule or edge case. The slight redundancy between the opening sentence and the 'CONNECTING FLIGHTS' section prevents a perfect score.

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?

Given the tool's complexity, minimal annotations, and no output schema, the description is remarkably complete. It covers prerequisites, multiple operational modes, financial and reputation consequences, edge cases (expired passengers, lounge deadlines), and references to related tools for the agent's workflow. The only missing element is explicit return-value documentation, but the description provides enough behavioral context to operate effectively.

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 raw parameter schema. It explains 'all' as putting every passenger off in a single combined operation, details the target parameter's possible values ('lounge' vs ship ID/name), and elaborates on consequences like 'the fare, its escrow, and the deadline continue unchanged.' This goes well beyond the schema's brief parameter descriptions.

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-plus-resource: 'Put a passenger (or everyone) off the ship here,' and immediately clarifies the two main modes: delivery/stranding or handoff. It distinguishes itself from sibling tools like load_passenger (mentioned as the reverse operation) and list_passengers (explicitly recommended to see who is aboard), so the purpose is unmistakable and differentiated.

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 clearly states the prerequisite ('You must be docked') and explains the decision criteria: if the station is the passenger's destination, they are delivered and pay; otherwise they are stranded and you take a reputation hit. It also explains when to use connecting-flight handoffs (lounge or another ship) and even notes edge cases like expired passengers not being hand-offable, providing explicit guidance on when to use the tool versus alternatives.

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?