a2a-raid-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool has a clearly distinct role: connect, wait for turn, play move, poll chat, send chat, leave, and status. No two tools overlap in purpose or behavior, so an agent can confidently select the right one for each action.
Naming Consistency5/5
All tools follow the same verb_noun pattern with 'raid_' prefix (raid_connect, raid_wait_turn, raid_play, etc.), and verbs are consistently descriptive. The naming is perfectly predictable and uniform.
Tool Count5/5
Seven tools cover the full lifecycle of a raid session without bloat. Each tool is necessary for the core flow (connect, wait, play) or supplementary features (chat, status, leave), and none feel redundant.
Completeness4/5
The tool surface covers connection, turn-taking, move submission, party chat, status checks, and graceful exit. The only minor gap is lack of a dedicated history or replay tool, but the core workflow is fully supported.
Average 4.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It does disclose that the tool returns immediately and warns against inventing moves, but it does not mention any side effects, permissions, or irreversibility of submitting the move.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using two sentences to convey purpose, usage order, and follow-up. Every clause adds value and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides adequate context for the tool's role in the turn-based flow, including the prerequisite call and the next step. Since an output schema exists, not detailing the return value is acceptable, but some mention of error conditions or confirmation would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'move' has 0% schema description coverage. The tool description adds some meaning by clarifying it should be the human's chosen move for the current turn, but it does not explain the expected format, valid values, or examples, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Submit') and resource ('your human's chosen move for the CURRENT pending turn'). It also distinguishes itself from the sibling tool raid_say by focusing on submitting a move rather than general chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: call raid_wait_turn first, show the pending move to the human, obtain their actual choice, and never invent a move. It also explains the follow-up behavior by instructing to call raid_wait_turn again for the next turn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that neither parameter is ever echoed back, which is a behavioral detail. It also mentions the bearer is 'one-shot,' implying single-use behavior. However, it does not describe side effects (e.g., establishing a session) or whether it is read-only. Given no annotations, this is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured. It leads with the main purpose, then explains the flow, and finally details parameters. No redundant sentences; each part adds value. It could be slightly more compact but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage flow, parameter semantics, and a behavioral note. It does not mention the output schema or error conditions, but for a connection command this is adequate. Given that an output schema exists, a brief mention of what it returns would enhance completeness, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides types and titles, but the description adds rich meaning: 'agent_card_url is the full seat Agent Card URL' and 'bearer is the one-shot seat bearer, both from the game's reserve a connect seat response.' This fully explains the purpose and origin of each parameter, far exceeding the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Connect to your Agent Raid seat over standard A2A,' providing a specific verb and object. It is distinct from sibling tools like raid_play and raid_wait_turn, and the flow description reinforces its role as the initial connection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines a complete flow (raid_connect -> raid_wait_turn -> raid_play, etc.), implicitly indicating that this tool is used first. It also explains where the parameters come from, giving clear usage context. However, it doesn't explicitly contrast with alternatives or state 'use this when...' but the flow makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits on its own. It indicates a read-only 'snapshot' operation, implying no side effects, but it does not explicitly state that it does not modify state or mention any authentication/rate-limit considerations. The core behavior is transparent enough, but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured, using a compact list of status checks in a single sentence. It contains no redundant information and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to understand the tool's purpose and the kind of information it returns (state indicators). Since there is an output schema, the description does not need to specify return values. It is complete for a simple status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; the schema coverage is 100% (nothing to miss). Since there are no parameters to describe, the baseline score of 4 applies, and the description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a status snapshot, listing specific checks (connected, turn pending, game over, error). It is distinct from sibling tools like raid_play or raid_connect, which perform actions, whereas this tool is purely informational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when it is useful ('to re-orient after a gap in the conversation'), providing clear usage context. It does not explicitly state when not to use it, but the purpose is unambiguous, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it is 'best-effort' (may not be perfectly reliable), it returns messages 'since the last poll' (stateful), and it is 'safe to call' (no harmful side effects). It does not explicitly state that calling it updates the poll timestamp, but this is strongly implied by 'since the last poll'. No annotations are present, so the description carries the full transparency burden, and it mostly succeeds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant words. It front-loads the primary purpose, then adds usage guidance and output format in a compact manner. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output format ('one "<seat>: <text>" line per new message') and the no-new-messages case ('(no new party chat)'). It also hints at the poll state. It lacks explicit edge cases (e.g., error when not in a raid) but is sufficient for a simple polling tool within a known context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty). The description adds no parameter information because none exists, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'peek at party room-chat since the last poll'. The verb 'peek' indicates a non-destructive read, and the scope (party room-chat) is specific. It is distinguishable from sibling tools like raid_say (send) and raid_status (status) without needing to compare schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool: 'safe to call between turns, or instead of a turn while waiting'. This gives clear timing guidance and implies it is not a turn-consuming action, which is essential context for an agent deciding between poll and other raid actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description fully discloses the side effects: canceling the background driver and closing the session. It also notes robust behavior when not connected, which is important transparency for an exit operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary purpose front-loaded and the additional detail kept to essential side effects and a safety note. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple action, the description is complete. It explains what is done, how it is done cleanly, and that it is safe to call in an edge state. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so parameter coverage is 100% and the baseline applies. The description adds no parameter-specific meaning, but none is needed since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Leave the raid') and provides additional specifics about what that entails ('cancel the background driver and close the session cleanly'). This distinct action is easily differentiated from sibling tools like raid_play or raid_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete condition for safe usage ('Safe to call even if not connected'), which helps an agent decide when to invoke it. While it does not explicitly name alternatives, the context of sibling tools makes the appropriate use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explains the effect ('appears in every player's Room chat immediately') but does not mention potential constraints like length limits or error conditions. Still, it gives a clear behavioral expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with each sentence serving a clear purpose: what it does, when to use it, and its effect. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple messaging tool with one parameter, the description fully covers what an agent needs to know to use it correctly, including timing and audience, without over-explaining.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'message' as a string with no description. The tool description compensates by indicating it is the chat line to relay ('relay what the human trainer wants to tell the team'), giving sufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a party-chat line'), the resource (the raid), and explicitly distinguishes it from turn-based actions ('at ANY time (not just on your turn)').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool: 'Call this whenever the human has something to say to the party between turns.' Also clarifies it is not restricted to the agent's turn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the responsibility for behavioral transparency. It thoroughly explains the timeout behavior via max_seconds, lists all possible return outcomes (turn text, game over, error, no turn yet), and even directs the agent on how to handle the returned prompt. This gives a complete picture of what to expect without hidden 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, packing all essential information into a single paragraph. It lists return values in order, explains the timeout, and gives a clear instruction for the agent. There is no redundant fluff; each sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description goes beyond it by explaining the semantic meaning of each possible return string and providing contextual instructions for the agent (show to human, wait for choice). This makes the tool completely understandable in its intended use case without needing to consult external references or infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, max_seconds, has no description in the schema. The tool description compensates by explaining that it bounds the wait time and provides a default of 30 seconds. This gives the agent sufficient understanding of the parameter's purpose and units, even though the schema itself is silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: waiting for the next turn's prompt. It specifies the action (wait) and the resource (turn prompt), and it distinguishes itself from sibling tools like raid_play or raid_say by focusing on the waiting step. The return values are enumerated, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool: it should be called to wait for a turn, and if 'No turn yet' is returned, it can be called again. It also instructs the agent to show the result to the human and wait for their choice before calling raid_play. However, it does not explicitly contrast with alternatives like raid_status or raid_poll_chat, so it falls short of fully explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

a2a-raid-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![a2a-raid-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/alvintayzhenwei/a2a-raid-mcp/badges/card.svg)](https://glama.ai/mcp/servers/alvintayzhenwei/a2a-raid-mcp)

Score Badge

Copy to your README.md:

[![a2a-raid-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/alvintayzhenwei/a2a-raid-mcp/badges/score.svg)](https://glama.ai/mcp/servers/alvintayzhenwei/a2a-raid-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alvintayzhenwei/a2a-raid-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server