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-connector Connect to the A2A agent at https://example.com/agent and query it for the latest news."
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.
A generic MCP server that stream-connects an AI agent to any standard
A2A endpoint — plus a built-in A2A Agent Card
validator. Install it once in your MCP-capable agent (Claude Code, Codex,
Cursor, …) and you can validate and drive any A2A agent over the standard
input-required multi-turn protocol, with no manual a2a-sdk install and no
per-endpoint code.
It is deliberately provider-agnostic: there is no LLM and no API key inside this server. It is a pure standard-A2A client bridge — your agent is the intelligence; the connector only speaks A2A. (Contrast with LLM-bound bridges that wire in a specific provider such as OpenRouter — this one binds to none.)
# Claude Code
claude mcp add a2a-connector -- uvx a2a-mcp-connector
# Codex
codex mcp add a2a-connector -- uvx a2a-mcp-connectorAny other MCP-aware client (Cursor, Claude Desktop, a hand-edited .mcp.json):
{
"mcpServers": {
"a2a-connector": {
"type": "stdio",
"command": "uvx",
"args": ["a2a-mcp-connector"]
}
}
}To run it from a checkout of this repository instead, use
uv run a2a-mcp-connector.
Related MCP server: Share A Bot MCP A2A (agent2agent) Protocol
Tool | What it does |
| Fetch a remote Agent Card and return a standard-A2A validation report (valid?/checks/warnings) — parses it against the a2a-sdk model and checks the required spec fields + streaming capability. Nothing is connected. |
| Validate the card first (refuses on failure), then start a background streaming session. Returns immediately. |
| Wait (bounded) for the next |
| Submit your reply to the current turn. |
| Connected? / turn pending? / done? / error snapshot. |
| Disconnect and close the session cleanly. |
bearer is optional — pass it only when the endpoint's card/RPC route
requires auth. It is held in memory only and never logged or returned by any
tool.
a2a_validate <card-url> # optional pre-flight; a2a_connect validates anyway
a2a_connect <card-url> <bearer?> # start the session
loop:
a2a_wait_turn # show the prompt to your human, get their reply
a2a_send <their reply> # submit it
a2a_leave # when done (or "the session is over.")The connecting agent should present each turn's prompt to its human and wait for their actual choice — it must not invent a reply.
One A2A task maps to the whole interaction. a2a_client.A2ASession resolves the
Agent Card, derives the JSON-RPC URL from the served card path (reverse-proxy
safe — it does not trust the card's advertised interface URL), opens or resumes
the task, and drives turns with message/send. Because an A2A turn blocks until
it is genuinely your turn, the session runs on one background asyncio task and
the MCP tools are small, bounded polls over it — so a tool call never hangs.
validator.validate_agent_card fetches the raw card, parses it into the a2a-sdk
AgentCard model (the authoritative "can this connector drive it?" check), then
runs the standard-A2A structural checks (required fields, tolerant of both the
supportedInterfaces and legacy top-level url shapes) and reports the
capabilities.streaming capability.
This package imports neither a2a_games nor a2a_raid_mcp (its game-specific
sibling) — its only dependencies are the public mcp, a2a-sdk (pinned
==1.1.0), and httpx — so it is reusable against any A2A endpoint. It is
published to PyPI and developed
in the open here.
uv sync --frozen --extra dev
uv run --frozen pytest -q--frozen is deliberate: it installs exactly what uv.lock pins and fails if
the lock has drifted from pyproject.toml. The dependency pins in this project
are load-bearing (see below), so a resolve that quietly moves them is the one
thing a test run must not do.
Every push and pull request runs the test suite on Python 3.11 and 3.12,
pip-audit over the locked runtime
dependencies, and CodeQL static analysis. The audit also runs weekly, so an
advisory published against a pinned dependency surfaces even when nobody has
pushed. Results are in this repository's Actions and Security tabs.
There is no LLM and no API key in this server, and no telemetry. A bearer token
is optional; when you supply one it lives only in memory for the life of the
session, is sent as an Authorization header to the endpoint you named, and is
never written to disk, to a log line, or into any tool's return value. The
connector contacts no host other than the one you point it at.
To report a vulnerability, see SECURITY.md - please use a private advisory rather than a public issue.
mcp is capped below 2.0 and a2a-sdk is pinned exactly. Both are deliberate,
both are explained in pyproject.toml and SECURITY.md, and
tests/test_packaging.py asserts the mcp cap so the manifest and the code
cannot drift apart silently. Please don't lift either in a drive-by pull
request - under mcp 2.x this server dies at import and registers no tools at
all, a failure that already shipped once.
MIT © 2026 Alvin Tay
Connect to a standard A2A endpoint and start streaming its turns. Validates
the Agent Card first and REFUSES to connect if it isn't usable (returns the
validator report). On success, starts a background session and returns
immediately — then call a2a_wait_turn for the first prompt. bearer is
optional (pass it only if the endpoint requires auth). Neither the card URL's
contents nor the bearer are echoed back.
| Name | Required | Description | Default |
|---|---|---|---|
| bearer | No | ||
| agent_card_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for transparency. It discloses key behaviors: validation of the Agent Card, refusal with a validator report on failure, starting a background session and returning immediately on success, and the note that neither the card URL nor bearer are echoed back. These details give the agent a solid model of side effects and return behavior.
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 moderately concise, containing multiple pieces of necessary information (purpose, validation, success behavior, follow-up, optional parameter, security note). It is well-structured with clear sentences, but slightly longer than strictly necessary. Still, every sentence adds value and there is 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?
Given the tool's complexity (validation, background session, follow-up action), the description covers the essential context: what to pass, what to expect on failure vs. success, and where to go next (`a2a_wait_turn`). It does not detail the output schema or error conditions, but these are less critical for a first call. Overall, it provides enough context for the agent to use the tool correctly in a typical flow.
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%, so the description must compensate. It gives clear semantics for `bearer` (optional, only when auth is required), but for `agent_card_url` it only implies from context that it is the endpoint URL. This is partial coverage; a more explicit definition of `agent_card_url` would improve the score.
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 primary function: "Connect to a standard A2A endpoint and start streaming its turns." It uses specific verbs (connect, start streaming) and identifies the resource (A2A endpoint). It also distinguishes itself from sibling tools implicitly by describing the connect/start action, which is unique among the listed 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?
The description provides actionable usage guidance: it tells the user to call `a2a_wait_turn` after success, and explains when to pass `bearer` ("pass it only if the endpoint requires auth"). It does not explicitly contrast with siblings like `a2a_validate` or `a2a_send`, but the sequencing and conditional parameter guidance are clear enough for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect: cancel the background driver and close the session cleanly. Safe to call even if not connected.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It explicitly describes the effect (cancel background driver, close session) and notes safety conditions, though it omits potential edge-case 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant wording. Directly conveys purpose and safety without extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, single action), the description covers purpose, behavior, and usage context sufficiently. Output schema exists, so return details are not required.
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?
No parameters exist; baseline score of 4 applies. Nothing further to document.
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 action (disconnect) and the resource (session), plus ancillary detail (cancel background driver). Distinct from sibling tools like connect or send.
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 by noting 'Safe to call even if not connected,' implying it can be used any time. Does not explicitly compare to alternatives but gives sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit your reply to the CURRENT pending turn (call a2a_wait_turn first to see the prompt). Returns immediately; call a2a_wait_turn again for the next turn. Rejected if it isn't your turn yet.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions immediate return and rejection when not your turn, but does not describe side effects, idempotency, or whether it modifies state. Since annotations are absent, more behavioral detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. Directly explains action, precondition, and postcondition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the key usage pattern with wait_turn, the rejection condition, and the immediate return. Lacks details about return value and error handling, but overall sufficient for a simple 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 only parameter 'message' is described as a reply, giving some semantic meaning, but no format, length, or content constraints are provided. Schema has no description, so the description carries a light burden.
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 tool submits a reply to the current pending turn, and references the wait_turn flow. No ambiguity.
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 instructs to call a2a_wait_turn first to see the prompt, and to call it again for the next turn. Also notes rejection when it's not your turn, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A quick snapshot: connected? a turn pending? session over? any error? Useful to re-orient after a gap in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only status check via 'snapshot,' but it does not explicitly guarantee no side effects. Since no annotations are provided, the description carries this burden and mostly satisfies it.
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 two short sentences to convey the tool's purpose and recommended usage. No unnecessary details are included.
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 parameterless status tool with an output schema present, the description is complete enough for an agent to understand what it does and when to invoke it.
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 tool has zero parameters, so parameter-level explanation is unnecessary. The baseline score of 4 applies because there is nothing about parameters that needs clarification.
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 as a status snapshot, checking connectivity, turn state, session status, and errors. This distinguishes it from sibling tools that connect, send, leave, validate, or wait for a 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?
It explicitly says the tool is useful to re-orient after a gap in the conversation, giving a clear use case. It does not explicitly contrast with sibling tools, but the context makes the appropriate scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate ANY standard A2A endpoint's Agent Card and return a readable
report (valid?/checks/warnings). agent_card_url is the full served card URL
(e.g. .../.well-known/agent-card.json); bearer is optional (only needed
if the card route requires auth). Nothing is connected or sent — this only
fetches and inspects the card. The bearer is never echoed back.
| Name | Required | Description | Default |
|---|---|---|---|
| bearer | No | ||
| agent_card_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description supplies key behavioral facts: it only fetches and inspects, never connects or sends, and does not echo the bearer token. This adequately conveys the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack purpose, parameter meanings, and behavioral guarantees without fluff. The structure is well organized and directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, its inputs, and the nature of the output (valid?/checks/warnings). Given an output schema exists, additional return-value details are not necessary.
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 has no descriptions, but the description explains agent_card_url as the full served URL and bearer as optional and needed only when auth is required. Both parameters are semantically covered.
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 validates Agent Cards at any standard A2A endpoint and returns a readable report. This distinguishes it from sibling tools like connect or send by focusing on validation/inspection.
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?
Implicitly tells when to use: whenever you need to validate an Agent Card, and explicitly notes it does not connect or send. It does not name sibling alternatives, but the read-only validation purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the next turn's prompt, bounded by max_seconds (default 30) so
this never hangs indefinitely. Returns the prompt text once it's your turn,
"the session is over." once the remote agent finishes, an "Error: ..." string
if the session broke, or "No turn yet — call a2a_wait_turn again." if the
window elapsed first (just call it again). Show whatever this returns to your
human and get their actual reply before calling a2a_send.
| Name | Required | Description | Default |
|---|---|---|---|
| max_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does well: it discloses blocking behavior with a timeout, all possible return outcomes, and the expected follow-up action. This is highly transparent.
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 efficient and well-organized, listing behaviors and outcomes in a compact form. It is slightly dense in the second sentence but remains focused and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description fully covers the tool's behavior, return values, and the appropriate workflow. No critical information is missing.
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 single parameter max_seconds is described in context as the bound for waiting, and the default value is stated. This adds meaningful semantics beyond the raw schema type and default.
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 verb 'wait' and the object 'next turn's prompt', and distinguishes this tool from siblings like a2a_send and a2a_status by focusing specifically on waiting for an incoming 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?
The description explains when to use the tool (to wait for a turn) and what to do with the result (show to human, get reply, then call a2a_send), but it does not explicitly contrast it with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2a2a_connecta2a_leavea2a_senda2a_statusa2a_validatea2a_wait_turnEach tool has a distinct responsibility: validate checks the Agent Card, connect establishes the session, send/wait_turn handle messaging, status reports state, and leave tears down. No functional overlap or ambiguity exists.
All tools use the a2a_ prefix and mostly use verb-led names like connect, send, leave, and validate. The sole exception is a2a_status, which is a noun rather than an imperative verb, but it remains clear and aligned with the overall pattern.
Six tools is appropriate for a focused A2A connector: validation, connection, turn-based messaging, status polling, and disconnection. The toolset is lean without missing necessary lifecycle operations.
The toolset covers the full A2A session lifecycle: validate, connect, send, wait for turn, check status, and leave. No essential operation for interacting with a remote agent over this protocol appears to be missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alvintayzhenwei/a2a-mcp-connector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server