Slay the Spire 2 MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STS2_BRIDGE_URL | No | URL of the game's REST bridge (the mod's default address is http://127.0.0.1:15526). Pass the matching --bridge-url http://127.0.0.1:PORT to the Python server or set STS2_BRIDGE_URL when editing the port in STS2_MCP.conf. | http://127.0.0.1:15526 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| health_checkB | Check whether Slay the Spire 2 is running with the STS2_MCP bridge enabled. |
| get_game_stateA | Read the current screen, player, cards, enemies, intents, and visible options. Returns state_id, detected mode, and the complete state. Read again after each action. auto detects singleplayer/co-op. This tool works at menus as well as during a run. |
| get_action_helpA | Get action names and required/optional parameters for take_action. Omit action to see all supported gameplay actions. This describes argument syntax; the current game state supplies the actual available choices and indices. |
| take_actionA | Perform one game action and return the result plus a fresh game state. Call get_action_help for parameter names. Examples: play_card: {"card_index": 0, "target": "CULTIST_0"}; end_turn: {}; choose_map_node: {"index": 0}; menu_select: {"option": "singleplayer"}. Use current state indices and target IDs. Actions are serialized and never retried. Optionally supply expected_state_id from get_game_state to reject stale decisions. |
| wait_for_playerA | Poll through enemy turns/loading until a player screen is available. Returns ready=false with the last state on timeout. Performs no gameplay actions. A visible screen is not a guarantee that every action on that screen is legal. |
| search_wikiB | Look up discovered card/relic rules text by name in the active game profile. |
| get_profileB | Read the active profile's progress and discoveries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools are clearly distinct: state reading (get_game_state), action discovery (get_action_help), acting (take_action), waiting (wait_for_player), and reference lookups (search_wiki, get_profile) target different needs. The descriptions explicitly clarify the tricky boundary between get_action_help (syntax) and get_game_state (actual choices), though health_check and get_game_state overlap slightly since both report game status.
All tools use consistent snake_case with clear verb_noun or verb_object patterns (get_game_state, take_action, search_wiki, wait_for_player). The get_* family is predictable and no casing or verb-style mixing appears.
Seven tools is well-scoped for an agent-driven game controller, covering status, read, help, act, wait, and profile/reference lookups without redundancy. Each tool earns its place in the gameplay loop.
The core agent loop (health, state, help, action, wait) plus profile/wiki lookups is well covered. Minor gaps exist around save/load, restart, or deck-management operations, but these are workable given the bridge exposes actions through take_action.