A Model Context Protocol server for chess analysis, game fetching, and interactive play. Provides tools for position analysis with Stockfish, game review, opening identification, fetching games from Chess.com and Lichess, batch analysis, puzzle generation, performance trend analysis, and interactive chess gameplay.
Chess MCP has 14 tools with mostly complete schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names follow verb_noun convention well (render_*, analyze_*, get_*, identify_*). Descriptions average ~150 chars and explain purpose clearly. However, many parameters lack descriptions (e.g., render_position's 'size', 'orientation'; analyze_game's 'player', 'move_time_ms'). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent; no recovery guidance. Security concern: get_chesscom_games and get_lichess_games accept optional usernames but rely on environment variables as fallback, creating ambiguity about credential handling. The play_game and sync_game_state tools suggest stateful game management, but state persistence mechanism is undocumented.
Review a full chess game (PGN) move-by-move with Stockfish: per-move evals, mistake/blunder classification, accuracy %, opening identification, and the most critical moments with FEN + best-move data ready for render_position.
Get Stockfish's evaluation and top candidate lines for a single position (FEN).
Fetch multiple games and aggregate stats: win rate by opening, color, time control, blunder rate per opening. Runs a lightweight quick scan on games.
Auto-extract tactics from a user's own blunder positions for spaced-repetition practice.
Fetch recent games for a Chess.com account. Each returned game includes full PGN ready to pass to analyze_game. If `username` is omitted, uses the CHESSCOM_USERNAME environment variable.
Read the current ongoing game state (FEN, moves, etc.) to answer user questions about the game. ALWAYS call resume_game after answering!
Output schemas not documented. LLMs cannot predict response structure for any tool. analyze_game returns 'per-move evals, mistake/blunder classification, accuracy %, opening identification, and critical moments' but no formal schema. This forces LLMs to guess field names and types.
Many parameters lack descriptions. render_position's 'size', 'orientation'; analyze_game's 'player', 'move_time_ms'; get_chesscom_games' 'max_games', 'time_class' have no descriptions. LLMs cannot infer parameter meaning from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Fetch recent games for a Lichess account. Each returned game includes full PGN ready to pass to analyze_game. If `username` is omitted, uses the LICHESS_USERNAME environment variable.
Analyze recent games to spot whether a losing streak correlates with time control, opening, or other factors.
Identify the ECO opening name for a game and report where it left known theory. Provide exactly one of `pgn` (full PGN text) or `moves` (list of SAN moves).
Play a full game of chess against Stockfish right inside the chat window. Returns an interactive board.
Animate a sequence of moves as a GIF (default) or a list of PNG frames. Provide exactly one of `moves` (SAN or UCI strings) or `pgn` (full PGN text).
Render a chess position (given as FEN) to a PNG board diagram. arrows: list of specs like "e2e4" (default green), "e2e4:red", or "e4:red" (circle on one square). highlights: list of specs like "e4" (default yellow tint) or "e4:#00ff0055". last_move: UCI string (e.g. "e2e4") to tint the most recently played move's squares.
CRITICAL INSTRUCTION: Always run resume_game automatically after answering ANY user question or request if a game is currently active. This brings the game board back to the front of the chat so the user can continue playing. Do not forget to do this!
Sync the current game state to a file so AI can access it.
No error handling or recovery guidance. Tools provide no actionable error messages. If analyze_game fails due to invalid PGN, LLM receives no guidance on what to do next. No categorization of retryable vs fatal errors.
Stateful game management (play_game, sync_game_state, get_game_state, resume_game) lacks documentation of state persistence mechanism. How is game state stored? Is it per-session, per-user, or global? Undocumented state breaks agent reasoning.
Credential handling ambiguous. get_chesscom_games and get_lichess_games accept optional 'username' but fall back to CHESSCOM_USERNAME / LICHESS_USERNAME env vars. No documentation of which takes precedence or how credentials are injected. Security risk if secrets leak into logs.