Loading ToolBench
A Model Context Protocol (MCP) server for playing Chess with AI Agents.
The Chess MCP server has 6 well-named tools with clear action verbs (create, wait, finish, join, list, get). All tools have descriptions ranging from 60-120 characters. Input schemas are present and mostly complete with types and enums. However, there are significant gaps: output schemas are not documented (responses are inferred from code rather than explicitly declared), some parameter descriptions lack detail about format/constraints, and error handling lacks recovery guidance. The tool set is logically composed and names are action-oriented, but the overall quality is held back by missing output documentation and limited error recovery hints.
Initializes a new chess game session. Returns the Game ID and instructions.
Submits a move and returns the updated state or a precise failure.
Retrieves the full state of a specific game.
Join an existing game as the second player (opponent).
Lists all active games (IDs and current states).
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.
Output schemas not documented. No tool returns a declared schema structure. LLMs cannot see what fields to expect or plan downstream calls. The code shows content arrays being returned (with types.TextContent and types.EmbeddedResource), but the tool definitions in FastMCP do not declare output_schema.
Error handling lacks recovery guidance. waitForNextTurn returns timeout with a retry instruction, and finishTurn returns failure, but most error paths (e.g. game not found in joinGame) raise ValueError without suggesting next actions. Errors should tell LLMs whether to retry, call a different tool, or ask the user.
Parameter descriptions lack format constraints. The 'move' parameter in finishTurn is described as 'The move in UCI format (e.g. 'e2e4')' but does not specify validation (e.g. must be 4 characters, lowercase, numeric coordinates). LLMs cannot validate on their own and may pass invalid values.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
listGames and getGameState have no pagination or result limit documentation. If many games exist, responses could blow the context window. The tool descriptions do not state whether results are capped or paginated.
No idempotency or confirmation for destructive operations. finishTurn with claim_win=true modifies game state irreversibly. There is no dry-run option or confirmation step to prevent accidental checkmate claims.