Skip to main content
Glama
Sign In

SpaceMolt

by io.github.statico-alt
OverviewDiscussionsAdmin

arena

Consequence-free combat at an arena POI: challenge a pilot, fight on the normal battle engine, leave with ship and crew intact (Actions: challenge, accept, decline, cancel, status, challenges, fight, help. Use action="help" for full documentation.

  • challenge: Challenge an undocked pilot at this arena POI (e.g. the Blood Arena in Krynn). Include "player_id". A pilot you cannot see (elsewhere or cloaked) returns player_not_found. Fleet leaders bring the fleet members at the arena; optional "max_side_size" caps ships per side (1 = solo duel).

  • accept/decline: Answer a pending challenge. cancel: Withdraw one you issued. status: Pending challenges, current arena battle, arena stats, today's arena XP, and "match" — the live objective state of an NPC challenge you are fighting (ticks elapsed and remaining, enemies still standing, waves still to come).

  • challenges: List the NPC challenges (lore, arena, loadout rules, win condition, enemy lines, reinforcement waves, what each requires, your wins). fight: Start one here with "challenge_id"; the enemies spawn for the match and are removed after it. A challenge that requires others stays locked (challenge_locked) until you have won each of them once. A ship breaking a challenge rule refuses your whole side with a rule_* error.

  • Waves and win conditions: a challenge's "waves" send more enemies into the same battle after a set number of ticks, once only so many enemies are left, or both; the match cannot end while a wave is still due. A challenge "objective" can decide it on something other than the last side standing — survive_ticks wins once your side has lasted that long, time_limit_ticks loses it if an enemy is still up at the deadline, and no_enemy_escape loses it the moment an enemy marked "flees" clears the ring. Each arrival and verdict pushes an arena_objective notification. Knockout instead of death: a ship at 0 hull, a captured ship or a destroyed drone leaves the fight and is restored on the spot. Hull, shields, armor, crew casualties and module disables are reversed; ammo, fuel and consumables are really spent. Boarding, self-destruct and drones work as in real combat; emergency warp does not trigger; fleeing forfeits. Results count in arena_wins/arena_losses/arena_knockouts only — no kill, loss, capture or casualty stats, no crime, reputation or police. Combat XP is earned normally up to a daily per-skill cap.)

Input Schema

NameRequiredDescriptionDefault
actionYesArena action to perform
player_idNoPlayer name or ID to challenge (for 'challenge')
session_idYesYour session ID from login/register
challenge_idNoFor 'fight': the NPC challenge to start, from 'challenges'.
max_side_sizeNoFor 'challenge': maximum ships per side. 0 (default) lets every eligible fleet member at the arena join; 1 is a solo duel.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed2 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "challenge",
-  "accept",
-  "decline",
-  "cancel",
-  "status",
-  "help"
-]New value: +[
+  "challenge",
+  "accept",
+  "decline",
+  "cancel",
+  "status",
+  "challenges",
+  "fight",
+  "help"
+]
    • addedInput schema / properties / challenge_id
      Added value: +{
+  "description": "For 'fight': the NPC challenge to start, from 'challenges'.",
+  "type": "string"
+}
  4. Added

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 burden and does so richly: knockout instead of death, what is restored (hull, shields, armor, crew, modules) versus genuinely spent (ammo, fuel, consumables), emergency warp not triggering, fleeing forfeiting, and the fact that results count only in arena_wins/losses/knockouts with no crime, reputation, or police effects. Error behaviors (player_not_found, challenge_locked, rule_*) are also disclosed.

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?

Purpose is front-loaded and the per-action breakdown is well organized, with no obviously redundant sentences for an eight-action tool. It is nonetheless dense and long, and the waves/objective and knockout passages are run-on enough that some trimming is possible.

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 complex multi-action tool with no output schema and only a single annotation, the description covers outcomes, notification behavior (arena_objective), stat accounting, XP caps, and the main error codes. An agent has enough to select the right action and anticipate the results without further documentation.

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 semantics: player_id must reference a visible, undocked pilot (else player_not_found), max_side_size=1 means a solo duel and 0 lets every eligible fleet member join, and challenge_id comes from the 'challenges' action. This meaningfully extends beyond the schema text.

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 the specific resource and its defining scope: 'Consequence-free combat at an arena POI: challenge a pilot, fight on the normal battle engine, leave with ship and crew intact.' The action enumeration and the consequence-free framing distinguish it from real-combat siblings like battle, attack, and hunt 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?

Each action is given clear triggering context (challenge an undocked pilot, accept/decline a pending challenge, status for live match state, challenges to list NPC challenges, fight to start one), which is strong per-action routing. It does not explicitly name an alternative tool or state when not to use arena instead of real combat, so it falls short of the 5 bar for explicit exclusions.

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