sts1
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STS1_KB_PATH | No | Path to the card knowledge base file. Defaults to card_kb1.json in the execution directory. | card_kb1.json |
| STS1_BRIDGE_BASE | No | Base URL to change the bridge destination. Can also be specified with the server's --base-url option. |
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 |
|---|---|
| get_game_stateB | Get the current game state (sanitized — no raw card/monster name text). Card/relic/potion/monster entries keep their |
| get_decision_packA | Get a compact decision pack — the primary LLM feed. Contains NO free-text fields: cards are identified by id and expressed as structured effects (damage/block/draw/apply_power ops from static card analysis + curation rules), plus advisor output: incoming damage, max damage, lethal targets, and a suggested action sequence. Custom mod mechanics appear as separate resources (e.g. hsr toughness is mod_damage pool=toughness, never mixed into HP lethal math). |
| send_commandA | Send a raw Communication Mod command line. Commands: PLAY <1-based hand index> [0-based enemy index], END, CHOOSE , CONFIRM, PROCEED, SKIP, CANCEL, RETURN, LEAVE, POTION <use|discard> , STATE, KEY , CLICK , WAIT , START . Prefer the dedicated tools (play_card / end_turn / choose / proceed) — they are easier to get right. PLAY hand index is 1-based, enemy index is 0-based. |
| play_cardA | Play a card by its Args:
card_id: card |
| end_turnB | End the current combat turn. |
| chooseB | Pick choice_list/screen option by 0-based index (events, map nodes, Neow, card rewards). |
| proceedB | Press the generic proceed/continue button. |
| confirmC | Confirm the current selection (grid confirm etc.). |
| cancelA | Cancel/back out of the current overlay. |
| leaveA | Leave the current room/shop (out of combat only). |
| run_turnB | Autonomously play one combat turn via the advisor. Builds the decision pack, then executes advice.plan through Communication Mod (re-resolves hand indices by card id). Returns the pack plus the execution log. In co-op the command may take a few seconds to apply. |
| flush_observationsA | Write accumulated card-play observations into card_kb1.json. play_card / run_turn record before/after state diffs; this tool aggregates them (median per effect) and persists entries with prov="observed" (conf 0.65-0.85). Entries with higher confidence (dll/static) are not overwritten — a disagreeing observation is stashed under the entry's "obs" field instead. |
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 12 tools
Most tools target clearly distinct actions (play_card, end_turn, choose, confirm, leave), but send_command duplicates nearly every dedicated tool and run_turn overlaps with play_card/end_turn, creating some selection ambiguity. The descriptions explicitly guide agents to prefer dedicated tools, which mostly resolves the confusion.
All names are snake_case and verb-first, with most following a verb_noun pattern (get_game_state, play_card, run_turn, flush_observations). A few are bare verbs (proceed, choose, confirm, cancel, leave), which is a minor deviation from a single predictable pattern.
12 tools is well within the sweet spot for this domain. The set covers combat actions, screen navigation, turn automation, state retrieval, and observation logging without obvious bloat, and each tool appears to earn its place.
Core gameplay (playing cards, ending turns, choosing options, confirming, cancelling, leaving) and autonomous turn execution are covered, with send_command as a raw fallback. However, common actions like potion usage lack a dedicated convenience tool and must go through send_command, leaving a minor gap.