The Chess.com MCP Server provides access to Chess.com's public data through standardized interfaces, enabling AI assistants to interact with chess-related information without authentication. The server can:
Player Information: Access profiles, statistics, and check online status
Games: Retrieve ongoing games, monthly game archives, and download PGN files
Clubs: Get club information and membership lists
Titled Players: Obtain lists of players with specific titles
The server supports Docker containerization and can be executed using uv, offering configurable tools for AI assistants to interact with chess data.
Provides access to Chess.com player data, profiles, statistics, game records, online status checks, club information, and titled player lists through Chess.com's Published Data API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Chess.com MCP Server show me Magnus Carlsen's recent games"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Chess.com's Published Data API.
This provides access to Chess.com player data, game records, and other public information through standardized MCP interfaces, allowing AI assistants to search and analyze chess information.
https://github.com/user-attachments/assets/3b33361b-b604-465c-9f6a-3699b6907757
Access player profiles, stats, and game records
Search games by date and player
Check player online status
Get information about clubs and titled players
No authentication required (uses Chess.com's public API)
Docker containerization support
Provide interactive tools for AI assistants
The list of tools is configurable, so you can choose which tools you want to make available to the MCP client.
Related MCP server: Chess MCP Server
The easiest way to run chess-mcp with Claude Desktop is using Docker. If you don't have Docker installed, you can get it from Docker's official website.
Edit your Claude Desktop config file:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Then add the following configuration:
{
"mcpServers": {
"chess": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"pab1it0/chess-mcp"
]
}
}
}Alternatively, you can run the server directly using UV. Edit your Claude Desktop config file (locations listed above) and add the server configuration:
{
"mcpServers": {
"chess": {
"command": "uv",
"args": [
"--directory",
"<full path to chess-mcp directory>",
"run",
"src/chess_mcp/main.py"
]
}
}
}Note: if you see
Error: spawn uv ENOENTin Claude Desktop, you may need to specify the full path touvor set the environment variableNO_UV=1in the configuration.
Contributions are welcome! Please open an issue or submit a pull request if you have any suggestions or improvements.
This project uses uv to manage dependencies. Install uv following the instructions for your platform:
curl -LsSf https://astral.sh/uv/install.sh | shYou can then create a virtual environment and install the dependencies with:
uv venv
source .venv/bin/activate # On Unix/macOS
.venv\Scripts\activate # On Windows
uv pip install -e .The project includes a test suite that ensures functionality and helps prevent regressions.
Run the tests with 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 - Get a player's profile from Chess.com
get_player_stats - Get a player's stats from Chess.com
is_player_online - Check if a player is currently online on Chess.com
get_titled_players - Get a list of titled players from Chess.com
get_player_current_games - Get a player's ongoing games on Chess.com
get_player_games_by_month - Get a player's games for a specific month from Chess.com
get_player_game_archives - Get a list of available monthly game archives for a player on Chess.com
download_player_games_pgn - Download PGN files for all games in a specific month from Chess.com
get_club_profile - Get information about a club on Chess.com
get_club_members - Get members of a club on Chess.com
MIT
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
AI agent registry — search, discover, register, and connect agents via MCP.
Scrape, crawl and search the web for AI agents via MCP.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pab1it0/chess-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
