poker-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| create_tableA | Create a new simulated no-limit hold'em table and deal the first hand. Args: seats: Number of seats (players) at the table (2-9). small_blind: Small blind size in chips. big_blind: Big blind size in chips (> small_blind). starting_stack: Starting stack for each seat. hero_seat: Seat index controlled by you (the hero). bot_profile: Opponent style: 'mixed', 'random', 'tight', or 'station'. Returns a snapshot of the table; bots are auto-advanced until it is the hero's turn or the hand ends. |
| list_tablesA | List all open tables with their current state summaries. |
| close_tableB | Close and remove a table by id. Returns whether it existed. |
| get_table_stateC | Return the full current state summary for a table. |
| get_legal_actions | Return the legal betting actions for the current actor on a table. |
| get_pending_actionsA | Return every table currently waiting on the hero to act. This is the multi-table driver: poll it to find which tables need a decision, act on one via submit_action, then poll again. |
| submit_actionA | Submit the hero's action, then auto-advance bots to the next decision. Args: table_id: Target table id. action: One of 'fold', 'check', 'call', 'bet', 'raise'. amount: Total chips to bet/raise to (required for bet/raise). After applying the action, bots play out until it is the hero's turn again or the current hand ends (a fresh hand is then dealt). |
| autoplay_botsA | Advance non-hero bots until it is the hero's turn or the hand ends. |
| adviseA | Recommend a hero action combining equity, pot odds, and preflop charts. Args: table_id: Target table id (must be the hero's turn). mc_trials: Monte Carlo rollouts used for the equity estimate. |
| calc_equityA | Estimate hero equity via Monte Carlo against random opponents. Args: hole: Hero's two hole cards, e.g. ["As", "Ah"]. board: Known community cards (0, 3, 4, or 5), e.g. ["Kd", "7c", "2h"]. num_opponents: Number of random opponents to simulate against. mc_trials: Number of random rollouts to run. |
| get_opponent_statsA | Return aggregate stats (VPIP/PFR/AF) for a player from stored hands. |
| import_hand_historyB | Import raw hand-history events into the store (minimal stub). Each event is {hand_id, player_id, street, action, amount, voluntary, table_id}. This lets you seed opponent stats from external data. |
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 11 tools
Each tool targets a distinct operation: table lifecycle (create/get/list/close), acting (submit/autoplay/pending), and analysis (advise/equity/stats). The only near-overlap, list_tables versus get_pending_actions, is clearly separated by 'all tables' versus 'tables waiting on hero.'
Most tools follow a clean verb_noun snake_case pattern such as create_table, close_table, get_table_state, and submit_action. Minor deviations like 'advise' (verb only) and 'calc_equity' (abbreviated verb) do not undermine the overall consistency.
11 tools is well-scoped for a poker simulation server covering table lifecycle, decision-making, and analysis. Every tool maps to a meaningful workflow step with no obvious redundancy or bloat.
Core table workflows are complete: create, list, get state, submit actions, advance bots, and poll pending decisions. The analysis side is solid, but import_hand_history is explicitly a stub and there is no direct hand-history query, leaving a minor gap for deeper opponent data exploration.