Loading ToolBench
This mod allows AI agents to play the game via Model Context Protocol (MCP)
MCP The Spire is a game-control MCP server with 10 tools spanning read-only queries (5) and state-mutating actions (5). Strengths: all tools have descriptions (10-200+ chars, mostly good); input schemas are present and mostly typed; naming follows verb_noun convention consistently. Weaknesses: parameter descriptions are sparse or missing for many tools; output schemas are undocumented; error handling guidance is absent; no tool annotations (readOnlyHint/destructiveHint); several parameters lack descriptions or type info. The server shows competent baseline quality but falls short of production-grade polish in areas critical for agent reasoning (error recovery, output contracts, parameter constraints). The descriptions are written for humans playing a game, not LLMs planning multi-step actions.
Select an option from the current screen's choices list by index. Use get_screen_state to see available choices first. Prefer execute_actions for multiple sequential choices.
End turn. Prefer execute_actions to combine with card plays.
Execute multiple actions in sequence. INDICES ARE STABLE - use positions at call time, don't recalculate! Examples: (1) Play cards by name: [{action:'play_card',card_name:'Bash',target_index:1},{action:'play_card',card_name:'Strike',target_index:1}]. (2) Play by index (stable): Hand [1:Strike,2:Defend,3:Bash] -> play 1 and 3: [{action:'play_card',card_index:1,target_index:1},{action:'play_card',card_index:3,target_index:1}]. (3) Collect rewards: [{action:'choose',choice_index:1},{action:'choose',choice_index:2},{action:'proceed'}]. (4) Survivor discard: [{action:'play_card',card_name:'Survivor'},{action:'select_cards',drop:['Strike']}]. (5) Gambler's Chip keep best: [{action:'select_cards',keep:['Bash','Inflame']}].
Get available tools for current screen with descriptions. Returns screen_type and available_tools list.
Get detailed card info (description, stats, upgraded version). Use when you need to know what a card does.
Output schemas completely undocumented. No tool returns structured type definitions. LLMs cannot plan downstream tool calls or extract fields without guessing. E.g. get_game_state returns what? Fields? Types? Pagination? Unknown.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in metadata but not exposed to LLM via schema annotations. Agent cannot distinguish safe from dangerous operations without reading descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | 2024-11-05+ | v1 |
Get game state. Sections: player, deck, relics, potions, combat, screen (default=all). 'map' excluded by default (large/static) - request explicitly when needed.
Get detailed relic info (description, tier, flavor text). Use when you need to know what a relic does.
RECOMMENDED: Get current screen state (screen_type, choices, hand, monsters, buttons). Use this instead of get_game_state for routine checks.
Play a card from hand. Specify card by ONE of: card_index, card_name, or card_id. Add target_index for attack cards. Examples: {card_name:'Bash',target_index:1}, {card_index:3,target_index:1}, {card_name:'Defend'}. Prefer execute_actions for playing multiple cards.
Use a potion from your potion slots. Targeted potions (e.g., Fire Potion) require target_index.
Parameter descriptions missing or minimal for critical action tools. execute_actions param 'actions' describes action types (play_card, choose, etc.) with examples but does NOT document what each action object must contain, field types, or mutually exclusive fields. Agent must infer structure from examples.
No error handling guidance. Tools lack documentation of failure modes, recovery paths, or actionable error messages. E.g. if play_card fails because card is not in hand, does the tool return a structured error? Can the agent retry? Should it fetch hand state first?
Tools operating on indices (play_card card_index, choose choice_index, use_potion potion_slot) lack clear documentation of index scheme (0-indexed vs 1-indexed). Description says '1-indexed' but no guidance on what happens if index is out of bounds or invalid.
Mutually exclusive parameters not clearly declared. play_card accepts card_index OR card_name OR card_id with description 'mutually exclusive' but no guidance on priority, error if multiple provided, or recommendations for which to use.
get_screen_state and get_game_state have overlapping purpose. Description recommends get_screen_state 'instead of get_game_state' but does not clarify when each is appropriate or what fields differ. Agent must discover by trial.
Confirmation/dry-run pattern missing. Destructive-but-reversible actions (choose, play_card, execute_actions) lack a way to preview or confirm before applying. Agent mistakes risk advancing the game to unwanted state.