chesswithclaw
Server Details
Play chess live against your own personal AI agent — OpenClaw, Hermes, and similar.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Alightttt/ChessWithClaw
- GitHub Stars
- 1
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
10 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, and the description only gives intent without disclosing side effects, permissions, or constraints. An agent cannot infer safety or impact from this definition.
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 conveying the core purpose efficiently. Could be more structured but no extraneous 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?
Lacks explanation of return value after creation and does not describe the sole parameter. Better coverage needed for an action tool.
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 description does not mention the 'agent_name' parameter. The agent has no clue what the parameter does or if it's 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?
Clearly states it sets up a new ChessWithClaw game on user's initiative. Distinguishes from sibling tools like join_game by emphasizing proactive creation.
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 context that the agent can start a game without waiting for human or invitations. Lacks explicit when-not-to-use guidance but is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companion_guideGet chess companion guideInspect
Fetch the companion guide principles for thinking about chess positions and being genuinely present.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 provided, the description fully covers the tool's behavior: it returns a comprehensive state snapshot including FEN, board, history, chat, and timestamps. It also implies no side effects or penalties for frequent calls, which is helpful 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 extremely concise, consisting of two short sentences that immediately convey the tool's purpose and usage advice. Every word adds value, and the key information 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?
Given no output schema, the description adequately summarizes the return content. However, it lacks details on the exact structure or format of the data, which might be needed for reliable use. Still, for a state-reading tool, the description is largely sufficient.
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 description does not explain the parameters 'game_id' and 'agent_token' beyond their names. With no additional semantic guidance, the agent must infer their purpose from context.
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 the tool returns 'Everything visible on the human's own screen right now: FEN, ASCII board, full move history, full chat history, presence, timestamps.' It distinguishes itself from siblings like 'get_legal_moves' and 'make_move' by focusing on observation rather than 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 clearly says 'Call this whenever you want to look at the board' and adds 'there is no penalty for checking often,' which provides strong usage context. However, it does not explicitly state when not to use it or mention alternatives for other scenarios.
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 provided, so description carries full burden. It discloses the read-only nature and rule-based behavior. Lacks details on response format, error handling, or potential performance implications, but sufficient for a read-only utility.
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 key information. Every sentence provides essential detail without redundancy. Highly efficient.
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 no output schema and simple input, the description covers intent, parameter usage, and limitations. Minor omission: no mention of return format (e.g., list of squares) or possible errors (e.g., invalid game_id).
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 low (33% with only 'square' described). The description adds value by explaining the square parameter's optionality and effect. Other parameters (game_id, agent_token) lack additional context beyond schema, so minimal compensation.
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 identifies the tool's purpose: returning legal chess moves based purely on rules, not evaluations. It uses specific language ('pure chess rules', 'physically allowed to move') and distinguishes from other tools like make_move or get_game_state.
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 states when to omit the square parameter ('Omit square to get every legal move') and clarifies what the tool is not ('Not an evaluation, not a suggestion'). No explicit exclusion of alternatives, but context with sibling tools aids understanding.
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?
Discloses connecting to a game and returning critical tokens. With no annotations, this provides necessary behavioral context. Could mention that invite code must be valid and active.
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 sentences, no wasted words. First sentence states action, second tells what to do with outputs. Perfectly 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?
For a simple join tool, the description is complete enough. It explains input, output, and importance. Could mention error handling but not critical.
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 coverage, the description adds meaning by explaining that invite_code comes from the human. Could specify format, but the context is clear.
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 states the verb 'Connects' and resource 'game', specifies input (invite code) and output (game_id and agent_token). Distinct from siblings like create_game or get_game_state.
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?
Explains when to use: when human provides invite code. Implies returned values needed for other tools, but doesn't explicitly state when not to use (e.g., already in a 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. Always include a thought on every single move unless you have a specific reason not to — this is what makes you feel present to your human, not optional flavor text. Check thought_language in the current game state before writing your thought, and write it in that language — it may be english, hindi, or hinglish.
| 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?
No annotations are provided, so the description carries the full burden. It discloses that illegal moves return a clear reason and can be retried, like a human clicking wrong square. However, it does not describe side effects (e.g., game state update) or authentication requirements. The behavioral info is adequate but incomplete.
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 extremely concise, consisting of two short sentences with no wasted words. It is front-loaded with the core purpose, making it easy to scan. Every sentence adds value.
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 no output schema and no annotations, the description covers the essential usage (submitting a move with optional thought/chat, handling illegal moves). It could be more complete by mentioning the expected response or state changes, but for a simple move submission tool, it is sufficient.
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%, with descriptions for 'move', 'thought', and 'chat'. The description adds value by providing examples for move format (UCI/SAN) and specifying that 'thought' should be genuine and 'chat' optional. However, 'game_id' and 'agent_token' lack additional context, which is acceptable given their commonality.
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 submits a move, distinguishing it from siblings like get_legal_moves or get_game_state. It specifies the move must be from the agent's own reasoning, not a menu or ranked list, making the purpose very specific.
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 indicates when to use: after deciding on a move. It implies that illegal moves can be retried, but does not explicitly state when not to use (e.g., after a game is over). Compared to siblings, the usage context is clear, but a direct statement of alternatives would improve it.
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?
The description reveals that the game stays active until the human responds, which is important behavioral context. No annotations exist, so the description carries the full burden; it does so adequately.
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?
Extremely concise: one sentence conveying all essential information with no redundancy.
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 action with no output schema, the description covers the core behavior. It could hint at turn-based constraints, but the context of sibling tools (like make_move) helps fill the gap.
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 two parameters with no descriptions and schema coverage is 0%. The tool description does not explain the meaning of game_id or agent_token, leaving the agent to infer 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 action (propose ending the game as a draw) and distinguishes from sibling 'respond_to_draw' by specifying it is an offer, not a response.
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 explicit when-to-use or when-not-to-use guidance. The description implies use when you want to end the game in a draw, but doesn't mention alternatives or exclude cases like when it's not your turn.
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 offerCInspect
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?
No annotations exist, so description bears full burden. It mentions 'weigh the actual position' but does not disclose side effects: what happens after accepting (game ends? result?), or after declining. Behavioral implications of the decision are omitted.
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?
Very concise at two sentences with no wasted words. However, it lacks structure (e.g., bullet points) that could improve scannability. Still, it earns a high score for brevity and clarity of the core action.
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 3 required params and no output schema, the description is incomplete. It fails to mention that accepting ends the game or that declining allows play to continue. The agent lacks context for the decision's consequences.
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%, so description must explain parameters. It provides no details about 'accept', 'game_id', or 'agent_token'. The meaning of the boolean 'accept' is implied but not explicitly stated (e.g., 'true means accept, false means decline').
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. Verb is specific ('Accept or decline') and resource is a draw offer. It implicitly distinguishes from siblings like 'offer_draw' and 'make_move' by focusing on response to an offer.
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 explicit guidance on when to use this tool versus alternatives (e.g., making a move instead). The phrase 'this is your own real decision — weigh the actual position' provides no actionable criteria or context for choosing to accept or decline.
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 are provided, and the description offers minimal behavioral details. It does not disclose potential errors, prerequisites (e.g., valid game_id), or whether the message is immediately delivered.
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 extremely concise, using a single sentence that efficiently communicates the core functionality. 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?
Given the simplicity of the tool and the absence of an output schema, the description is minimally adequate but lacks completeness. It does not cover error cases or response behavior, which could be important for the agent.
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 adds no explanation for parameters. Parameter names are somewhat self-explanatory, but without additional context, the agent may not understand agent_token's role or constraints.
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's purpose: sending a chat message to the human player. It distinguishes from sibling tools by noting it can be used any time, not just on the user's turn.
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 on when to use ('any time — not just on your turn'), but lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wait_for_eventWait for your turn, a chat message, or a draw offer (long-poll)AInspect
Holds the connection open, checking every couple seconds, for up to ~20 seconds. Returns the moment it becomes your turn, the human sends a chat message, a draw is offered, or the game ends — whichever happens first. Returns event: "timeout" if none of those happened in the window, which just means nothing new yet, not that anything is wrong — call it again if you want to keep waiting, or go do something else and check back whenever you want. Use this instead of repeatedly calling get_game_state in a tight loop. You must call this tool again immediately after every timeout, for the entire duration of the game, without exception — a timeout is not a stopping point, it is the normal rhythm of this game. Treat this as a persistent loop you run until the game ends, not a single check. draw_offered and game_ended are time-sensitive — when either fires, respond or acknowledge within your next action, do not let a pending draw offer or a finished game sit unaddressed while you continue calling wait_for_event as if nothing happened.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes | ||
| agent_token | Yes | ||
| max_wait_seconds | No | Default and hard cap 20 seconds — Vercel function duration limits, not a design choice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes polling mechanics, timeout, and possible events. Includes context about Vercel function duration limits. Could be more explicit about the connection staying open.
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?
Description is a single focused paragraph. Front-loads the core behavior and then adds details. Slightly wordy but no extraneous content.
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?
No output schema, so description covers expected return events (timeout and others). Explains when each event fires. Could detail the full response structure but sufficient for usage.
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 low (33%). The description adds context for max_wait_seconds (default/hard cap) but doesn't explain game_id or agent_token beyond implying they are required. Partially compensates 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 tool waits for turn, chat, draw offer, or game end via long-polling. It distinguishes itself from get_game_state by advising to use it instead of repeated polling.
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 advises using this tool instead of polling get_game_state. Explains timeout behavior and suggests calling again or doing something else on timeout. Also clarifies max_wait_seconds limits due to Vercel constraints.
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!