How do I use a2a-mcp-bridge?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@a2a-mcp-bridge Get the agent card from the A2A agent" 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.

a2a-mcp-bridge

by ytugarev

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

a2a-mcp-bridge

A minimal MCP server that bridges MCP clients (Claude Desktop, etc.) to A2A agents — built directly on a2a-sdk 0.3.26+, so it speaks the A2A protocol version that current agent servers (e.g. Google ADK's to_a2a) actually implement.

Stateless by design: no registry file, no local persistence, nothing written to disk. Each call opens a connection, does the round trip, and returns — so it never hits the file-permission traps that registry/cache-based bridges run into on locked-down or sandboxed clients.

Why this exists

The most visible community bridge, PyPI's a2a-mcp-server, does not depend on a2a-sdk at all — it vendors a hand-copied client from the pre-1.0 draft A2A protocol. Its hardcoded JSON-RPC methods are tasks/send, tasks/sendSubscribe, tasks/get, tasks/cancel, tasks/pushNotification/{get,set}.

Current a2a-sdk (0.3.26+) servers use a different method set entirely: message/send, message/stream, tasks/get, tasks/cancel, tasks/pushNotificationConfig/{get,set,list,delete}, tasks/resubscribe, agent/getAuthenticatedExtendedCard.

Point the old bridge at a modern A2A server and every call fails with -32601 Method not found — the server has genuinely never heard of tasks/send. This isn't a version skew you can fix by bumping a pin; the dialect changed. a2a-mcp-bridge sidesteps the problem by using a2a-sdk's own client (ClientFactory, send_message), so it always speaks whatever protocol the SDK you install implements.

Related MCP server: ACP-MCP-Server

Install

Option A — uvx, no clone, no install:

uvx --from git+https://github.com/ytugarev/a2a-mcp-bridge a2a-mcp-bridge

Option B — pip, from source:

git clone https://github.com/ytugarev/a2a-mcp-bridge
cd a2a-mcp-bridge
pip install -e .

Option C — single file, zero install: src/a2a_mcp_bridge/server.py carries a PEP 723 inline metadata header, so you can download that one file and run it directly with uv — uv resolves and caches its dependencies on first launch, no pip install and no venv to manage:

uv run --script /absolute/path/to/server.py

Configure

Two environment variables, both optional:

Variable	Default	Purpose
`A2A_AGENT_URL`	`http://localhost:8001`	Default A2A agent endpoint (also overridable per tool call)
`A2A_TIMEOUT_SECONDS`	`300`	HTTP client timeout — raise this for slow/long-running agents
`A2A_HEARTBEAT_SECONDS`	`15`	Interval between MCP progress notifications while a task runs

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "a2a-bridge": {
      "command": "a2a-mcp-bridge",
      "env": {
        "A2A_AGENT_URL": "http://192.168.1.50:8001"
      }
    }
  }
}

Using the single-file uv run --script form instead (Option C above):

{
  "mcpServers": {
    "a2a-bridge": {
      "command": "/absolute/path/to/uv",
      "args": ["run", "--script", "/absolute/path/to/server.py"],
      "env": {
        "A2A_AGENT_URL": "http://192.168.1.50:8001"
      }
    }
  }
}

Both command and every path in args must be absolute. MCP clients launch server subprocesses with the working directory set to some system default (on Windows, Claude Desktop uses C:\WINDOWS\System32) and often a stripped PATH, so a bare "uv" or a relative "server.py" will silently fail to resolve — this is the single most common setup error with this bridge (and MCP servers in general), not a bug in the bridge itself. On Windows, also double check your actual config path: Store-installed Claude Desktop keeps it under AppData\Local\Packages\<package-id>\LocalCache\Roaming\Claude\, not the %APPDATA%\Claude path most docs assume.

Tools exposed

get_agent_card(agent_url?) — fetches the target agent's name, description, and skills from its /.well-known/agent-card.json card.
send_a2a_message(message, agent_url?, task_id?, context_id?) — sends a message to the agent and returns its final text response. Uses A2A streaming internally when the agent supports it (falling back to a blocking send otherwise), but still returns one clean answer per call.
get_a2a_task(task_id, agent_url?) — fetches the current state and result of a previously started task. The escape hatch for calls that timed out after the task had already started: the task keeps running server-side, and the timeout error names the task_id to check on.

