BetterChess

Server Details

Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 22 days
Last Tested: 2026-09-22 22:24
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.2/5.0

Scored 2026-09-02 06:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: analyse evaluates positions, attacks lists attacked squares, review replays games for blunders, and rig generates coaching script. No ambiguity between them.

Naming Consistency4/5

All tools share the 'chess_' prefix, and the suffixes are short and meaningful. There is a slight mix of verb-like and noun-like suffixes (analyse, attacks, review, rig), but the pattern is still predictable and readable.

Tool Count4/5

Four tools is appropriate for a chess analysis server, covering analysis, tactics, game review, and a special integration rig. Not too many, not too few, though it might feel slightly minimal for broader chess workflows.

Completeness4/5

The core analysis functions are present: position evaluation, attack squares, game review, and a browser rig. Missing features like move legality checks or board state retrieval are minor gaps that don't block primary use cases.

Available Tools

4 tools

chess_analyseAnalyse a chess positionA

Read-only

Inspect

Returns an engine evaluation of a chess position: the strongest candidate moves with their scores, and the position's checkable facts — side to move, whether that side is in check, undefended pieces and the pieces attacking them, and the material balance. Accepts a FEN, a PGN, or a list of SAN moves from the starting position. Also reports what the OPPONENT would play if it were their turn, which is the difference between a position being quiet and merely looking quiet. Pass considering with a move you are thinking of playing and it returns what that move actually walks into — a losing move is usually not in the top candidates, so asking about it directly is the only way to find out.

ParametersJSON Schema

Name	Required	Description
`fen`	No	FEN of the position.
`pgn`	No	PGN; the position after the final move is used.
`moves`	No	SAN moves from the start, e.g. ["e4","e5"].
`traps`	No	Also scan the captures and checks available to the side to move and return the ones that lose, each with its refutation. Slower — several extra searches.
`multipv`	No	How many candidate moves (1-5, default 3).
`considering`	No	A move you are thinking of playing, in SAN, e.g. "Ng5". Returns the evaluation after it and the line that refutes it.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable behavioral context: it explains that the tool reports what the opponent would play (distinguishing quiet positions), explicitly warns that the 'traps' parameter is slower due to extra searches, and clarifies that a losing move may not appear in top candidates, requiring the 'considering' parameter. This goes well 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 compact yet rich: the first sentence conveys primary functionality, the second covers input formats, the third introduces a key nuanced behavior, and the fourth explains the 'considering' parameter. Every sentence adds value with no redundancy, and critical details are front-loaded.

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?

