What can you do with this server?

This Chess MCP Server enables AI agents and LLMs to play chess interactively, providing game management, move execution, and real-time board visualization through the Model Context Protocol. * Create and manage chess games: Initialize games against computer AI (difficulty levels 1-10, from "Random Blunderer" to "Minimax Master") or other agents, specifying player color and UI preferences with automatic Game ID generation. * Join existing games: Connect to ongoing games using Game IDs to participate as a player. * Execute moves and turn-based gameplay: Submit moves in UCI format (e.g., e2e4), claim checkmate/win conditions, and use long-polling to wait for opponent moves (up to 30 seconds) with automatic timeout handling. * Real-time board visualization: View boards in Markdown format for text-based analysis or interactive HTML with drag-and-drop piece movement (when showUi is enabled in supported MCP clients). * Monitor via web dashboard: Access http://localhost:8080 to view all active games and spectator views. * Flexible game modes: Support Human vs Computer, Agent vs Computer, Agent vs Agent, and Human vs Agent gameplay. * Tools API: createGame (initialize sessions), joinGame (connect to existing games), finishTurn (submit moves), and waitForNextTurn (receive opponent moves). * Spatial understanding: Provide chess board context enabling LLMs to understand positions, legal moves, and strategic relationships between pieces.

How do I use Chess MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Chess MCP Server Start a new chess game against you at level 5. You go first." 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.

Chess MCP Server

by fritzprix

Overview Schema Related Servers Score Discussions

Python

Local

♟️ Chess MCP Server

PyPI version

Give your AI Agent eyes to see the board and hands to make the move.

This is not just a chess API. It's a Model Context Protocol (MCP) server designed to let Large Language Models (LLMs) like Claude play chess agentically.

Capable of visualizing the board in real-time HTML, understanding spatial relationships via Markdown, and challenging you with a hybrid difficulty engine (Levels 1-10)—or simply facilitating a game between you and your Agent.

🚀 Features

MCP-UI Support: Interactive HTML board embedded directly in the chat (where supported).
Hybrid AI Engine: Adjustable difficulty from "Random Blunderer" (Level 1) to "Minimax Master" (Level 10).
Agent vs. Agent: Let two AI personalities battle it out.
Web Dashboard: Automatically launches a local sidecar dashboard (http://localhost:8080) to monitor all active games.

Related MCP server: Chess MCP

🧰 Tools API

Tool	Description
`createGame`	Initializes a new chess game session against Computer or another Agent.
`joinGame`	Joins an existing game using its Game ID.
`finishTurn`	Submits a move in UCI format and optionally claims a win.
`waitForNextTurn`	Long-polling tool that waits for the opponent's move.

For full specification, see docs/spec/tools.md.

📦 Installation

Prerequisites

Python 3.10+
An MCP Client (e.g., Claude Desktop, Cursor)

1. Installation

You can install directly from PyPI:

pip install chess-mcp-server

2. Configure MCP Client

Add the following to your MCP Client configuration file (e.g., ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "chess": {
      "command": "uvx",
      "args": ["chess-mcp-server"]
    }
  }
}

Alternatively, using pip installation:

{
  "mcpServers": {
    "chess": {
      "command": "python",
      "args": ["-m", "src.mcp_server"]
    }
  }
}

🛠️ Development

If you want to modify the code:

Clone & Setup

git clone https://github.com/fritzprix/chess-mcp-server.git
cd chess-mcp-server

python -m venv .venv
source .venv/bin/activate
pip install -e .

🎮 How to Play

Once the server is connected, you can ask your Agent to start a game.

Start a Game

Ask: "Start a new chess game against the computer at level 5."

The Agent calls createGame.
Pro Tip: You can also ask "I want to play against YOU. Create a game where you are White."

Join an Existing Game

If you have a Game ID (e.g., from another agent), you can ask: "Join game [Game_ID]".

The Agent calls joinGame.

The Game Loop

Your Move:
- Interact with the HTML Board if shown. Drag your piece and click Confirm.
- Or tell the Agent: "Move pawn to e4."
Agent's Turn:
- The Agent calls waitForNextTurn.
- It sees the board (Markdown or HTML) and thinks about the move.
- It calls finishTurn to submit its move.
Checkmate:
- If you deliver the final blow, you can check the "Claim Checkmate" box on the UI or tell the Agent "Checkmate!".

Dashboard

When the server starts, it will try to open http://localhost:8080. You can view the list of all active games and spectator views there.

Available Tools

4 tools

createGameA

