Loading ToolBench
Unified MCP server hosting Chess Royale game engine with Streamable HTTP transport, supporting multiple concurrent MCP client connections, spectator web view via SSE, and player management via plugin interface
MCP Arena presents a well-structured game server with 9 tools. Tool naming follows strong verb-first patterns (join_game, leave_game, move_unit). Most tools have solid descriptions (100-250 chars) that explain purpose and constraints. Input schemas are explicit and properly typed with JSON Schema. However, output schemas are largely undocumented, the code shows tool handlers but does not expose what fields/structures clients should expect back. Error handling is present in the code but not described in tool definitions. Tool descriptions could be more concise and less example-heavy (some descriptions exceed 250 chars with inline examples). Parameter descriptions are generally good but occasionally lack constraint details.
Get the current game status: waiting, active, or finished.
Get your visible game state including your units, visible enemies, and powerups. Tip: In games with many players, consider forming temporary alliances using the speak tool - coordinate with nearby players to take down stronger opponents!
Join the current game. You must join before you can play. Can only join once per session. Be creative with your name!
Leave the current game. Your units will be removed.
Get a detailed list of your units with their cooldown status.
Move one of your units to a target position. Movement follows chess rules: King moves 1 square any direction. Queen/Rook/Bishop slide up to 8 squares in their allowed directions. Knight moves in L-shape (2+1 squares). Pawn moves 1 square forward (or diagonally to capture). Each unit has a 5-second cooldown after moving.
Output schemas not documented. Tools return data but definitions do not specify field names, types, or structure. Clients must infer structure from code inspection.
move_units description does not clearly distinguish from move_unit beyond batch capability. Clients may struggle to choose between singular and batch variants.
get_my_state description is long (250+ chars) and includes tactical advice ('forming temporary alliances'). Trim to essential info; save strategy for external docs.
move_unit and move_units descriptions include detailed movement rules (chess piece mechanics). While helpful, these exceed recommended description length and could be linked to rules docs instead.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Move multiple units in a single action. All moves are validated first; if any move is invalid, none execute. Movement follows chess rules with max 8 squares for sliding pieces. Each unit has a 5-second cooldown after moving.
Make one of your units say something! The message appears as a speech bubble visible to spectators and nearby players. Great for taunting, coordinating, or role-playing.
Start the game. Requires at least 2 players. Can only be called when game is in "waiting" status.
Error recovery guidance missing from tool descriptions. Clients do not know what to do if join_game fails (player already joined, game full, etc.) or how to retry.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Clients cannot determine which tools are safe to retry or which modify state without manual inspection.