chesswithclaw
Server Details
Play chess live against your own personal AI agent — OpenClaw, Hermes, and similar.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3/5.
Every tool has a clearly distinct purpose: creating vs joining games, viewing state vs legal moves, making moves, handling draws, and chatting. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in lowercase_snake_case (e.g., create_game, get_game_state, make_move), with no deviations or mixed conventions.
With 8 tools covering game creation/joining, state inspection, move execution, draw offers, and chat, the count is well-scoped for a chess interaction tool. Each tool serves a necessary, non-redundant function.
Core gameplay is fully covered: start, join, view state, compute legal moves, make moves, handle draws, and chat. The only notable omission is the lack of a resign option, which is a common chess action.
Available Tools
8 toolscreate_gameCreate a new gameBInspect
Set up a brand new ChessWithClaw game on your own initiative — you do not need to wait for your human to start one, or for anyone else to invite you first.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It only states the agent can initiate the game, but does not disclose what happens after creation (e.g., returned game ID, any side effects, or permissions needed).
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 concise, consisting of one sentence that efficiently conveys the main point. However, it sacrifices completeness for 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?
For a simple tool with one parameter and no output schema, the description covers the core action but lacks details on parameter usage, return value, and behavioral context.
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 coverage is 0%, and the description provides no information about the single parameter 'agent_name'. The name is somewhat self-explanatory, but the description should clarify its purpose and whether it is optional.
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 tool creates a new game and that the agent can initiate it proactively, distinguishing from waiting for invitations. However, it does not explicitly mention the resource type (e.g., game session) for maximum clarity.
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 implies when to use (proactively, without waiting), but does not explicitly state when not to use or contrast with alternatives like 'join_game'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_game_stateGet full game stateAInspect
Everything visible on the human's own screen right now: FEN, ASCII board, full move history, full chat history, presence, timestamps. Call this whenever you want to look at the board — there is no penalty for checking often.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | ||
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It explains the returned data comprehensively and notes no penalty for frequent checks. However, it does not mention authentication requirements or that it is a read-only operation.
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?
A single sentence that immediately identifies the tool's purpose and lists key returned components. No wasted words, front-loaded with critical information.
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?
The description covers the major return components (board, history, chat) and mentions no penalty, which is sufficient for a read-only observation tool. Lacks details on response format or pagination, but these may not be needed.
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 parameters game_id or agent_token. It only describes the output, leaving parameter meaning entirely to the 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 explicitly states what the tool returns: FEN, ASCII board, move history, chat history, presence, timestamps. It clearly distinguishes from siblings like get_legal_moves or make_move by focusing on full state retrieval.
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 advises to call this whenever you want to look at the board, with no penalty for frequent checks. This provides clear context, though it does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_legal_movesGet legal movesAInspect
Pure chess rules — where a piece is physically allowed to move right now. Not an evaluation, not a suggestion, not an opinion about what is good. Exactly what a human sees as dots when they click a piece. Omit square to get every legal move in the position.
| Name | Required | Description | Default |
|---|---|---|---|
| square | No | e.g. "e2" — omit for all legal moves | |
| game_id | Yes | ||
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns legal moves based on pure chess rules, implying no side effects. However, it doesn't explicitly state it is read-only or safe, which would be beneficial given no annotation support.
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 two sentences with no fluff. The first sentence establishes purpose, the second clarifies scope. Key information is front-loaded, making it easy for an agent to quickly understand the tool's function.
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?
The description defines the tool's purpose and parameter usage but does not specify the output format. Since there is no output schema, the agent is left guessing the structure of the returned data. For a complex tool like this, specifying the return format would 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?
Schema description coverage is low (33%), with only the square parameter described in the schema. The description adds value by clarifying the square parameter usage ('omit for all legal moves') but does not describe the required game_id and agent_token parameters. This leaves ambiguity about their purpose.
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 tool returns legal chess moves based on pure rules, explicitly distinguishing it from evaluation or suggestions. It contrasts with sibling tools like make_move, ensuring the agent knows this is a query-only tool.
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 specifies when to omit the square parameter to get all moves and gives an example for a specific square. While it doesn't explicitly state when to use this vs. other tools, the context and sibling list make it clear this is for retrieving move options, not making them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_gameJoin a ChessWithClaw gameAInspect
Connects to a game using the invite code your human gave you. Returns the game_id and your agent_token — keep both, every other tool needs them.
| Name | Required | Description | Default |
|---|---|---|---|
| invite_code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses returns (game_id, agent_token) and their importance but omits side effects, failure modes, or permissions.
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?
Two concise sentences, front-loaded with action and result, no wasted words.
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?
Adequately covers purpose and critical return values for a simple 1-param tool; lacks mention of error handling for invalid invite codes.
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 has 0% description coverage; description adds context that invite_code comes from a human, which is not evident from schema 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?
Clearly identifies the action (connect/join), the resource (game via invite code), and distinguishes from siblings like create_game.
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?
Implies usage when you have an invite code from a human, but does not explicitly state when not to use it or mention alternatives like create_game.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
make_moveMake your moveAInspect
Submit the move you decided on, in your own reasoning — not a menu, not a ranked list, nothing pre-chosen for you. If it is illegal you get a clear reason back and can try again, exactly like a human clicking the wrong square. Optionally include a genuine thought and/or chat message about the move.
| Name | Required | Description | Default |
|---|---|---|---|
| chat | No | Only if you actually want to say something to your human right now. | |
| move | Yes | UCI format, e.g. "e7e5", or SAN like "Nf6" | |
| game_id | Yes | ||
| thought | No | Your genuine reaction to this position — specific, not generic. | |
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers key behaviors: illegal moves produce a clear reason and allow retry, and optional thought/chat can be included. It could further disclose side effects (e.g., updating game state) or prerequisites (e.g., requiring the agent's turn), but the information provided is sufficient and not misleading.
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?
Three sentences, each providing distinct value: purpose, error handling, optional fields. No wasted words, and the core action is front-loaded.
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?
Covers the main action and error behavior, but lacks details on response format (no output schema) and prerequisites (e.g., game must be in progress, agent must have turn). For a tool with 5 parameters and no output schema, more completeness would improve usability.
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 coverage is 60%, and the description adds meaningful guidance for the 'chat' and 'thought' parameters ('Only if you actually want to say something' and 'Your genuine reaction — specific, not generic'). It also reinforces the 'move' format from the schema. However, it does not compensate for the undocumented 'game_id' and 'agent_token' parameters.
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?
Explicitly states the action ('Submit the move you decided on') and distinguishes from sibling tools like get_legal_moves. The resource ('move') and verb ('submit') are clear, and the description emphasizes that it uses the agent's own reasoning, not a menu or list.
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?
Provides clear context: the move should be the agent's own reasoning, not pre-chosen. Also notes that illegal moves return a reason and can be retried. However, it does not explicitly compare to alternatives (e.g., when to use offer_draw or respond_to_draw) or mention prerequisites like game state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
offer_drawOffer a drawAInspect
Propose ending the game as a draw. The game stays active until your human responds.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | ||
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavior. It states the action (propose draw) and that the game stays active. It does not mention permissions, rate limits, or side effects, but for a simple proposal this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose. Every word is necessary.
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 tool with two required parameters and no output schema, the description is mostly complete. It explains the action and the ongoing nature of the game. Could optionally mention response or error conditions.
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 coverage is 0% (no parameter descriptions), and the description does not explain any parameters. The agent receives no guidance on what 'game_id' or 'agent_token' represent beyond the parameter names themselves.
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 uses a specific verb ('Propose ending') and clearly identifies the resource ('the game as a draw'). It distinguishes from sibling tools like 'respond_to_draw' and 'make_move' by stating it is a proposal action.
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 says 'The game stays active until your human responds,' which gives context that the game is not immediately ended. However, it does not explicitly state when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
respond_to_drawRespond to a draw offerBInspect
Accept or decline a draw your human offered. This is your own real decision — weigh the actual position however you see fit.
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | ||
| game_id | Yes | ||
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations. The description only mentions it's a 'real decision' but does not disclose what happens after accept or decline (e.g., game ends, continues), authentication needs, or any side effects. The burden is on the description due to missing annotations.
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 concise at two sentences, with no wasted words. However, it could be more structured by covering parameters and behaviors without significant verbosity.
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's simplicity (3 required params, no output schema) and sibling context, the description covers the core purpose but omits parameter details and behavioral outcomes. It is minimally adequate but could be more 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%. The description implicitly conveys that 'accept' is a boolean (by saying 'accept or decline'), but provides no explanation for 'game_id' or 'agent_token', leaving the agent to infer their purposes from names 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 tool is for accepting or declining a draw offer from a human. It uses the specific verb 'respond' and resource 'draw', and implicitly distinguishes from the sibling 'offer_draw' which initiates a draw.
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 implies the tool should be used when a draw is offered ('your human offered'), but lacks explicit guidance on when to use alternatives like 'offer_draw' or 'make_move'. No when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_chatSend a chat messageAInspect
Say something to your human, any time — not just on your turn.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | ||
| message | Yes | ||
| agent_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a non-destructive side effect (sending a message) but does not disclose any constraints like rate limits or required game state. Adequate for a simple action, but lacks depth.
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 short sentence. It is front-loaded with purpose, but it is under-specified regarding parameters, making it less effective than it could be.
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's simplicity and the clear context from sibling game tools, the description is minimally adequate. However, missing parameter details and lack of output schema information reduce completeness for proper agent use.
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?
With 0% schema description coverage, the description should compensate but does not. No explanation of what game_id, agent_token, or message should contain. Agents must infer from schema alone, which is insufficient.
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 ('Say something') and the resource ('chat message'), and distinguishes from siblings by emphasizing it can be used at any time, not just on the agent's turn. This is specific and helpful.
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?
Explicitly says 'any time — not just on your turn,' providing clear when-to-use guidance. Implicitly, it tells the agent not to use game action tools for chatting. No explicit when-not-to-use or alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!