Despite lacking an output schema, the description fully specifies what the tool returns (candidate moves, scores, checkable facts, opponent's response, refutation lines for 'considering'). It also covers all input formats, optional parameters, and performance trade-offs, leaving no critical gap for an agent to call it correctly.

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 description coverage is 100%, so all six parameters already have descriptive text in the schema. The description itself only elaborates on 'considering' and 'traps' behavior, but the schema already covers the rest. Per the baseline rule for high coverage, a score of 3 is appropriate because the description adds minimal extra beyond the schema.

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 verb ('Returns an engine evaluation'), a clear resource (a chess position), and enumerates the concrete outputs (candidate moves, scores, checkable facts). It distinguishes itself from siblings by focusing on engine evaluation and opponent responses, 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context, such as using the 'considering' parameter to evaluate a specific move when it might not appear in top candidates, and explains that 'traps' adds slower scans. However, it does not explicitly mention when not to use this tool or compare it with sibling tools like chess_review or chess_rig, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

chess_attacksWhat a piece attacksA

Read-only

Inspect

Returns the exact list of squares attacked by the piece standing on a given square in a chess position, together with that piece's type and colour. Returns an empty list when the square is unoccupied. Accepts a FEN, a PGN, or a list of SAN moves from the starting position.

ParametersJSON Schema

Name	Required	Description
`fen`	No	FEN of the position.
`pgn`	No	PGN; the position after the final move is used.
`moves`	No	SAN moves from the start, e.g. ["e4","e5"].
`square`	Yes	The square, e.g. "d5".

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true, and the description adds meaningful behavioral detail: unoccupied squares return an empty list, output includes piece type and colour, and the accepted position formats are disclosed. No contradiction with the read-only annotation exists.

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?

Two tightly written sentences front-load the core result and the key edge case, then list accepted input formats. Every sentence earns its place and there is no filler or redundant restatement of the tool name.

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 description is complete for a simple computation tool: it explains the return value and the empty-list case, which is especially important because there is no output schema. It names all three position input types, though it does not specify what happens if multiple position arguments are supplied or what the default starting position is.

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 description coverage is 100%, so the baseline is 3. The description adds context by naming FEN, PGN, and SAN moves as the position inputs and noting that SAN moves begin from the starting position. However, 'square' semantics are left to the schema's example, and the description does not significantly deepen parameter understanding.

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 opens with a specific verb—'Returns the exact list of squares attacked'—and names the resource: the piece standing on a given square. It also includes return details (piece type and colour) and edge-case behavior, making its purpose unmistakable and distinct from the broader chess_analyse and chess_review siblings.

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 implies usage: use this when you need the squares a particular piece attacks. It also states the accepted input formats (FEN, PGN, or SAN moves), which helps with input preparation. However, it never explicitly compares this tool to chess_analyse or chess_review, nor gives when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

chess_reviewReview a game for turning pointsA

Read-only

Inspect

Replays a finished game ply by ply with the engine and returns the moves where the evaluation swung by more than a threshold (default 1.5 pawns). Each entry gives the move number, the side that moved, the move played, the engine's preferred move, the size of the swing in pawns, the evaluation before and after, and the FEN of the resulting position. Accepts a PGN or a list of SAN moves, and can be filtered to one colour. Long games are truncated at 60 plies.

ParametersJSON Schema

Name	Required	Description
`pgn`	No	The finished game as PGN.
`moves`	No	Or SAN moves from the start.
`colour`	No	"white" or "black" — whose mistakes to report. Default both.
`threshold`	No	Swing in pawns that counts as a turning point. Default 1.5.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only declare readOnlyHint=true, and the description adds substantive behavior beyond that: engine replay, threshold default of 1.5 pawns, output fields per entry, supported inputs, colour filtering, and 60-ply truncation. These details make the tool's behavior predictable without contradicting the read-only annotation.

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 with no fluff. It front-loads the core purpose, then packs necessary operational details into the remaining sentences. Every 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?

With no output schema, the description takes on the burden of explaining return values, and it does: each entry's fields are enumerated. It also covers accepted inputs, configuration options, default behavior, and truncation, making the tool self-contained for an agent to use 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it clarifies that pgn and moves are alternatives ('or SAN moves'), explains the colour filter, and states the default threshold value of 1.5 pawns. This goes beyond what the schema alone provides.

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 uses a specific verb and resource: it replays a finished game and returns moves where the engine evaluation swung by a threshold. The 'turning points' concept clearly distinguishes this from the sibling tools chess_analyse and chess_attacks, even without naming them.

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 clear context for when to use the tool: after a game is finished, when you want engine-identified turning points based on evaluation swings. It mentions input options, colour filtering, and the 60-ply truncation, but it does not explicitly name alternatives or say when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

chess_rigThe live-coach page rigA

Read-only

Inspect

Returns the JavaScript source of the in-page coaching rig for a chess.com bot game, to be run in that page by the browser's javascript tool. Once running, the page exposes window.__coachWait(ms) (resolves with events and board status), window.__coachWatch.status() (moves, fen, turn, myTurn, result) and window.__coach (beginDraw, play, dashed, label, step, say) for drawing on the board. Also returns the rig version and the URL of the chess.com bot surface.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, and the description aligns by stating it 'Returns' source code rather than mutating state. It also goes beyond annotations by detailing the exposed API (window.__coachWait, window.__coachWatch.status, window.__coach) and noting it also returns the rig version and bot surface URL, giving a full picture of what the returned payload does when executed.

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 sentences pack essential information without fluff: the main return value, the runtime behavior, the exposed API details, and auxiliary return values. The most important claim is front-loaded ('Returns the JavaScript source'), and each subsequent detail earns its place by clarifying what the returned code provides.

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 read-only tool with no parameters and no output schema, the description fully equips an agent to invoke it correctly. It states the target context (chess.com bot game), how to use the returned source (run in page via javascript tool), what the source exposes, and what other data is returned (version and URL). Nothing necessary is missing.

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?

There are no parameters, so the baseline is 4. The description does not need to explain parameter semantics because none exist; the zero-parameter schema is fully covered by the absence of parameters.

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 identifies a specific verb ('Returns') and resource ('the JavaScript source of the in-page coaching rig for a chess.com bot game'), making the tool's purpose unmistakable. It also distinguishes itself from the sibling analysis tools by focusing on an in-browser rig rather than analysis or review.

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 context: the returned source is to be run in the chess.com bot game page via the browser's javascript tool. It implies the use case but does not explicitly contrast with alternative tools or state when not to use it. Still, the context is strong enough for an agent to select this tool when a live-coaching rig is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesSep 2, 2026

Changedchess_analyse1 field changed

addedInput schema / properties / traps

Added value: +{
+  "description": "Also scan the captures and checks available to the side to move and return the ones that lose, each with its refutation. Slower — several extra searches.",
+  "type": "boolean"
+}

Addedchess_rig

1 tool updateSep 2, 2026

Changedchess_analyse1 field changed

addedInput schema / properties / considering

Added value: +{
+  "description": "A move you are thinking of playing, in SAN, e.g. \"Ng5\". Returns the evaluation after it and the line that refutes it.",
+  "type": "string"
+}

3 tool updatesSep 1, 2026
- First observedchess_analyse
- First observedchess_attacks
- First observedchess_review

Related MCP Connectors

Teamfight Tactics MCP ServerOAuth
com.mr-bridge
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
Games & Gamification AI & Machine Learning
2
nexsusOAuth
io.github.dbnexsus
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Knowledge & Memory RAG Systems
2
Jade NoteOAuth
app.jadenote
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Note Taking Knowledge & Memory
2
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2

Related MCP Servers

gotham-browser
Browser Automation Web Scraping
gotham-os
F
license
Not graded
quality
B
maintenance
Enables Claude Code to control a real browser using AI for web scraping, competitive intelligence, and UX auditing through the MCP protocol.
Updated 3 months ago (2026-06-24 15:20 UTC)
-
AI Diagram Maker MCP Server
Software Architecture Developer Tools Data Visualization
erajasekar
A
license
A
quality
F
maintenance
MCP server for AI Diagram Maker — generate software engineering diagrams from natural language, code, ASCII diagram, images, or Mermaid. Inline diagram rendering using MCP apps UI and diagram URL in responses. Works with Cursor, Claude Desktop, Claude Code, and any MCP-compatible AI.
Updated 5 months ago (2026-05-04 04:45 UTC)
5
38 npm
9
MIT
Foundry VTT MCP Bridge
Games & Gamification Content Management Systems App Automation
adambdooley
F
license
Not graded
quality
A
maintenance
Connects Claude Desktop to Foundry VTT for AI-powered campaign management, enabling natural language interaction with game data including quest creation, character management, compendium searches, and dice rolling. Provides 20 MCP tools for seamless integration between Claude and your tabletop RPG sessions.
Updated 10 days ago (2026-09-12 15:21 UTC)
70
-
Controlium
Browser Automation Web Scraping
am-will
A
license
Not graded
quality
B
maintenance
Chrome extension + MCP bridge that gives Claude control over your real browser via CDP, enabling navigation, clicking, typing, scrolling, screenshots, and JS execution with a visible cursor and tab-bring-to-front.
Updated 2 months ago (2026-07-20 17:11 UTC)
1
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?