Skip to main content
Glama

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". 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

TableJSON 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.7/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint=false annotation by detailing what is restored, what is genuinely consumed, how knockout works, what happens to fleeing ships, and how XP is capped. It also explains challenge locking, waves, objectives, and notification behavior, giving an unusually complete behavioral profile.

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 warranted given eight actions and complex arena rules. It is front-loaded with the core purpose and action list, then organized into focused sections. It is dense rather than padded, and every section earns its place.

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?

With no output schema, the description still tells the agent what status returns, what match state contains, what errors to expect, and how waves and win conditions work. It provides enough detail for an agent to select, parameterize, and invoke the correct arena action without external documentation.

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?

Even though schema coverage is 100%, the description adds meaningful semantics: max_side_size is explained with the solo-duel sentinel, challenge_id is tied to the challenges action, and each action parameter behavior is elaborated. The description clarifies the action enum far beyond the schema's one-line 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, unambiguous purpose: 'Consequence-free combat at an arena POI' and lists the exact actions an agent can invoke. It clearly distinguishes the arena from normal combat by emphasizing that ships and crew survive and that results only count in arena-specific stats.

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 clear context for when to use the tool: for duels and NPC arena challenges where combat is consequence-free, with no kill/loss/crime/reputation effects. It implies the contrast with real combat tools like attack/battle, though it does not explicitly name alternatives or state when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources