Loading ToolBench
An MCP server over the esca chess library: rules, facts, explanations, openings and PGN, with no engine
The chess-esca-mcp server defines 2 tools with strong descriptions and detailed parameter schemas. Naming is clear and verb-free (position, legal_moves) but lacks conventional verb prefixes (e.g., 'get_position', 'list_legal_moves') that would improve LLM intent recognition. Both tools have comprehensive, well-written descriptions (180-280 chars) exceeding the baseline of 194 chars. Input schemas are fully typed with descriptions for all parameters. However, output schemas are NOT documented in the source code, descriptions mention what is returned ('Each move carries what it does...') but no formal output schema is visible. Error handling exists (error field mentioned) but recovery guidance is minimal. Tool annotations (readOnlyHint) are present, which is a positive sign of spec alignment. No security concerns (all tools are read-only, no secrets in parameters). The composition is sound: two single-responsibility tools with clear separation.
Every legal move of a position, in SAN and in UCI. Each move carries what it does — the role that moves, whether it captures and what, whether it gives check, what it promotes to, and the static exchange it starts. With `categories`, the same moves are also grouped as captures, checks, castling, promotions, en passant and quiet.
The whole state of a chess position, read by the rules. Answers in one call: whose turn it is, whether that side is in check and from where, whether the game is over and how, which draws are claimable and on what evidence, how many legal moves there are, the opening name if the position has one, the material on each side, both castlings of both colours with every obstacle at once, the en-passant capture on offer, the pins and skewers on the board, and the ending it is where the material makes one. `prose` gathers every sentence the answer carries.
Tool names lack action verbs. 'position' and 'legal_moves' are nouns; LLM intent recognition improves with verb-prefixed names like 'get_position', 'list_legal_moves', or 'analyze_position'. Baseline: 90% of A+ tools start with an action verb.
Output schemas are not documented in source. Descriptions state what is returned ('Answers in one call: whose turn it is, whether that side is in check...') but no formal schema (JSON Schema with types and fields) is visible. LLMs cannot plan downstream calls without knowing the response structure. Baseline: 100% of A+ tools have documented return types.
Error handling lacks recovery guidance. Code mentions `{"error": {...}}` responses but source does not show what fields the error object contains or how LLMs should interpret and recover from specific errors (e.g., invalid FEN, unsupported variant).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
Parameter 'variant' accepts free-form string values ('classic' or 'chess960' mentioned in descriptions) but no enum constraint is visible in the schema. Free-form strings invite hallucinated values; an enum is self-documenting and prevents invalid variants from being passed.