Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pyplai-mcp Play Phantom against MO-ISMCTS and analyze each position before moving."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets a language model play board games against search algorithms, and use those same algorithms as tools to choose its own moves.
Language models reason in words; they do not search. Ask one to play Ultimate tic-tac-toe and it
will explain its moves well and choose them badly. This server gives the model the search it lacks:
the Monte Carlo tree search, minimax and information set MCTS algorithms of
pyplAI, my open-source Python library on
PyPI. The model calls analyze_position, gets every legal move
ranked with its win rate, and explains the choice in plain language.
Here is a real call (numbers vary between runs). The board is an Ultimate tic-tac-toe position
where the opponent has just won the centre board and sent you to the top-centre board, B1:
{
"algorithm": "mcts",
"metric": "win_rate",
"best_move": "B1:a3",
"moves": [
{"move": "B1:a3", "visits": 121, "value": 0.4711},
{"move": "B1:c1", "visits": 70, "value": 0.4357},
{"move": "B1:c3", "visits": 89, "value": 0.4326}
],
"iterations": 777,
"seconds": 2.001,
"note": "Monte Carlo tree search (UCT). value is the share of simulated games won after each move, counting draws as half."
}Game | Information | Opponents and analysis |
Tic-tac-toe | Perfect | MCTS, minimax, random |
Ultimate tic-tac-toe | Perfect | MCTS, minimax, random |
Phantom (4,4,4) | Imperfect: you cannot see your opponent's stones | MO-ISMCTS, SO-ISMCTS, random |
Phantom is where the design matters. A perfect-information search would read the hidden stones from the game state and cheat, so the server does not offer one. The information set searches sample where the hidden stones could be from what the player knows, and a test plays whole games checking that nothing the player receives reveals a hidden stone.
Related MCP server: Gym MCP
Tool | What it does |
| Games, move notation, opponents and analysis algorithms. |
| The full rules of a game. |
| Starts a game. Options: who moves first, the opponent, its thinking time or depth, a seed and opening moves to set up a position. |
| The board as you see it, your legal moves and the history. |
| Plays your move; the opponent replies in the same call. Illegal moves return an error listing the legal ones. |
| Ranks your legal moves with MCTS, minimax or information set MCTS. |
| Frees a game. |
The rules are also the rules://{game} resource, but get_rules exists because a model often
cannot read resources on its own: in Claude Desktop it only calls tools. A play_game prompt asks
the model to analyse, explain and play a whole game, and every tool returns structured output with
a published schema.
Requires uv. The server speaks MCP over stdio, and uvx installs and
runs it straight from this repository (it is not on PyPI yet).
Claude Code
claude mcp add pyplai -- uvx --from git+https://github.com/plss12/pyplAI-MCP pyplai-mcpClaude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"pyplai": {
"command": "uvx",
"args": ["--from", "git+https://github.com/plss12/pyplAI-MCP", "pyplai-mcp"]
}
}
}Any other client: run uvx --from git+https://github.com/plss12/pyplAI-MCP pyplai-mcp over stdio, or add
--transport streamable-http --port 8000 and connect to http://127.0.0.1:8000/mcp.
Then ask for a game, for example: "Play Phantom against the MO-ISMCTS opponent, and analyse each position before you move."
Here is a real game that Claude played and won from Claude Desktop, analysing every position before moving:
The search never touches the real game. Every analysis runs on a copy of the state, and in Phantom on samples of it.
Search runs off the event loop. Tools are synchronous functions, which the MCP SDK runs on worker threads, so a 10-second search does not block other requests. Games are locked per session.
stdout belongs to the protocol. Over stdio any stray print corrupts the JSON-RPC stream.
pyplAI 1.1 added analiza() for exactly this reason: it returns the search statistics as data
instead of printing them. Logs go to stderr, and an end-to-end test runs the server as a
subprocess over stdio.
Errors the model can fix are tool errors. An illegal move, a finished game or an unknown id comes back as a readable error, so the model can correct itself. Arguments are validated against their schema (for example, analysis time between 0.1 and 10 seconds).
Bounded memory. At most 100 games are kept, and idle games expire after an hour.
Does a small model play better with these tools? benchmarks/ lets Llama 3.2 3B,
served locally with Ollama, play 960 games through the server, with and without
analyze_position. In tic-tac-toe the tool cut its losses against MCTS from 100% to 31%, and in the
34 games where it followed every recommendation it never lost. In Ultimate tic-tac-toe it gained
nothing (no wins, against 82% for the search alone), because it ignored the analysis most often
there. The search helps a small model about as much as the model trusts it.
uv sync
uv run pytest
uv run ruff check . && uv run ruff format --check .
uv run pyrightTry the tools by hand with the MCP Inspector:
npx @modelcontextprotocol/inspector uv run pyplai-mcpPublish on PyPI, so it installs with uvx pyplai-mcp, and list it in the official MCP Registry.
More pyplAI games: draughts, Escoba and Stratego.
C. B. Browne et al. A survey of Monte Carlo tree search methods. IEEE TCIAIG, 4(1), 2012.
P. I. Cowling, E. J. Powley and D. Whitehouse. Information set Monte Carlo tree search. IEEE TCIAIG, 4(2), 2012.
D. E. Knuth and R. W. Moore. An analysis of alpha-beta pruning. Artificial Intelligence, 6(4), 1975.
MIT. Built on pyplAI, by the same author.
Rank your legal moves with a search from the current position. It only uses information you have.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | How many of the best moves to return. | |
| game_id | Yes | Id returned by new_game. | |
| seconds | No | Search time for Monte Carlo algorithms. | |
| algorithm | No | Search to run. auto uses MCTS for perfect-information games and MO-ISMCTS for Phantom. | auto |
| minimax_depth | No | Depth (moves ahead) for minimax. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| moves | Yes | Best moves first. |
| metric | Yes | |
| game_id | Yes | |
| seconds | Yes | |
| algorithm | Yes | |
| best_move | Yes | |
| iterations | Yes | Search iterations, or positions evaluated for minimax. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond that: 'It only uses information you have', signalling no hidden-information leakage or cheating. It does not mention cost/latency of the searches, but the seconds/top_k schema parameters carry that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no waste; the primary action is front-loaded and the behavioral qualifier follows. Nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and all parameters are fully documented in the schema. The description covers purpose and the fairness trait, leaving only sibling routing guidance as a gap, which is a minor completeness issue for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter (top_k, seconds, algorithm, minimax_depth, game_id) is documented in the schema, including the algorithm semantics and minimax depth. The description adds no parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (rank) and resource (your legal moves) with the scope 'from the current position', which clearly separates it from play_move and get_state. However, it never names or contrasts a sibling explicitly, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to invoke this versus get_state, get_rules, or play_move, and no stated prerequisites beyond the implied 'a game must exist'. The reader must infer that this is a pre-move analysis step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forget a game you no longer need.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | Id returned by new_game. |
| Name | Required | Description |
|---|---|---|
| game_id | Yes | |
| removed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and falls short. 'Forget' hints at removal but doesn't say whether the game and its move history are permanently destroyed, whether it's reversible, whether it requires ownership/auth, or whether an in-progress game is affected. For a state-mutating tool these are exactly the facts an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence with no filler and the intent front-loaded. It is efficient, though the brevity comes partly at the cost of substance rather than from disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but for a destructive-leaning tool with zero annotations, no prerequisites, and no statement of what gets removed or whether the action is reversible, the definition is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single game_id parameter is documented as 'Id returned by new_game.' The description adds no format, type, or provenance detail beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Forget a game you no longer need' uses a metaphorical verb that reasonably maps to ending/discarding a game session, and the resource (game) is clear. But it never states what actually happens to the stored game or its state, and it does nothing to distinguish itself from siblings like list_games or new_game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a game you no longer need' implies the triggering condition (you're finished with a session), which is minimal but real usage context. There is no explicit when-not guidance and no mention of alternatives, though for a terminal cleanup action there aren't many competitors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full rules and move notation of a game, in Markdown. The same text as the rules://{game} resource.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | Game name from list_games. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds format (Markdown) and completeness ('full' rules and move notation), which is useful but modest; it says nothing about size, paging, or failure behavior for an invalid game.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the core purpose (rules content + format) front-loaded and the resource-equivalence note as supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering the safety profile, the description needn't explain return values; format and scope are stated. It is essentially complete for a simple read tool, though it omits any note about the three allowed game values beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum is already documented ('Game name from list_games'), so the schema carries the parameter burden. The description only echoes the parameter via the '{game}' placeholder in the resource URI and adds no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full rules and move notation of a game') and specifies the output format (Markdown). It is clearly distinct from play_move/get_state/analyze_position by content, but never explicitly names a sibling or contrasts scope the way a 5 would.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent infers 'call this to read the rules.' The note that it returns 'the same text as the rules://{game} resource' is a mild routing hint (avoid fetching twice), but there is no explicit when-to-use/when-not guidance against alternatives like list_games.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the board as you see it, your legal moves and what has happened so far.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | Id returned by new_game. |
| Name | Required | Description |
|---|---|---|
| game | Yes | |
| board | Yes | The board as you see it. |
| notes | Yes | Facts about the position you are allowed to know. |
| status | Yes | |
| game_id | Yes | |
| history | Yes | Everything that has happened, as you saw it. |
| you_are | Yes | Your player number. Player 1 moves first. |
| opponent | Yes | |
| legal_moves | Yes | Moves you can play now. Empty when the game is over. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered and 'Show' is consistent with them. The description adds modest value by naming the returned content (board, legal moves, history), but omits behaviorally relevant facts such as whose perspective the state reflects or how game-over states are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every clause describes a distinct part of the returned state. Nothing could be trimmed without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, and annotations cover the read-only profile, so the description is nearly sufficient. It could still note when the snapshot should be refreshed relative to play_move or end_game, but the gap is minor for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single game_id parameter is fully documented in the schema as 'Id returned by new_game.' The description contributes no additional meaning about the parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb ('Show') and enumerates the resource content: the board, legal moves, and move history. It tells an agent this is a state-snapshot read, but it never distinguishes itself from siblings like analyze_position or get_rules, which an agent could plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., 'call after play_move to refresh the board'). Usage is only inferable from the tool name and the returned content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the games you can play, their move format and the algorithms available for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, self-contained read. The description adds that the response enumerates move formats and per-game algorithms, which is genuine context about what the listing contains. It stops there, offering no pagination, ordering, or filtering context, so a 3 is appropriate with annotations carrying the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clause-rich sentence with no filler, and the core purpose ('List the games') is front-loaded before the details of what the listing returns. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not spell out return values, and with zero parameters there is no input surface to document. The description covers purpose and payload adequately; the only missing piece is routing guidance between siblings, which is minor for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate and no schema-coverage gap to compensate for. Baseline 4 applies for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('List') with a specific resource ('the games you can play') and further states the payload: move format and available algorithms. This clearly separates it from action-oriented siblings like play_move or new_game. It stops short of explicitly naming which sibling to use instead, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus alternatives such as get_rules or new_game, and no prerequisites or exclusions are given. The discovery role (call before starting a game) is only inferable from the word 'List'. This matches the mid-tier calibration where absent when-to-use guidance scores 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a game against a pyplAI algorithm. If the opponent moves first, it has already moved in the returned state.
| Name | Required | Description | Default |
|---|---|---|---|
| game | Yes | Game to play. See list_games. | |
| seed | No | Seed for the opponent's search, to make its play reproducible. | |
| opening | No | Moves to play from the start, for both players, before the game is handed over. Use it to set up a position. | |
| play_as | No | Your player number. Player 1 moves first. | |
| opponent | No | Opponent algorithm. auto picks the strongest fair one for the game. | auto |
| minimax_depth | No | Search depth (moves ahead) for the minimax opponent. | |
| opponent_seconds | No | Thinking time per move for Monte Carlo opponents. |
| Name | Required | Description |
|---|---|---|
| game | Yes | |
| board | Yes | The board as you see it. |
| notes | Yes | Facts about the position you are allowed to know. |
| status | Yes | |
| game_id | Yes | |
| history | Yes | Everything that has happened, as you saw it. |
| you_are | Yes | Your player number. Player 1 moves first. |
| opponent | Yes | |
| legal_moves | Yes | Moves you can play now. Empty when the game is over. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose one genuinely useful non-obvious behavior: if the opponent moves first, its move is already reflected in the returned state. However, it says nothing about session identity/persistence, what the returned state contains, or the cost of calling it repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, and the most decision-relevant constraint (the opponent may already have moved) is placed where it will be read. Nothing could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the schema is fully self-documented. What is missing for a zero-annotation game-creation tool is lifecycle context: how the new game relates to play_move/get_state and what happens to an existing game.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — every one of the 7 parameters carries its own description, including seed, opening, play_as and opponent trade-offs. The description adds nothing on top, which is the correct baseline when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Start a game against a pyplAI algorithm'), and the sibling set (play_move, get_state, end_game) makes the lifecycle stage unambiguous. It never names a sibling explicitly, so it stops short of the differentiation a 5 requires, but an agent can tell what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement that this must precede play_move, and no note about whether calling it again discards the current game. The only routing hint ('See list_games') lives in the schema's game parameter, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play a move. The opponent replies straight away, so the returned state is your next turn (or the end of the game).
| Name | Required | Description | Default |
|---|---|---|---|
| move | Yes | One of the legal moves, as written in legal_moves. | |
| game_id | Yes | Id returned by new_game. |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| outcome | Yes | What happened after your move, including your opponent's reply. |
| your_move | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses that the opponent replies immediately and the returned state is the next turn or game end, but it omits other behavioral details like error handling for illegal moves or required preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with zero waste. The core action is front-loaded, and the behavioral note is equally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool, full schema coverage, and an existing output schema, the description is largely complete. It supplements the return behavior but does not cover edge cases like invalid moves, which are arguably handled elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('move' as a legal move from legal_moves and 'game_id' from new_game). The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Play) and resource (a move), making it clear what the tool does. It does not explicitly differentiate itself from siblings like analyze_position or get_state, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as analyze_position or get_state. The description only states what the tool does, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_positionend_gameget_rulesget_statelist_gamesnew_gameplay_moveScored across 7 tools
Each tool targets a distinct action in the game lifecycle (list, rules, new, play, state, analyze, end) with little true overlap. The only mild ambiguity is between get_state (shows legal moves) and analyze_position (ranks legal moves), but descriptions make the distinction clear.
All seven tools follow a consistent snake_case verb_noun pattern (list_games, get_rules, play_move, new_game, get_state, analyze_position, end_game). No mixed conventions or vague verb styles.
Seven well-scoped tools fit the game-playing domain cleanly, each earning its place with a distinct role. Neither thin nor bloated.
The surface covers a full game lifecycle: discover games, read rules, start, play, inspect state, analyze, and clean up. Minor gaps like undo/resign or move history rollback exist but are workable around.
Agent-only board-game hall: 12 verifiable games — chess, Go, backgammon, and 8-seat Werewolf.
Games for AI agents. Each game runs inside a single context window.
The game engine built for AI. Any agent makes a multiplayer game and publishes it.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.