llm-chess-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation4/5
The game lifecycle tools (create_game, delete_game, game_state, game_play_move, etc.) are clearly distinct. The analysis tools (position_analyze, move_evaluate, move_candidates, move_candidates_by_intent) have overlapping purposes, but descriptions clarify their unique roles (e.g., analyze position vs. evaluate specific moves).
Naming Consistency4/5
Most tools follow a snake_case pattern with resource prefixes (game_, move_, position_, human_, opening_). There is some inconsistency: create_game and delete_game are verb-first, while others are noun-first (game_state, position_analyze, move_candidates), but the pattern is still readable.
Tool Count5/5
13 tools is well within the 3-15 range and each tool earns its place covering game creation, state management, move execution, and multiple analysis capabilities. The count feels appropriate for a comprehensive chess server.
Completeness5/5
The tool set covers the full game lifecycle (create, play, query, delete) and exports/imports via PGN. It includes extensive analysis features (Stockfish, Maia, opening explorer) with no obvious dead ends. The only minor gap is no list_games tool, but the server likely manages games internally.
Average 4/5 across 12 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered structurally. The description adds "free its session" as a mild behavioral note but doesn't disclose permanence of deletion, whether related data (moves, analyses) is destroyed, or access requirements. No contradiction with annotations exists; the description adds modest value over what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly one sentence (7 words), front-loaded with the action verb. It's efficient but arguably over-terse — the "free its session" concept and the game_id requirement both deserve elaboration. This borders on under-specification rather than genuine conciseness, though it avoids padding.
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 1-parameter destructive tool with good annotations and an output schema, the description is minimally adequate. The main gap is the unexplained "free its session" semantic — whether deletion is permanent, whether sessions are tied to games, and what the caller should expect afterward. Low complexity lowers the bar, but the session concept creates real ambiguity the description should resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. While game_id is a self-descriptive parameter name, the description doesn't explain how to obtain a valid game_id (e.g., from create_game or game_state), any format expectations, or validation constraints. With zero coverage, the description carries the burden and drops the ball.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Delete a game" clearly identifies the verb and resource, and it implicitly distinguishes from create_game among siblings. However, "free its session" is vague and unexplained — it's unclear what a session is, what freeing it means, or whether it implies releasing resources beyond the game itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites (ownership, active games, permissions), and no reference to sibling tools like create_game as the inverse operation. It neither states exclusions nor implies usage context beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate a safe read-only operation. Description adds environment requirement: the question requires a token. Does not mention permissions, read-only side effects, or returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short description of one sentence with no unnecessary details. However, the output or result not mentioned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema(true), annotations (readOnly/openWorld/idempotent), the description doesn't mention what the tool returns (opening list/names/counts), so the agent may not know if it can fulfill the request. the description is too sparse for interactive decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description gives no parameter semantics. The input schema covers params and types but does not explain the source or valid values. There are 4 parameters and he documentation does not cover the specific role of `db`, `speeds`, `ratings`, or `game_id`. Coverage is 0% and the description doesn't compensate.
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?
Description uses a specific verb ('Query') with the Lichess opening explorer and the current position context. However, it doesn't distinguish itself from sibling tools other than by name and implicit use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like position_move or game_analysis. The only guidance meaning implied: 'current position' and 'requires a token'. Not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no new behavioral context. The word 'Export' is consistent with read-only, but there is no elaboration on side effects, permissions, or response details beyond the output schema.
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 a single sentence with zero filler. It efficiently states the tool's function without unnecessary detail, making it easy to parse quickly.
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 is simple with one parameter and an output schema, so the description covers the core action. However, it lacks any guidance on alternatives or parameter specifics, and the lack of usage context means the description is only minimally adequate for the tool's overall adoption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the parameter, but it only refers to 'the current game' without explaining that game_id identifies which game. The lone parameter's meaning is left implicit, forcing the agent to infer from the parameter name alone.
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 states a specific action ('Export') on a specific resource ('the current game') with a clear output format (PGN). It distinguishes from siblings like game_import_pgn (import) and game_state (state retrieval), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as game_state or game_import_pgn. The description is a single declarative sentence with no context about scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the transparency burden. It discloses that a new game is created (side effect), returns a game_id, and rejects invalid PGN. However, it does not mention idempotency, potential side effects on other resources, or permission requirements, but the core side effect is well-stated.
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 three concise sentences: action, result, and error handling. No unnecessary details or redundant phrasing. It is well-structured and easy to parse.
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?
There is no output schema, but the description clearly states the output: 'Returns a new game_id.' It also mentions error rejection. It does not describe the error format or potential additional outputs (e.g., full game state), but for a simple import tool, these details are not critical. The description provides sufficient context for a basic understanding.
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 'pgn' has no description in the schema. The description implies it is a PGN string by the tool name and purpose, and mentions rejection of malformed PGN, but does not elaborate on acceptable format (e.g., whether headers are required) or provide examples. This is minimal but adequate for a standard chess PGN.
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: 'Import a PGN into a new game' and its outcome: 'Returns a new game_id with the position after all PGN moves.' This distinguishes it from sibling tools like create_game, game_pgn, and game_play_move by specifying the input format (PGN) and the new game 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 description mentions error behavior ('Rejects malformed or illegal PGN') but does not explicitly indicate when to use this tool versus alternatives, such as when a PGN is available versus starting a blank game with create_game. There is no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate these. The description adds behavioral context by listing the output fields (SAN, UCI, piece, capture, promotion), which informs the agent about the nature of the response. No contradictions with annotations are present.
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 a single, front-loaded sentence that clearly states the action and output fields. It contains no filler or redundant information, making it highly concise and well-structured.
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?
Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description adequately covers the necessary context. It specifies the output fields and the operation's scope ('current position'). It could have mentioned edge cases (e.g., no legal moves) or the meaning of 'current position' in terms of move history, but these are not critical for a basic move-listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, game_id, with no description coverage (0%). The tool description does not mention game_id at all, leaving its semantics implicit. While the parameter is self-explanatory (identifying the game), the description fails to compensate for the lack of schema descriptions, providing no added meaning beyond the name and type.
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 tool lists all legal moves in the current position, specifying the output fields (SAN, UCI, piece, capture, promotion). This distinguishes it from sibling tools like game_play_move (which executes moves) and move_candidates (which may provide candidate analysis), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for retrieving legal moves for the current game identified by game_id, but it does not explicitly contrast with alternatives like move_candidates or position_analyze. The context is clear, but no exclusions or specific when-to-use guidance are given, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds value by specifying the content of the response (fields) and the optional include_ascii behavior, but does not disclose additional behavioral nuances like response format or error conditions beyond what annotations already imply. With strong annotations, this is adequate.
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 sentences, front-loaded with the core purpose and fields, followed by an optional usage hint. Every sentence carries value; there is no fluff or redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which explains return structure) and the simple parameter set, the description fully covers what the tool does and when to use it. It even lists the key fields for quick understanding and provides a usage example for the optional parameter. It is complete for this tool's complexity.
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 is 0%, so the description must compensate. It explains include_ascii (setting it true provides a board diagram) but leaves game_id implicit, though the name suggests it identifies the game. It adds some meaning for include_ascii, but could have explicitly stated game_id's purpose. Since game_id is evident from context, this partially compensates.
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 tool returns the authoritative game state and enumerates specific fields (FEN, turn, revision, flags, move history, etc.). It differentiates itself from siblings like game_pgn (which likely returns a different format) by focusing on the internal state, and explicitly suggests using it instead of remembering the board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use this tool instead of relying on memory, giving a clear when-to-use context. It does not explicitly mention when not to use it or mention alternatives, but the ton of 'authoritative state' and scope differentiate it from related tools. No exclusions are stated, but the implied usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and determinism. The description adds crucial behavioral nuances: it clarifies that higher probability means more human-typical, and explicitly notes that this is not move quality, preventing misinterpretation. It does not contradict annotations, and adds context beyond what annotations provide, such as the meaning of the output values.
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 extremely concise—two sentences, no fluff. Every word earns its place: the first sentence defines the function and key input (Elo), and the second provides a critical caveat. It is front-loaded with the core purpose and avoids unnecessary details.
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?
The tool is relatively simple (read-only, 1 required param) and has an output schema, so the description needn't detail the return structure. It covers the core usage and behavior (human-likeness, Elo conditioning, not-quality warning). The main gap is parameter semantics (covered separately), but overall the description provides sufficient context for an agent to understand what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only mentions 'target Elo' (which maps to elo) but does not clarify top_n (how many moves returned), oppo_elo (opponent rating effect), or game_id (required, identifies position). The word 'distribution' might imply all moves, but top_n suggests a subset, creating ambiguity. This is inadequate for a 4-param tool with no schema descriptions.
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 tool returns the Maia3 human-like move probability distribution for the current position, conditioned on target Elo. It explicitly distinguishes itself from move quality ('This is NOT move quality'), which differentiates it from siblings like move_evaluate or position_analyze. The verb 'Return' and specific resource 'Maia3...distribution' make the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need human-like probabilities for a given rating, and warns against confusing with move quality. It does not explicitly mention alternatives or when NOT to use it, but the 'NOT move quality' caveat curbs misuse. The 'conditioned on a target Elo' hints at the parameter, but no direct guidance on top_n or oppo_elo is given. So it provides clear context with a partial exclusion but lacks explicit alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context by explaining that moverCp is from the mover's perspective and that the tool merges three distinct evaluation sources, which goes beyond what annotations or schema convey.
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 three sentences, front-loaded with the tool's primary role, and every sentence adds meaningful context: what the tool does, the moverCp perspective, and when to use it. There is no redundancy or filler.
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?
Given the tool's complexity and the presence of an output schema and helpful annotations, the description covers the core selection context well. It could be more complete by explicitly contrasting with sibling tools like move_candidates_by_intent, but the 'primary' framing mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the nine input parameters such as elo, sf_depth, lichess_ratings, or analysis_level. It adds meaning to the output metrics but fails to compensate for the lack of parameter documentation.
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 this is the primary move-selection tool and that it combines Stockfish evaluation, Maia3 human probability, and Lichess statistics into a unified candidate list. This specific verb+resource combination distinguishes it from sibling tools like move_evaluate or move_candidates_by_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to use this tool before choosing a move, which is strong usage guidance. However, it does not name alternatives or provide when-not-to-use conditions, so it falls short of full differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and idempotentHint=true, and the description explicitly states 'without mutating the game,' reinforcing that. It also adds value by describing the output (score, cpLoss, classification) and the engine (Stockfish), which are not required but provide useful behavioral context.
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 concise—three sentences—and front-loaded with the core purpose and non-mutation guarantee. Every sentence adds meaning without redundancy.
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?
An output schema is present, so detailed return field explanations are unnecessary. The description covers the primary purpose, input flexibility, and key output categories, making it adequate for most usage scenarios. Minor omissions (e.g., depth semantics) are acceptable given the schema's constraints.
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 is 0% and the description partially compensates by explaining the 'move' parameter format (string or array). However, it does not clarify the 'depth' or 'game_id' parameters beyond what the schema already provides, leaving incomplete semantic 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?
The description clearly states the tool evaluates moves using Stockfish, specifying the action (evaluate), resource (moves), and context (without mutating the game). It distinguishes itself from sibling tools like game_play_move (which mutates) and game_legal_moves (which lists legal moves).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for analysis rather than gameplay via 'without mutating the game' and mentions comparing moves, which gives context. However, it does not explicitly name alternative tools or provide exclusion criteria, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) already indicate a write operation, but the description adds the critical behavioral directive to treat the server as the source of truth and avoid local board tracking. It also discloses the return of game_id. This goes beyond what annotations provide.
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 sentences and front-loaded with the primary action. Each sentence adds value: the core function, the state-tracking warning, and the optional parameter explanation. No wasted words.
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 create tool with one optional parameter and an existing output schema, the description covers the essential aspects: what it does, return value, usage caution, and parameter semantics. It does not mention error behavior or prerequisites, but these are not critical for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the 'fen' parameter, but the description clearly explains that it is optional and used to start from a custom FEN position. This fully compensates for the missing schema description.
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 starts with a specific verb+resource pair ('Create a new chess game') and explicitly states the return value (game_id), making the tool's purpose unambiguous. It also clearly distinguishes from siblings like delete_game and game_import_pgn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: the server is authoritative and one should never track the board locally, which implies how to use this with other game-state tools. It also notes the optional FEN for custom positions but does not explicitly exclude alternatives like game_import_pgn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds critical concurrency behavior: the STALE_POSITION rejection if the revision is outdated. It also states it returns the resulting state, which is useful even with an output schema.
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?
Three concise sentences deliver the core action, uniqueness, and concurrency requirement with zero fluff. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with an output schema and annotations, the description covers the essential operational details: mutation, concurrency control, error condition, and move format. It is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description compensates by explaining the 'move' parameter (SAN vs UCI) and the 'expected_revision' parameter (required, from a recent read, and its role in staleness). The 'game_id' is self-explanatory, so overall it adds substantial meaning.
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?
Description explicitly states 'Play a move' and even clarifies SAN/UCI formats. The unique claim 'This is the ONLY tool that mutates the game' clearly differentiates it from all siblings, which are read-only or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool (to make a move) and specifies the required expected_revision from a prior read. It does not explicitly mention alternatives, but by highlighting it's the only mutating tool, it implicitly advises that all other tools are non-mutating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds behavioral context by stating it RANKS but does NOT choose a move, and clarifies the meaning of each intent, which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs essential information: purpose, relationship to sibling, behavioral caveat, and intent definitions. It is front-loaded with the core purpose and then details intents. Slightly long but each sentence adds value.
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?
The tool has 10 parameters, 2 required, and an output schema. The description explains the core intent parameter and the tool's role, but does not cover other parameters like elo, sf_depth, or lichess_db. However, the output schema exists, so return values are covered. The description is adequate for a complex tool but could mention how other parameters affect ranking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'intent' parameter in detail with definitions for each enum value, which is critical. However, other parameters like elo, sf_depth, lichess_db, etc., are not explained in the description, relying on the schema's names and defaults. Given the complexity, the description covers the most important parameter but leaves others to inference.
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 it is a convenience layer over move_candidates that ranks candidates for a strategic intent. It explicitly distinguishes itself from move_candidates and clarifies it does not choose a move, which differentiates it from siblings like game_play_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: as a ranking layer over move_candidates, and explicitly warns not to map user skill mechanically to an intent. It also lists all intents with definitions, giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's statement 'Does NOT mutate the game' adds no new information, but it does clarify the evaluation perspective and wdl format, and explains analysis levels without contradiction.
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?
All sentences are purposeful and detailed without redundancy, front-loading the core action and then explaining parameters and output semantics efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with output schema and strong annotations, the description covers the tool's functionality, parameter choices, and output interpretation (cp, mate, wdl) completely, making it highly usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the meaning and effect of analysis_level, depth, and multipv, and clarifies that game_id is required to identify the position. This compensates fully for the lack of schema documentation.
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 tool runs Stockfish on the current position and returns top engine lines, distinguishing it from sibling tools like move_evaluate and move_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains how to specify analysis level or depth/multipv, and mentions it does not mutate the game, but lacks explicit when-not-to-use or alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![llm-chess-mcp MCP server](https://glama.ai/mcp/servers/prepaser/llm-chess-mcp/badges/card.svg)](https://glama.ai/mcp/servers/prepaser/llm-chess-mcp)

Score Badge

Copy to your README.md:

[![llm-chess-mcp MCP server](https://glama.ai/mcp/servers/prepaser/llm-chess-mcp/badges/score.svg)](https://glama.ai/mcp/servers/prepaser/llm-chess-mcp)

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/prepaser/llm-chess-mcp'

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