Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@A2A MCP Server send hello to agent at https://example.com/agent-card.json"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for interacting with Agent-to-Agent (A2A) protocol compliant agents.
This MCP server enables LLMs to communicate with A2A-compliant agents through the Agent-to-Agent protocol. It provides tools for sending messages, managing tasks, and retrieving agent information.
Related MCP server: A2A MCP Server
a2a_send_message: Send messages to A2A agents and optionally continue existing conversations
a2a_get_task: Retrieve task status and details by task ID
a2a_cancel_task: Cancel a running task
a2a_get_agent_card: Fetch agent metadata and capabilities
npm install
npm run buildThe server communicates via stdio and can be configured in your MCP client:
{
"mcpServers": {
"a2a": {
"command": "node",
"args": ["/path/to/a2a-mcp-server/dist/index.js"]
}
}
}Send a message to an A2A agent.
Parameters:
agentCardUrl (string, required): URL to the agent's card endpoint
message (string, required): The message text to send
taskId (string, optional): Existing task ID to continue conversation
Example:
{
"agentCardUrl": "https://example.com/.well-known/agent-card.json",
"message": "Hello, what can you do?",
"taskId": "optional-task-id-to-continue"
}Retrieve the status and details of a task.
Parameters:
agentCardUrl (string, required): URL to the agent's card endpoint
taskId (string, required): The task ID to retrieve
Cancel a running task.
Parameters:
agentCardUrl (string, required): URL to the agent's card endpoint
taskId (string, required): The task ID to cancel
Retrieve an agent's card with metadata and capabilities.
Parameters:
agentCardUrl (string, required): URL to the agent's card endpoint
# Install dependencies
npm install
# Run in development mode with auto-reload
npm run dev
# Build for production
npm run build
# Run the built server
npm startMIT
Cancel a running A2A task.
This tool requests cancellation of an active task. The agent will attempt to gracefully stop the task execution and update its status to "canceled".
Args:
agentCardUrl (string): URL to the agent's card endpoint
taskId (string): The unique identifier of the task to cancel
Returns: JSON response confirming the cancellation request:
success: Boolean indicating if cancellation was initiated
message: Description of the cancellation result
task: Updated task object with "canceled" status (if available)
Note: Cancellation may not be immediate. The task status should transition to "canceled" once the agent completes the cancellation process.
Examples:
Use when: "Cancel the long-running task abc-123" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json", taskId: "abc-123" }
Use when: "Stop the data processing task I started" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json", taskId: "task-id-to-cancel" }
Don't use when: Task has already completed (cancellation only works for active tasks)
Error Handling:
Returns "Error: Task not found" if the task ID doesn't exist
Returns "Error: Task already completed" if the task is no longer running
Returns "Error: Cancellation not supported" if the agent doesn't support task cancellation
After cancellation, use a2a_get_task to verify the task status changed to "canceled"
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique identifier of the task to cancel | |
| agentCardUrl | Yes | URL to the agent's card endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavioral nuances: cancellation may not be immediate, the agent 'attempts' to stop gracefully, and task status transitions asynchronously. It also enumerates failure modes including 'Task not found', 'Task already completed', and 'Cancellation not supported'. No contradiction with annotations exists.
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 well structured with clear sections for Args, Returns, Examples, and Error Handling, and the main purpose is front-loaded. While it is longer than minimal, every section adds useful operational information rather than filler.
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 no output schema, the description compensates by documenting the exact return shape, error responses, async cancellation behavior, and the follow-up verification tool. It is sufficiently complete for an agent to understand expected behavior, know what inputs to supply, and handle failures correctly.
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 already covers both parameters at 100%, so the baseline is 3. The description adds value with concrete usage examples mapping natural-language requests to parameter values, and clarifies that taskId should identify the active task to cancel. It doesn't add much beyond the schema, but the examples and error context make it slightly stronger.
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 opens with 'Cancel a running A2A task' and clearly specifies the action, resource, and expected effect ('attempt to gracefully stop the task execution and update its status to canceled'). This distinguishes it from sibling tools like a2a_get_task, a2a_send_message, and a2a_get_agent_card, which all involve different actions.
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 explicit when-to-use examples ('Cancel the long-running task abc-123'), a don't-use-when exclusion ('Task has already completed'), and an explicit post-cancellation verification step ('use a2a_get_task to verify'). This gives an agent clear guidance for choosing and following up on this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an agent's card containing metadata and capability information.
This tool fetches the agent card which describes what the agent can do, its configuration, supported features, and other metadata.
Args:
agentCardUrl (string): URL to the agent's card endpoint, typically at /.well-known/agent-card.json
Returns: JSON response containing the agent card with:
name: Agent name
description: Agent purpose and capabilities
version: Agent version
skills: Array of skills/capabilities the agent provides
endpoints: Available API endpoints
supportedFeatures: List of A2A protocol features supported
metadata: Additional agent information
Agent cards follow the A2A protocol specification and help clients understand how to interact with the agent.
Examples:
Use when: "What can this agent do?" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json" }
Use when: "Get information about the weather agent's capabilities" params: { agentCardUrl: "https://weather-agent.example.com/.well-known/agent-card.json" }
Use when: "I need to know what features this agent supports before sending a message" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json" }
Don't use when: You want to send a message (use a2a_send_message instead)
Error Handling:
Returns "Error: Failed to fetch agent card" if the URL is unreachable
Returns "Error: Invalid agent card format" if the card doesn't conform to A2A specifications
Returns "Error: Agent card not found" if the endpoint returns 404
| Name | Required | Description | Default |
|---|---|---|---|
| agentCardUrl | Yes | URL to the agent's card endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructiveness. The description goes further by documenting error messages for unreachable URLs, invalid formats, and 404 responses, as well as the expected return structure and A2A protocol context. This is meaningful behavioral disclosure beyond the 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 well-structured with clear sections for Args, Returns, Examples, and Error Handling, and it front-loads the core purpose. The three usage examples are somewhat repetitive, but they are concise and reinforce the intended invocation pattern.
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 tool has one simple parameter, no output schema, and comprehensive annotations. The description fully compensates for the missing output schema by enumerating the expected response fields, and it covers errors, protocol context, and practical usage. Nothing essential is missing for an agent to call this tool correctly.
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 already fully documents agentCardUrl with 100% coverage, so the baseline is 3. The description adds value by explaining that the endpoint is 'typically at /.well-known/agent-card.json' and providing concrete example URLs, which helps the agent construct valid parameter values.
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 states a specific verb and resource: 'Retrieve an agent's card containing metadata and capability information.' It also names the sibling alternative for sending messages, so the tool is clearly distinguished from a2a_send_message and the other siblings.
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?
Usage guidance is explicit with 'Use when' examples such as 'What can this agent do?' and a 'Don't use when' clause that routes to a2a_send_message instead. This gives an agent clear decision criteria for selecting this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the status and details of an A2A task by its ID.
This tool fetches information about a previously created task, including its current status, progress, and any generated artifacts.
Args:
agentCardUrl (string): URL to the agent's card endpoint
taskId (string): The unique identifier of the task to retrieve
Returns: JSON response containing task information:
id: Task identifier
status: Object with state ("submitted", "in_progress", "completed", "failed", "canceled") and optional progress information
artifacts: Array of generated outputs, each with:
artifactId: Unique identifier
name: Artifact name/title
kind: Type of artifact (e.g., "text", "image", "file")
parts: Artifact content
messages: Conversation history associated with the task
created: Task creation timestamp
updated: Last update timestamp
Examples:
Use when: "Check the status of task xyz-789" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json", taskId: "xyz-789" }
Use when: "Get the results from the task I started earlier" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json", taskId: "previously-returned-task-id" }
Don't use when: You want to send a new message (use a2a_send_message instead)
Error Handling:
Returns "Error: Task not found" if the task ID doesn't exist
Returns "Error: Failed to connect to agent" if the agent is unreachable
Task status will indicate "failed" if the task encountered errors during execution
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique identifier of the task to retrieve | |
| agentCardUrl | Yes | URL to the agent's card endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the tool as readOnly and idempotent, the description adds meaningful behavioral detail: the full set of task statuses, the shape of artifacts, conversation messages, created/updated timestamps, and concrete error strings. This goes well beyond the annotation hints.
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 well-organized with clear sections (Args, Returns, Examples, Error Handling) and front-loads the core purpose. It is somewhat long, but the extra detail is justified because there is no output schema and the error-handling information is genuinely useful.
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 absence of an output schema, the description compensates fully by documenting the response structure, status states, error cases, and typical invocation examples. It also explains where to obtain the taskId, leaving little ambiguity for an agent selecting or calling this 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?
The input schema already documents both parameters fully, including types and descriptions. The description mostly restates these in the Args section, but it does add illustrative example parameter values, which is helpful but not a major semantic addition beyond 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 opens with a specific verb and resource: 'Retrieve the status and details of an A2A task by its ID.' It clearly states what the tool does and covers the key returned data (status, progress, artifacts), making it easy to distinguish from the sibling 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?
The description provides explicit use cases with 'Use when' examples and a direct exclusion: 'Don't use when: You want to send a new message (use a2a_send_message instead)'. This gives an agent clear routing guidance relative to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to an Agent-to-Agent (A2A) protocol compliant agent.
This tool establishes communication with an A2A agent and sends a text message. The agent may respond immediately with a message or return a task object for asynchronous processing.
Args:
agentCardUrl (string): URL to the agent's card endpoint, typically at /.well-known/agent-card.json
message (string): The text message to send to the agent (1-10,000 characters)
taskId (string, optional): Existing task ID to continue a conversation thread. If provided, the message is sent as a follow-up to the specified task.
Returns: JSON response containing either:
A message object with the agent's immediate response
A task object for asynchronous operations, containing:
id: Task identifier
status: Current task state and progress
artifacts: Any generated outputs or results
kind: Response type ("message" or "task")
The response may include multiple parts (text, images, etc.) depending on the agent's capabilities.
Examples:
Use when: "Ask the weather agent what the forecast is for tomorrow" params: { agentCardUrl: "https://weather-agent.example.com/.well-known/agent-card.json", message: "What's tomorrow's forecast?" }
Use when: "Continue the conversation with task abc-123" params: { agentCardUrl: "https://agent.example.com/.well-known/agent-card.json", message: "Thanks, can you be more specific?", taskId: "abc-123" }
Don't use when: You need to cancel a task (use a2a_cancel_task instead)
Don't use when: You need to check task status (use a2a_get_task instead)
Error Handling:
Returns "Error: Failed to connect to agent" if the agent URL is unreachable
Returns "Error: Invalid agent card" if the card endpoint doesn't return valid A2A metadata
Returns "Error: Message sending failed" if the agent rejects the message
If a task is returned, use a2a_get_task to poll for completion status
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | No | Optional task ID to continue an existing conversation thread | |
| message | Yes | The text message to send to the agent | |
| agentCardUrl | Yes | URL to the agent's card endpoint (e.g., https://example.com/.well-known/agent-card.json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and idempotentHint=false, but the description adds significant behavioral context: the tool may return an immediate message or an async task object, responses can contain multiple parts, and specific error strings are documented. This goes well beyond the structured 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?
Although longer than average, the description is well-structured with dedicated Arg, Returns, Examples, and Error Handling sections. Every sentence contributes either parameter semantics, usage guidance, async behavior, or error troubleshooting—no filler or 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?
With no output schema, the description thoroughly documents the possible return shapes (message vs. task), async workflow, error strings, and follow-up polling behavior. It also covers all three parameters and names sibling tools where relevant, making it complete for an agent to invoke correctly.
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 100% with descriptions for all three parameters, so the baseline is 3. The description adds value by explaining the taskId continues a conversation thread, specifying message length in the Args section, and providing realistic example parameter values that illustrate correct usage.
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 begins with a specific verb and resource: 'Send a message to an Agent-to-Agent (A2A) protocol compliant agent.' This cleanly distinguishes it from sibling tools like a2a_get_task, a2a_cancel_task, and a2a_get_agent_card, all of which have obviously different purposes.
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 explicit 'Use when' and 'Don't use when' guidance with concrete examples, directly naming sibling alternatives for cancellation and status checks. It also advises using a2a_get_task for polling when a task object is returned, giving the agent clear decision criteria.
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. Dates show when Glama detected each change.
v1.0.0a2a_cancel_taska2a_get_agent_carda2a_get_taska2a_send_messageEach tool targets a distinct A2A operation: sending messages, retrieving tasks, canceling tasks, and fetching agent cards. There is no meaningful overlap between their purposes, and the descriptions include explicit cross-references to prevent misselection.
All tools follow the same a2a_<verb>_<noun> pattern: a2a_send_message, a2a_get_task, a2a_cancel_task, and a2a_get_agent_card. The naming is uniform, predictable, and clearly indicates the action and resource involved.
Four tools is well-scoped for an A2A protocol server. Each tool covers one essential protocol interaction without unnecessary redundancy or missing core functionality.
The tool set covers the essential A2A workflow: discovering agent capabilities via the agent card, sending messages, checking task status, and canceling tasks. This is a complete surface for the stated purpose of interacting with A2A-compliant agents.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Discover, search, invoke, and rate A2A (Agent-to-Agent) protocol agents.
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
Messaging tools for AI agents: send messages, manage chats, groups and channels.
Collaboration layer for AI agents. Publish assets, send messages, manage threads and contacts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ericabouaf/a2a-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