All tools accept an optional agent_url override, so a single bridge instance can talk to multiple agents if needed.

Multi-turn conversations

Every send_a2a_message response ends with an ids footer:

[a2a task_id=... context_id=...]

Passing those ids back as task_id / context_id on the next call continues the same task — which is how you answer a [task input-required] follow-up question from the agent. Omitting them starts a fresh task. The bridge itself stays stateless: the conversation state lives in the A2A server and the ids travel through the MCP client's context.

Long-running tasks and timeouts

While a task runs, the bridge emits MCP progress notifications — one per A2A status event, plus a heartbeat every A2A_HEARTBEAT_SECONDS while the agent is silent — so MCP clients that reset their tool-call timeout on progress (per the MCP spec) won't kill a slow call. For agents that outlive even that, raise A2A_TIMEOUT_SECONDS, and note that a timed-out task is not lost: the error message includes its task_id for get_a2a_task.

Requirements

Python 3.10+
An A2A server speaking a2a-sdk 0.3.x semantics (e.g. Google ADK's to_a2a, or anything else built on the same SDK). The bridge pins a2a-sdk>=0.3.26,<1.0.0: the 1.x SDK line moved to protobuf-based types and is a separate migration.

Development

pip install -e ".[dev]"
pytest

License

MIT — see LICENSE.

Available Tools

3 tools

get_a2a_taskA

Fetch the current state and result of a previously started A2A task.

Use this when send_a2a_message timed out or errored after the task had already started: the task keeps running server-side, and this retrieves its status and any output by the task_id from the error message or the [a2a ...] response footer.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes
`agent_url`	No		http://localhost:8001

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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 the tool retrieves status and output, and that the task continues running server-side. It does not explicitly state it is read-only, but that is implied. The description provides useful context for polling behavior but lacks explicit mention of rate limits or authentication.

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?

Two sentences with no wasted words. The first sentence states the purpose, the second provides usage guidance. Information is front-loaded and easy to parse.

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?

For a simple fetch tool with two parameters (one required) and an output schema, the description covers the key use case (polling after send_a2a_message failure) and explains how to obtain the required task_id. It is missing agent_url explanation, but given its default and typical usage (same as the original message), the overall completeness is high.

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?

Schema description coverage is 0%, so the description must compensate. It explains the task_id parameter indirectly (derived from error messages or response footer), but does not mention the agent_url parameter at all, which has a default but may need to be overridden. The explanation is insufficient for both 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 starts with a clear verb+resource: 'Fetch the current state and result of a previously started A2A task.' This distinguishes it from sibling tools like send_a2a_message (which starts tasks) and get_agent_card (which retrieves agent information).

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?

Explicitly states when to use: 'Use this when send_a2a_message timed out or errored after the task had already started.' It provides context that the task runs server-side and explains how to obtain the task_id from error messages or the response footer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_agent_cardB

Fetch capabilities (name, description, skills) of an A2A agent.

ParametersJSON Schema

Name	Required	Description	Default
`agent_url`	No		http://localhost:8001

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It only states the action without disclosing side effects, authentication needs, or behavior on invalid input. The fetch is likely read-only but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded verb, no unnecessary words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple fetch with one optional parameter and an output schema. However, lacks error handling or availability notes. Minimal but sufficient.

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?

Schema description coverage is 0%. Description does not add meaning to the parameter 'agent_url' beyond its schema definition (string with default). The description could clarify the format or required permissions.

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?

Description clearly states the verb 'Fetch' and the resource 'capabilities (name, description, skills) of an A2A agent'. It distinguishes from sibling tools which deal with tasks and messages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage (when you need agent capabilities) but no explicit guidance on when not to use or alternatives. No exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_a2a_messageA

Send a message to an A2A agent and return its final text response.

The response ends with an [a2a task_id=... context_id=...] line. To continue the same conversation -- in particular to answer a [task input-required] question -- pass those ids back via the task_id / context_id arguments on the next call; omitting them starts a fresh task.

Long-running agent pipelines are expected: progress notifications are emitted while the task runs, so tune A2A_TIMEOUT_SECONDS rather than treating a slow response as a hang. If the call does time out after the task started, the error names the task_id -- the task keeps running server-side and get_a2a_task can retrieve its result.

ParametersJSON Schema

Name	Required	Default
`message`	Yes
`task_id`	No
`agent_url`	No	http://localhost:8001
`context_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: emits progress notifications, may time out but task continues server-side, response format includes an [a2a ...] line. It clarifies that omitting ids starts a fresh task, and describes how to handle timeouts.

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 (approximately 9 lines) and well-structured: purpose first, then response continuation, then timeout handling. Every sentence adds value, no redundancy.

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?

Given the tool's complexity (asynchronous task-based communication, with progress notifications and timeout recovery) and the presence of an output schema (though not shown), the description covers all necessary context: usage, continuation, error handling, and ties to sibling tools. It is complete for an agent to use correctly.

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?

Schema has 0% description coverage; the description adds meaning to all 4 parameters: message as content, task_id/context_id for conversation continuity, and agent_url as default endpoint. It explains how omitting ids vs. providing them changes behavior.

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 starts with a clear verb-resource pair: 'Send a message to an A2A agent and return its final text response.' It distinguishes from siblings get_a2a_task (retrieve results) and get_agent_card (get metadata) by focusing on initiating or continuing a conversation.

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?

Provides explicit guidance: explains the response format with task_id/context_id, instructs to pass those back to continue the conversation, and advises to tune A2A_TIMEOUT_SECONDS for long-running tasks instead of treating delays as hangs. Also mentions using get_a2a_task if a timeout occurs, linking to the sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jul 9, 2026
- First observedget_a2a_task
- First observedget_agent_card
- First observedsend_a2a_message

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-09 18:40 across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: send_a2a_message sends messages, get_a2a_task retrieves task state, get_agent_card fetches agent metadata. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (get_a2a_task, get_agent_card, send_a2a_message). The naming is predictable and uniform.

Tool Count5/5

Three tools is appropriate for a minimal A2A bridge: send message, poll task result, and discover agent capabilities. The scope is well-defined and not over- or under-tooled.

Completeness4/5

The set covers core interactions (send, poll, discover) but lacks a cancel or list tasks operation. Minor gap, but agents can work around by polling for completion.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
AgentDM: Agent to Agent Communication PlatformOAuth
ai.agentdm
Agent communication platform for agent to agent messaging via MCP. Messages, channels, skills.
Autonomous Agents Communication Agent Orchestration
2
telegram-mcp
io.github.Shreyas-Profile
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
Communication App Automation
2
Chat ThingOAuth
ai.chatthing
Build and manage AI-native customer support agents from Claude or any MCP client.
Customer Support Autonomous Agents AI & Machine Learning
2

Related MCP Servers

A2A MCP Server
Agent Orchestration Autonomous Agents Communication
GongRzhe
A
license
A
quality
F
maintenance
A bridge server that enables MCP-compatible AI assistants like Claude to seamlessly discover, communicate with, and manage A2A protocol agents.
Updated a year ago (2025-06-18 07:36 UTC)
7
148
Apache 2.0
ACP-MCP-Server
Agent Orchestration Communication
GongRzhe
A
license
B
quality
F
maintenance
A bridge server that connects Agent Communication Protocol (ACP) agents with Model Context Protocol (MCP) clients, enabling seamless integration between ACP-based AI agents and MCP-compatible tools like Claude Desktop.
Updated a year ago (2025-06-18 08:48 UTC)
16
24
MIT
A2A MCP Server
a2anet
-
license
Not graded
quality
Not graded
maintenance
An MCP server that enables Claude to interact with A2A-compatible agents by providing tools to fetch agent cards, retrieve stored cards, and send messages to specific agents.
Updated a year ago (2025-07-12 02:55 UTC)
-
hivegate
Agent Orchestration Autonomous Agents AI & Machine Learning
srotzin
A
license
Not graded
quality
C
maintenance
MCP server for cross-platform agent onboarding. Registers external agents, translates intents from LangChain, CrewAI, AutoGen, and A2A formats, and proxies cross-ecosystem transactions.
Updated a month ago (2026-07-30 16:25 UTC)
MIT

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/ytugarev/a2a-mcp-bridge'

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