Initializes a new chess game session. Returns the Game ID and instructions.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Opponent type. 'computer': Play against AI (No UI). 'agent': Play against another Agent (No UI). 'human': Play against Human (Returns UI).
`color`	No	Your color. 'white' moves first. If 'black', the opponent will move first.	white
`difficulty`	No	AI Difficulty Level (1-10), if type is 'computer'.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of disclosing side effects and behavior. It does state the core side effect (initializes a session) and that it returns a Game ID and instructions, but it omits any context about permissions, session lifecycle, whether repeated calls create multiple sessions, or type-dependent outcomes. For a state-changing tool, this is thin disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short, front-loaded sentences: the first states the core action, the second the return value. There is no filler, and every sentence adds information. It is concise without sacrificing the essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description's 'Returns the Game ID and instructions' is the only return guidance. It does not specify the shape of the return value, how the Game ID should be used with sibling tools, or the fact that the return differs by opponent type (e.g., human returns UI). It is minimally adequate but leaves gaps for a stateful, multi-tool workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for parameters is 100%, so the baseline is 3 even though the description adds no parameter-specific meaning. The description does not mention type, color, or difficulty, leaving all parameter semantics to the input schema, which is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Initializes a new chess game session,' which names a specific action (initializes) and resource (chess game session), and adds that it returns the Game ID and instructions. This clearly distinguishes it from sibling tools like waitForNextTurn or joinGame by focusing on session creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The verb 'initializes' implies that this tool is for starting a new game rather than joining (joinGame) or progressing an existing one, but no explicit when-to-use or when-not-to-use guidance is provided. The description does not name alternatives or conditions, leaving the agent to infer usage from the tool name and sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

finishTurnA

Submits a move and returns the updated state or a precise failure.

ParametersJSON Schema

Name	Required	Description
`move`	Yes	The move in UCI format (e.g., 'e2e4').
`game_id`	Yes	The ID of the active game.
`claim_win`	No	Set to true if you are claiming Checkmate or Win with this move.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of explaining behavior. It does disclose the return behavior ('returns the updated state or a precise failure'), which is useful, but it does not describe side effects, turn ownership requirements, or the meaning of the claim_win option. This is a reasonable partial disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence front-loads the action and then gives the expected result. Every phrase contributes, with no repetition of the title or schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple move-submission tool with fully documented parameters, the description plus schema is nearly complete. It would benefit from a brief note on when it is valid to call (e.g., only during the player's turn), but the lack of an output schema is mitigated by stating the return behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters already have meaningful schema descriptions (e.g., UCI format, claim_win semantics). The tool description adds little about the parameters, but it does not need to compensate for missing schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Submits a move') and its result, clearly distinguishing it from sibling tools like waitForNextTurn, createGame, and joinGame. No ambiguity about what resource/operation this covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context of submitting a move is implicit given the name and UCI-formatted move parameter, but the description never explicitly says when to call it or when to prefer a sibling such as waitForNextTurn. No alternatives or exclusions are named, so the agent must infer usage from the verb and parameter names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

joinGameA

Joins an existing chess game. Returns the current board state and turn information.

ParametersJSON Schema

Name	Required	Description	Default
`game_id`	Yes	The ID of the game to join.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions the return value (board state and turn information) but does not disclose potential side effects (e.g., whether joining modifies the game state or requires authentication). Since no annotations are provided, the description carries the full burden, and this omission is significant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The first sentence states the action, the second describes the return. Efficiently front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is decent but lacks context on what happens if the game is full or requires authorization. Given no annotations, more completeness would be expected to guide correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides a description for the single parameter (game_id) and covers 100% of parameters. The description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Joins') and the resource ('an existing chess game'). The sibling tools (createGame, finishTurn, waitForNextTurn) have distinct purposes, making joinGame's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for joining a game after it has been created, but it does not explicitly say when to use it versus alternatives like createGame. No prerequisites or conditions for use are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

waitForNextTurnA

Blocks until it is the Agent's turn (or User's turn via Agent proxy). Waits up to 30 seconds for the opponent to move.

ParametersJSON Schema

Name	Required	Description	Default
`game_id`	Yes	The ID of the active game.

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral disclosure, and it does reveal the blocking nature and timeout. However, it doesn't state what happens when the 30-second wait expires, whether it can be polled repeatedly, or what information it returns. The 'User's turn via Agent proxy' phrasing adds ambiguity rather than clarity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loads the core blocking behavior, and includes the critical timeout detail. Every phrase contributes meaning, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the main purpose and timeout. However, the lack of an output schema and the absence of any statement about timeout behavior or return value leaves a notable gap. The ambiguity around 'User's turn via Agent proxy' also reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, game_id, is fully described in the schema with 100% coverage. The description does not add any extra semantic detail about how game_id is used beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it blocks until the Agent's turn, with a 30-second wait for the opponent. The verb 'blocks' and the resource 'turn' make the operation understandable, and it is distinct from siblings like finishTurn or joinGame, though it doesn't explicitly reference them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this should be used when waiting for an opponent after your turn, and mentions the 30-second timeout. However, it gives no explicit guidance about when to use it versus alternatives, nor what to do if the timeout elapses. Usage context is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev0.1.17Aug 29, 2026

ChangedcreateGame1 field changed

changedInput schema / properties / color / description

Previous value: -"Your color. 'white' moves first. If 'black', computer will move first."New value: +"Your color. 'white' moves first. If 'black', the opponent will move first."

4 tool updatesv0.1.12May 6, 2026

ChangedcreateGame7 fields changed

