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
윈도우: %APPDATA%/Claude/claude_desktop_config.json
리눅스: ~/.config/Claude/claude_desktop_config.json
그런 다음 다음 구성을 추가합니다.
지엑스피1
또는 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설정해야 할 수 있습니다.
기여를 환영합니다! 제안이나 개선 사항이 있으시면 이슈를 개설하거나 풀 리퀘스트를 제출해 주세요.
이 프로젝트는 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에서 클럽 회원을 모집합니다
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.
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.