chess-mcp-server 0.1.0__tar.gz

chess_mcp_server-0.1.0/.gitignore

@@ -0,0 +1,47 @@
+# Python
+__pycache__/
+*.py[cod]
+*$py.class
+*.so
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# Virtual Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Environment Variables
+.env
+.env.*
+
+# IDEs
+.vscode/
+.idea/
+*.swp
+
+# OS
+.DS_Store
+Thumbs.db
+
+# MCP
+.gemini/

chess_mcp_server-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Fritzprix
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

chess_mcp_server-0.1.0/PKG-INFO

@@ -0,0 +1,111 @@
+Metadata-Version: 2.4
+Name: chess-mcp-server
+Version: 0.1.0
+Summary: A Model Context Protocol (MCP) server for playing Chess with AI Agents.
+Project-URL: Homepage, https://github.com/fritzprix/chess-mcp-server
+Project-URL: Issues, https://github.com/fritzprix/chess-mcp-server/issues
+Author-email: fritzprix <your-email@example.com>
+License-Expression: MIT
+License-File: LICENSE
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.10
+Requires-Dist: fastapi
+Requires-Dist: jinja2
+Requires-Dist: mcp[cli]
+Requires-Dist: python-chess
+Requires-Dist: uvicorn
+Description-Content-Type: text/markdown
+
+# ♟️ Chess MCP Server
+
+**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.
+
+## 📦 Installation
+
+### Prerequisites
+-   Python 3.10+
+-   An MCP Client (e.g., [Claude Desktop](https://claude.ai/download), [Cursor](https://cursor.sh/))
+
+### 1. Installation
+You can install directly from PyPI:
+
+```bash
+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):
+
+```json
+{
+  "mcpServers": {
+    "chess": {
+      "command": "uvx",
+      "args": ["chess-mcp-server"]
+    }
+  }
+}
+```
+
+*Alternatively, using pip installation:*
+```json
+{
+  "mcpServers": {
+    "chess": {
+      "command": "python",
+      "args": ["-m", "src.mcp_server"]
+    }
+  }
+}
+```
+
+## 🛠️ Development
+
+If you want to modify the code:
+
+1.  **Clone & Setup**
+    ```bash
+    git clone https://github.com/fritzprix/chess-mcp-server.git
+    cd chess-mcp-server
+    
+    python -m venv .venv
+    source .venv/bin/activate
+    pip install -r requirements.txt
+    ```
+
+## 🎮 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."*
+
+### The Game Loop
+1.  **Your Move**:
+    -   Interact with the **HTML Board** if shown. Drag your piece and click **Confirm**.
+    -   *Or* tell the Agent: *"Move pawn to e4."*
+2.  **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.
+3.  **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.

chess_mcp_server-0.1.0/README.md

@@ -0,0 +1,91 @@
+# ♟️ Chess MCP Server
+
+**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.
+
+## 📦 Installation
+
+### Prerequisites
+-   Python 3.10+
+-   An MCP Client (e.g., [Claude Desktop](https://claude.ai/download), [Cursor](https://cursor.sh/))
+
+### 1. Installation
+You can install directly from PyPI:
+
+```bash
+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):
+
+```json
+{
+  "mcpServers": {
+    "chess": {
+      "command": "uvx",
+      "args": ["chess-mcp-server"]
+    }
+  }
+}
+```
+
+*Alternatively, using pip installation:*
+```json
+{
+  "mcpServers": {
+    "chess": {
+      "command": "python",
+      "args": ["-m", "src.mcp_server"]
+    }
+  }
+}
+```
+
+## 🛠️ Development
+
+If you want to modify the code:
+
+1.  **Clone & Setup**
+    ```bash
+    git clone https://github.com/fritzprix/chess-mcp-server.git
+    cd chess-mcp-server
+    
+    python -m venv .venv
+    source .venv/bin/activate
+    pip install -r requirements.txt
+    ```
+
+## 🎮 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."*
+
+### The Game Loop
+1.  **Your Move**:
+    -   Interact with the **HTML Board** if shown. Drag your piece and click **Confirm**.
+    -   *Or* tell the Agent: *"Move pawn to e4."*
+2.  **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.
+3.  **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.

chess_mcp_server-0.1.0/docs/analysis/feasibility_report.md

@@ -0,0 +1,160 @@
+# MCP Tools Specification Feasibility Analysis
+
+## 1. Overview
+This document analyzes the feasibility of the tools defined in `docs/spec/tools.md` based on the `docs/mcp_reference_en.md` standard.
+
+**Conclusion:** The proposed specification is **FEASIBLE**.
+**Updates:**
+- Generic `finishTurn` is recommended.
+- `waitForNextTurn` with 30s long-polling is feasible.
+- **Checkmate Claiming**: Explicit checkmate acknowledgment by the user is feasible and supported.
+- **Web Dashboard**: Sidecar web server with auto-launch is feasible.
+
+## 2. Detailed Verification
+
+| Feature spec | MCP Reference Component | Feasibility | Notes |
+| :--- | :--- | :--- | :--- |
+| **Tool: `createGame`** | Section 2.4 (Tools) | ✅ Supported | Standard tool definition. Returns text. |
+| **Tool: `waitForNextTurn`** | Section 2.4 (Tools) | ✅ Supported | Standard tool definition. Returns text + resource. |
+| **Tool: `finishTurn`** | Section 2.4 (Tools) | ✅ Supported | Generic submission of moves. Replaces `finishUserTurn`. |
+| **Text Rendering** | N/A (Client Rendering) | ✅ Supported | Markdown tables are standard in LLM responses. |
+| **UI Resource** | Section 3.1 & 3.2 | ✅ Supported | `text/html` is a valid `UIResource` MIME type (Strategy 1). |
+| **UI Interaction (Move)** | Section 3.3 (UI Actions) | ✅ Supported* | Requires Host to handle `postMessage` and strict `onUIAction` loop. |
+
+## 3. Implementation Details & Considerations
+
+### 3.1 UI Resource Implementation
+The specification calls for returning an HTML board when `showUi` is true.
+According to Reference Section 3.2 (Strategy 1):
+- Server returns: simple HTML string.
+- Host behavior: Injects into sandboxed iframe.
+- **Feasible**: Yes, the Python `show_dashboard` example (Reference Section 4.2) directly demonstrates this pattern using `text/html`.
+
+### 3.2 Bi-directional Interaction (The "User Move")
+The spec mentions: "User... selects Confirm... user's move is sent to server... usage choice is `finishUserTurn`... via MCP UI ui action".
+
+**Mechanism:**
+1.  **HTML Logic**: The embedded HTML board must contain JavaScript to capture clicks and send a message.
+    ```javascript
+    // Inside the HTML returned by waitForNextTurn
+    window.parent.postMessage({
+      type: 'action',
+      action: 'finishTurn', // GENERIC NAME RECOMMENDED
+      payload: { from: 'e2', to: 'e4' } 
+    }, '*');
+    ```
+2.  **Host Handling**: The MCP Host (e.g., Claude Desktop, IDE) receives this event.
+3.  **Loopback**: The Host must route this action to a tool call.
+    - *Note*: The MCP reference Section 3.3 says "The host then cycles this back by calling MCP tools".
+    - You will likely need to expose `finishUserTurn` as an MCP Tool so the host (or the Agent reacting to the UI event) can call it.
+
+### 3.3 The `waitForNextTurn` Blocking Issue
+One logical ambiguity in the spec is the behavior of `waitForNextTurn` when it is the **Human's** turn.
+- If the LLM calls `waitForNextTurn`, and it is the Human's turn, the tool should likely:
+    1.  Return the board state immediately with a status "Waiting for User".
+    2.  The LLM should then perhaps yield or wait?
+    3.  **Recommended Pattern**: The `waitForNextTurn` tool serves as a "Refresh/Poll" mechanism. The LLM sees the state. If it's human turn, LLM does nothing (or just outputs "Waiting for human move..."). When Human moves (via UI -> `finishUserTurn`), the state updates. The LLM might be re-triggered or manually check again.
+
+## 4. Analysis: `finishTurn` vs `finishUserTurn`
+The user questioned if a generic `finishTurn` is sufficient for both scenarios (Agent move vs User move).
+
+**Recommendation: Use `finishTurn` for ALL moves.**
+
+### Reasons:
+1.  **Protocol Simplicity**: The server logic is "Execute Move X on Game Y". The mechanics of *who* originated the move (Agent thinking process vs User UI click) are transport details.
+2.  **State-Driven Validation**: The Server already knows whose turn it is.
+    *   If requests `finishTurn` and it is **Agent's Turn**: Accepted.
+    *   If requests `finishTurn` and it is **User's Turn**: Accepted (assuming the UI triggered it).
+    *   *Security Note*: Strictly speaking, if the Agent (LLM) hallucinates and calls `finishTurn` during the User's turn, the server MUST return an error ("Not your turn"). This state check is required regardless of the tool name.
+3.  **Unified Schema**:
+    ```typescript
+    finishTurn(game_id: string, move: string)
+    ```
+    This single signature covers both cases.
+
+### Revised Flow with `finishTurn`:
+1.  **Agent Turn**: LLM thinks -> Calls `finishTurn(game_id, move)`. Server updates state.
+2.  **User Turn**:
+    *   LLM Calls `waitForNextTurn`.
+    *   Server returns UI.
+    *   User interacts with UI -> `postMessage({ action: 'finishTurn', ... })`.
+    *   Host receives message -> Calls `finishTurn(game_id, move)`.
+    *   Server updates state.
+
+## 5. Analysis: `waitForNextTurn` Blocking Strategy
+The proposed strategy is:
+- **Blocking**: 30 seconds wait for opponent move.
+- **Return Condition 1 (Activity)**: Opponent moves -> Return State Immediately.
+- **Return Condition 2 (Timeout)**: 30s elapsed -> Return "Timeout, try again" message.
+
+**Feasibility: ✅ Confirmed**
+
+### Considerations:
+1.  **Host Timeout**: Most MCP Clients (Host applications) set a timeout for tool calls.
+    - *Typical Default*: Often 60s or more.
+    - *Risk*: If the Host has a very short timeout (e.g., 10s), this call will fail with a Protocol Error before the server returns the custom "Timeout" message.
+    - *Mitigation*: 30 seconds is generally a safe lower bound. It allows for a "Long Poll" pattern without triggering aggressive read timeouts.
+2.  **Server Implementation**:
+    - Must use asynchronous sleep (`await asyncio.sleep(0.1)` or `threading.Event`).
+    - Do NOT use `time.sleep(30)` in a single-threaded blocking server, as it will freeze the entire server for all users/requests.
+    - *Recommendation*: Use `async def` and event loops (FastMCP supports this natively).
+3.  **LLM Loop**:
+    - The LLM must be instructed (via the System Prompt or Tool Description) that receiving a "Timeout" is **normal** and it should simply call the tool again. Without this, the LLM might interpret the timeout as a failure and stop or hallucinate complications.
+
+**Revised Tool Description Suggestion:**
+> "Waits for the opponent to move. Blocks for up to 30 seconds. If the opponent moves, returns the new board state. If no move occurs within 30 seconds, returns a timeout message. You should immediately call this tool again if you receive a timeout."
+
+## 6. Analysis: Checkmate Acknowledgement
+The user requested that the user must "explicitly decide" whether a move is checkmate.
+
+**Feasibility: ✅ Confirmed**
+
+To support this:
+1.  **Protocol**: Update `finishTurn` to accept `claim: string` (values: `null`, `'checkmate'`, `'draw'`).
+2.  **Validation**:
+    - If `claim='checkmate'` is sent, the server MUST verify `board.is_checkmate()` AFTER the move.
+    - If valid -> Win acknowledged.
+    - If invalid -> Return error "Accusation failed: Not checkmate".
+3.  **UI**: The HTML Board requires an interactive element (e.g., specific "Move & Claim Checkmate" button or a toggle).
+
+**Modified Schema**:
+```typescript
+finishTurn(
+  game_id: string, 
+  move: string, 
+  claim_win?: boolean // if true, asserts this move ends the game
+)
+```
+
+**Recommendation for Spec**: Include `claim_win` as an optional parameter to support this "Explicit Decision" mechanic.
+
+## 7. Analysis: Web Dashboard & Sidecar Server
+**Use Case**: When the MCP server starts, it should satisfy "start web server + open browser" to show a game list.
+
+**Feasibility: ✅ Confirmed (with considerations)**
+
+### Architecture
+- **Dual Interface**:
+    1.  **MCP Interface**: Stdio/SSE handling JSON-RPC.
+    2.  **HTTP Interface**: Sidecar web server (e.g., Flask/FastAPI/Starlette) running on localhost (random or fixed port).
+- **Execution**: The MCP server entry point must launch the HTTP server background thread/task on startup (`lifespan` event or `__main__`).
+
+### Mechanism
+1.  **Startup**:
+    - Initialize `FastMCP` (or equivalent).
+    - Start HTTP Server (e.g. `uvicorn.run` in a thread).
+    - Get Port (e.g., `8080`).
+2.  **Browser Launch**:
+    - Use Python `webbrowser` module: `webbrowser.open("http://localhost:8080")`.
+    - *Note*: This works well on local machines (macOS/Windows/Linux). It may fail silently in headless environments (SSH/Cloud), which is acceptable.
+
+### UX Consideration
+- **Auto-Open**: If the server crashes/restarts frequently, the browser popping up repeatedly can be annoying.
+- **Mitigation**: Add a logic to only open if not already "running" or check a flag/env var `MCP_DISABLE_BROWSER=1`.
+
+### Integration with Game State
+- The Game State manager must be a singleton shared between the MCP Tools context and the HTTP Server endpoints.
+- **Endpoints**:
+    - `GET /`: HTML Dashboard showing list of active games.
+    - `GET /api/games`: JSON list.
+    - `GET /game/{id}`: View specific game board (spectator mode).

chess_mcp_server-0.1.0/docs/chess_logic.md

@@ -0,0 +1,161 @@
+Here is a proposal to quantify the difficulty into 10 distinct levels using a hybrid approach of **Search Depth** (foresight) and **Error Rate** (probability of making a random move instead of the best move).
+
+### Logic: The Hybrid Model
+
+* **Depth (1-4):** Controls how far the AI calculates. Python is relatively slow, so Depth 4 is a realistic maximum for a responsive game without C++ extensions.
+* **Error Rate (0.0 - 0.6):** The probability that the AI ignores the "best move" and picks a random legal move (simulating a blunder).
+
+### Configuration Dictionary
+
+| Level | Depth | Error Rate | Description |
+| --- | --- | --- | --- |
+| **1** | 1 | 60% | Calculates 1 move ahead, frequently plays randomly. |
+| **2** | 1 | 40% | Still shortsighted, but slightly more coherent. |
+| **3** | 1 | 20% | Rarely misses immediate captures, but has no plan. |
+| **4** | 2 | 20% | Starts seeing 2 moves ahead, but makes mistakes. |
+| **5** | 2 | 10% | Standard amateur level. Solid 2-move calculation. |
+| **6** | 3 | 10% | Stronger. Sees 3 moves ahead, occasional errors. |
+| **7** | 3 | 5% | Competent. Very few unforced errors. |
+| **8** | 3 | 0% | Best possible play at Depth 3. |
+| **9** | 4 | 5% | Deep calculation (slower), slight human-like noise. |
+| **10** | 4 | 0% | Maximum strength. Pure Minimax at Depth 4. |
+
+### Python Implementation
+
+This code wraps your previous Minimax logic into a class structure that accepts a level (1-10).
+
+```python
+import chess
+import math
+import random
+
+class ChessAI:
+    def __init__(self):
+        # Configuration for 10 levels
+        self.levels = {
+            1:  {"depth": 1, "error_rate": 0.60},
+            2:  {"depth": 1, "error_rate": 0.40},
+            3:  {"depth": 1, "error_rate": 0.20},
+            4:  {"depth": 2, "error_rate": 0.20},
+            5:  {"depth": 2, "error_rate": 0.10},
+            6:  {"depth": 3, "error_rate": 0.10},
+            7:  {"depth": 3, "error_rate": 0.05},
+            8:  {"depth": 3, "error_rate": 0.00},
+            9:  {"depth": 4, "error_rate": 0.05},
+            10: {"depth": 4, "error_rate": 0.00},
+        }
+        
+        # Piece values for evaluation
+        self.piece_values = {
+            chess.PAWN: 10, chess.KNIGHT: 30, chess.BISHOP: 30,
+            chess.ROOK: 50, chess.QUEEN: 90, chess.KING: 900
+        }
+
+    def get_move(self, board, level):
+        """
+        Returns the best move based on the difficulty level (1-10).
+        """
+        if level not in self.levels:
+            level = 5 # Default to medium
+            
+        settings = self.levels[level]
+        depth = settings["depth"]
+        error_rate = settings["error_rate"]
+
+        # 1. Error Chance (Simulate Blunder)
+        # If the random roll is within the error rate, pick a random legal move.
+        if random.random() < error_rate:
+            return random.choice(list(board.legal_moves))
+
+        # 2. Strategic Calculation (Minimax)
+        # Otherwise, calculate the best move using Minimax.
+        return self._get_best_move_minimax(board, depth)
+
+    def _evaluate_board(self, board):
+        if board.is_checkmate():
+            return -9999 if board.turn else 9999
+        if board.is_stalemate() or board.is_insufficient_material():
+            return 0
+
+        score = 0
+        for square in chess.SQUARES:
+            piece = board.piece_at(square)
+            if piece:
+                value = self.piece_values[piece.piece_type]
+                if piece.color == chess.WHITE:
+                    score += value
+                else:
+                    score -= value
+        return score
+
+    def _minimax(self, board, depth, alpha, beta, maximizing):
+        if depth == 0 or board.is_game_over():
+            return self._evaluate_board(board)
+
+        legal_moves = list(board.legal_moves)
+        
+        if maximizing:
+            max_eval = -math.inf
+            for move in legal_moves:
+                board.push(move)
+                eval = self._minimax(board, depth - 1, alpha, beta, False)
+                board.pop()
+                max_eval = max(max_eval, eval)
+                alpha = max(alpha, eval)
+                if beta <= alpha:
+                    break
+            return max_eval
+        else:
+            min_eval = math.inf
+            for move in legal_moves:
+                board.push(move)
+                eval = self._minimax(board, depth - 1, alpha, beta, True)
+                board.pop()
+                min_eval = min(min_eval, eval)
+                beta = min(beta, eval)
+                if beta <= alpha:
+                    break
+            return min_eval
+
+    def _get_best_move_minimax(self, board, depth):
+        best_move = None
+        best_value = -math.inf if board.turn == chess.WHITE else math.inf
+        alpha = -math.inf
+        beta = math.inf
+        
+        legal_moves = list(board.legal_moves)
+        
+        # Simple optimization: shuffle moves to prevent deterministic behavior on equal scores
+        random.shuffle(legal_moves)
+
+        for move in legal_moves:
+            board.push(move)
+            value = self._minimax(board, depth - 1, alpha, beta, not board.turn)
+            board.pop()
+
+            if board.turn == chess.WHITE:
+                if value > best_value:
+                    best_value = value
+                    best_move = move
+                alpha = max(alpha, best_value)
+            else:
+                if value < best_value:
+                    best_value = value
+                    best_move = move
+                beta = min(beta, best_value)
+                
+        return best_move
+
+# --- Usage Example ---
+if __name__ == "__main__":
+    board = chess.Board()
+    ai = ChessAI()
+
+    # User selects Level 7
+    user_level = 7
+    print(f"AI Level: {user_level} (Depth: {ai.levels[user_level]['depth']}, Error: {ai.levels[user_level]['error_rate']*100}%)")
+
+    best_move = ai.get_move(board, level=user_level)
+    print(f"AI plays: {best_move}")
+
+```