removedInput schema / $defs

Removed value: -{
-  "GameConfig": {
-    "properties": {
-      "color": {
-        "default": "white",
-        "description": "Your color. 'white' moves first. If 'black', computer will move first.",
-        "enum": [
-          "white",
-          "black"
-        ],
-        "title": "Color",
-        "type": "string"
-      },
-      "difficulty": {
-        "default": 5,
-        "description": "AI Difficulty Level (1-10), if type is 'computer'.",
-        "maximum": 10,
-        "minimum": 1,
-        "title": "Difficulty",
-        "type": "integer"
-      },
-      "showUi": {
-        "default": false,
-        "description": "If true, returns an interactive HTML board in waitForNextTurn. Required for human players.",
-        "title": "Showui",
-        "type": "boolean"
-      },
-      "type": {
-        "description": "Play against 'computer' (AI) or 'agent' (another tool/human)",
-        "enum": [
-          "computer",
-          "agent"
-        ],
-        "title": "Type",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type"
-    ],
-    "title": "GameConfig",
-    "type": "object"
-  }
-}

addedInput schema / properties / color

Added value: +{
+  "default": "white",
+  "description": "Your color. 'white' moves first. If 'black', computer will move first.",
+  "enum": [
+    "white",
+    "black"
+  ],
+  "title": "Color",
+  "type": "string"
+}

removedInput schema / properties / config

Removed value: -{
-  "$ref": "#/$defs/GameConfig"
-}

addedInput schema / properties / difficulty

Added value: +{
+  "default": 5,
+  "description": "AI Difficulty Level (1-10), if type is 'computer'.",
+  "maximum": 10,
+  "minimum": 1,
+  "title": "Difficulty",
+  "type": "integer"
+}

addedInput schema / properties / type

Added value: +{
+  "description": "Opponent type. 'computer': Play against AI (No UI). 'agent': Play against another Agent (No UI). 'human': Play against Human (Returns UI).",
+  "enum": [
+    "computer",
+    "agent",
+    "human"
+  ],
+  "title": "Type",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "config"
-]New value: +[
+  "type"
+]

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "createGameOutput",
-  "type": "object"
-}New value: +null

ChangedfinishTurn4 fields changed

addedInput schema / properties / claim_win / description

Added value: +"Set to true if you are claiming Checkmate or Win with this move."

addedInput schema / properties / game_id / description
```
Added value: +"The ID of the active game."
```

addedInput schema / properties / move / description

Added value: +"The move in UCI format (e.g., 'e2e4')."

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "finishTurnOutput",
-  "type": "object"
-}New value: +null

AddedjoinGame
ChangedwaitForNextTurn1 field changed
- addedInput schema / properties / game_id / description
```
Added value: +"The ID of the active game."
```

3 tool updatesv0.1.0Jan 25, 2026
- First observedcreateGame
- First observedfinishTurn
- First observedwaitForNextTurn

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool serves a distinct purpose: create game, submit move, join game, and wait for turn. No overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in camelCase (createGame, finishTurn, joinGame, waitForNextTurn), making the set predictable and easy to understand.

Tool Count4/5

With 4 tools, the set is compact but covers the essential operations for a chess game. While minimal, it avoids unnecessary complexity and feels appropriately scoped.

Completeness3/5

The tools cover core gameplay but lack common chess operations like resign, draw, or move history. There is no way to get the current board state without waiting for a turn, creating a notable gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
26
agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
Skedra Whiteboard
io.github.moonriddim
Create, read and live-edit visual boards, Kanban plans, Gantt timelines and diagrams with AI agents.
Project Management Workplace & Productivity Design Tools
1
DynamicEndpoints-autogen_mcpOAuth
ai.smithery
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Autonomous Agents Agent Orchestration Developer Tools
215

Related MCP Servers

MCP Chess Server
Games & Gamification App Automation
jiayao
A
license
Not graded
quality
D
maintenance
A server that enables users to play chess against any LLM, with features for visualizing the board, making moves in standard notation, and analyzing positions from PGN files.
Updated a year ago (2025-05-05 06:09 UTC)
23
Apache 2.0
Chess MCP
makimoto
-
license
Not graded
quality
Not graded
maintenance
A Model Context Protocol server that enables LLM agents and humans to play chess games together with comprehensive game management capabilities including move validation, draw detection, and game state tracking.
Updated a year ago (2025-07-09 04:04 UTC)
-
Chess MCP Server
Games & Gamification
chatkausik
F
license
Not graded
quality
D
maintenance
Enables AI assistants to play, analyze, and track chess games with full rule validation and support for standard algebraic notation. It provides tools for position evaluation and game state persistence during user sessions.
Updated 9 months ago (2025-12-04 12:06 UTC)
-
Chess MCP Server
Games & Gamification
aidanouckama
F
license
A
quality
D
maintenance
Enables AI assistants to play chess against users, manage games, make moves, and visualize boards with Stockfish AI opponent.
Updated 9 months ago (2025-11-26 20:22 UTC)
8
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fritzprix/chess-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server