Chess.com 的已发布数据 API 的模型上下文协议(MCP) 服务器。
这使得可以通过标准化的 MCP 接口访问 Chess.com 玩家数据、游戏记录和其他公共信息，从而允许 AI 助手搜索和分析国际象棋信息。
https://github.com/user-attachments/assets/3b33361b-b604-465c-9f6a-3699b6907757
[x] 访问玩家资料、统计数据和游戏记录
[x] 按日期和玩家搜索游戏
[x] 检查玩家在线状态
[x] 获取有关俱乐部和冠军球员的信息
[x] 无需身份验证（使用 Chess.com 的公共 API）
[x] Docker 容器化支持
[x] 为AI助手提供交互工具
工具列表是可配置的，因此您可以选择要向 MCP 客户端提供的工具。
Related MCP server: Chess MCP Server
使用Claude Desktop运行 chess-mcp 最简单的方法是使用 Docker。如果你还没有安装 Docker，可以从Docker 的官方网站获取。
编辑您的 Claude Desktop 配置文件：
Mac： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows： %APPDATA%/Claude/claude_desktop_config.json
Linux： ~/.config/Claude/claude_desktop_config.json
然后添加如下配置：
{
"mcpServers": {
"chess": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"pab1it0/chess-mcp"
]
}
}
}或者，您可以直接使用 UV 运行服务器。编辑您的 Claude Desktop 配置文件（位置见上文）并添加服务器配置：
{
"mcpServers": {
"chess": {
"command": "uv",
"args": [
"--directory",
"<full path to chess-mcp directory>",
"run",
"src/chess_mcp/main.py"
]
}
}
}注意：如果您在Claude Desktop中看到
Error: spawn uv ENOENT，则可能需要指定uv的完整路径或在配置中设置环境变量NO_UV=1。
欢迎贡献代码！如果您有任何建议或改进，请提交 issue 或 pull request。
本项目使用uv来管理依赖项。请按照您平台的说明安装uv ：
curl -LsSf https://astral.sh/uv/install.sh | sh然后，您可以创建一个虚拟环境并使用以下命令安装依赖项：
uv venv
source .venv/bin/activate # On Unix/macOS
.venv\Scripts\activate # On Windows
uv pip install -e .该项目包括一个测试套件，可确保功能并有助于防止回归。
使用 pytest 运行测试：
# Install development dependencies
uv pip install -e ".[dev]"
# Run the tests
pytest
# Run with coverage report
pytest --cov=src --cov-report=term-missingget_player_profile - 从 Chess.com 获取玩家的个人资料
get_player_stats - 从 Chess.com 获取玩家的统计数据
is_player_online - 检查玩家当前是否在 Chess.com 上在线
get_titled_players - 从 Chess.com 获取有头衔的玩家列表
get_player_current_games - 获取 Chess.com 上玩家正在进行的游戏
get_player_games_by_month - 从 Chess.com 获取特定月份玩家的游戏
get_player_game_archives - 获取 Chess.com 上玩家可用的每月游戏档案列表
download_player_games_pgn - 从 Chess.com 下载特定月份所有游戏的 PGN 文件
get_club_profile - 获取 Chess.com 上某个俱乐部的信息
get_club_members - 获取 Chess.com 俱乐部的成员
麻省理工学院
Download PGN files for all games in a specific month from Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| year | Yes | ||
| month | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Download PGN files' but does not mention file size, rate limits, whether multiple files are bundled, or if the download is synchronous. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits essential information. While brevity is valued, it sacrifices completeness, making it under-specified rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and existence of an output schema, the description still falls short. It does not explain the output format (PGN bundle or single file), nor does it provide context about the tool's place among siblings. The description is minimally adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The tool description does not add any meaning beyond the parameter names (username, year, month). It fails to explain expected formats, ranges, or constraints (e.g., month 1-12, year range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Download PGN files' and the resource 'all games in a specific month from Chess.com'. It distinguishes from siblings like get_player_games_by_month by specifying the PGN format, but could be more explicit about how it differs from other game retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_player_games_by_month or get_player_game_archives. The description does not indicate prerequisites, limitations, or context for use, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get members of a club on Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| url_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Get members of a club', omitting key behavioral details like pagination, rate limits, or whether it returns all members.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices informativeness for brevity, providing insufficient detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (1 parameter) and existence of an output schema, the description fails to mention return value or usage context, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'url_id' is not explained in the description; schema coverage is 0%, so the description adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get members of a club on Chess.com' clearly identifies the verb (Get) and resource (members of a club), and distinguishes it from sibling tools like get_club_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_club_profile, or any context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a club on Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| url_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation ('Get information'), but fails to disclose any behavioral traits like required permissions, rate limits, or data scope beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise but lacks additional structuring or front-loading of key details. It is adequate but could benefit from expanding on the parameter and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return format is covered. However, given the tool has only one parameter and moderate complexity, the description provides minimal additional context about the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the meaning of the 'url_id' parameter (e.g., it is the club's URL identifier). This leaves the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets information about a club on Chess.com, with a specific verb and resource. It distinguishes from siblings like get_club_members which retrieves members, not profile info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_club_members. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's ongoing games on Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not explain what 'ongoing games' means (e.g., live vs daily), how long they persist, or what happens if the player has no ongoing games. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 11 words, but the brevity sacrifices necessary detail. It is appropriately front-loaded but lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description does not mention the output or its structure. The agent must infer return format from the output schema alone. Missing context about when results are empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'username' has no description in schema (0% coverage) and the tool description adds no additional meaning, format, or constraints. The agent receives no value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'a player's ongoing games', and the platform 'Chess.com'. It effectively distinguishes from sibling tools like 'get_player_games_by_month' which retrieve historical games.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_player_games_by_month' or 'download_player_games_pgn'. There are no prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of available monthly game archives for a player on Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states the action without mentioning authentication needs, rate limits, error handling, or any side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. However, it lacks structural elements like bullet points or sections for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description could rely on it, but it still omits context like what the list contains (e.g., dates, URLs) and how to proceed after retrieval. The description is too minimal for comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter 'username', and the tool description does not elaborate on its meaning or required format. The description adds no value beyond the schema itself for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'list of available monthly game archives', and the target 'a player on Chess.com'. It effectively differentiates from sibling tools like 'get_player_current_games' and 'get_player_games_by_month'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as 'get_player_games_by_month' or 'download_player_games_pgn'. There is no mention of suggested workflows or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's games for a specific month from Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| year | Yes | ||
| month | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It does not mention any authentication requirements, rate limits, or data freshness, leaving the agent without important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose with no redundant words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description does not need to detail return values. However, for a tool with 3 parameters and no parameter descriptions, the description is too minimal; it could include usage constraints (e.g., month range) to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds no parameter details beyond the schema field names. It does not explain valid ranges for year/month or username format, forcing reliance on the schema titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('player's games'), and the scope ('for a specific month from Chess.com'). It effectively distinguishes this tool from siblings like 'get_player_current_games' and 'get_player_game_archives'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic context for when to use this tool (to retrieve games for a given month), but lacks explicit guidance on when not to use it or how it differs from alternatives like 'download_player_games_pgn'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's profile from Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context beyond the action. It does not disclose authentication requirements, rate limits, or response characteristics, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient for a simple tool. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description covers the basic action. However, the lack of parameter details and behavioral context leaves gaps, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not elaborate on the 'username' parameter. No hints about format, case sensitivity, or valid values are given, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a player's profile from Chess.com', which is specific and distinguishes this tool from siblings like get_player_stats or get_player_game_archives. However, it does not elaborate on what constitutes a 'profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_player_stats). The description provides no context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's stats from Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, rate limits, or authentication requirements. The description is very brief and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) with no redundant words. However, its brevity sacrifices necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (not described), the description is incomplete. It fails to explain what kind of stats are returned, any limitations, or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage for parameter descriptions. The description does not mention the username parameter or provide any context about its format or meaning, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('player's stats'), providing a clear purpose. However, it does not distinguish this tool from siblings like get_player_profile or get_player_current_games, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of common use cases, prerequisites, or disclaimers about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of titled players from Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves a list but provides no details on behavior such as read-only nature, response structure, potential errors, or rate limits. The description is insufficient for an agent to understand the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short (one sentence), it omits critical information that would justify its brevity. Conciseness should not come at the cost of completeness; here, the agent is left guessing about parameter values and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema, the description could omit return details, but it still fails to explain the meaning of 'titled players', valid title values, or the default behavior of the tool. The minimum viable information required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has schema description coverage of 0%, and the tool description does not explain the 'title' parameter's valid values (e.g., 'GM', 'IM', 'FM', etc.) or its format. The agent has no information to correctly construct the parameter value beyond the schema's type constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of titled players from Chess.com', distinguishing it from sibling tools that focus on individual player data or game downloads. However, it does not explain what 'titled players' means, which could be ambiguous for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like download_player_games_pgn or get_player_profile. There is no mention of prerequisites, context, or conditions that would inform appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a player is currently online on Chess.com
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It indicates a read-only check but doesn't specify if authentication is needed, what 'online' means (e.g., currently active vs. recently seen), or rate limits. Adequate for a simple boolean but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. Front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple boolean output and presence of an output schema, the description is sufficient. It covers the essential action without needing more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no param descriptions), but the description adds no detail about the 'username' parameter (e.g., case sensitivity, format). The parameter is self-explanatory due to simplicity, but the description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'player is currently online on Chess.com', distinct from sibling tools like get_player_profile or get_player_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_player_current_games indicates activity). The description only states the function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0download_player_games_pgn1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "title": "Result",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "download_player_games_pgnOutput",
+ "type": "object"
+}get_club_members1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_club_membersOutput",
+ "type": "object"
+}get_club_profile1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_club_profileOutput",
+ "type": "object"
+}get_player_current_games1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_player_current_gamesOutput",
+ "type": "object"
+}get_player_game_archives1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_player_game_archivesOutput",
+ "type": "object"
+}get_player_games_by_month1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_player_games_by_monthOutput",
+ "type": "object"
+}get_player_profile1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_player_profileOutput",
+ "type": "object"
+}get_player_stats1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_player_statsOutput",
+ "type": "object"
+}get_titled_players1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "get_titled_playersOutput",
+ "type": "object"
+}is_player_online1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "result": {
+ "additionalProperties": true,
+ "title": "Result",
+ "type": "object"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "title": "is_player_onlineOutput",
+ "type": "object"
+}download_player_games_pgnget_club_membersget_club_profileget_player_current_gamesget_player_game_archivesget_player_games_by_monthget_player_profileget_player_statsget_titled_playersis_player_onlineScored across 10 tools
Each tool targets a distinct resource or action, such as downloading games, retrieving club info, or checking online status. There is no overlap or ambiguity between tool purposes.
All tool names follow a clear verb_noun pattern using underscores (e.g., get_player_profile, download_player_games_pgn). The verbs (download, get, is) and nouns are consistently structured.
With 10 tools, the set is well-scoped for a Chess.com data retrieval server. It covers player data, clubs, and utilities without being too sparse or overwhelming.
The tool surface covers core read operations for players, clubs, and games. Minor gaps exist, such as missing tools for live ratings or tournament data, but the set is largely complete for typical queries.
Chess.com MCP — wraps the Chess.com public API (free, no auth)
Lichess MCP — public read-only API for users, games, explorer, tablebase.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.