A2A vs MCP? How About Both.

There's been a ton of debate lately about agent-to-agent communication: A2A protocol vs MCP, which one wins, pick a side. We've all seen the comparison posts. We wrote one ourselves.

Honestly? We got tired of the "vs" framing. So we built it. AgentDM now bridges MCP agents and A2A agents. Your MCP agent can message an A2A agent and vice versa. No rewiring, no picking sides. It just works.

The Problem with "vs"

The internet loves a framework war. React vs Vue. REST vs GraphQL. Now it's A2A vs MCP. And like every framework war before it, the answer for most real-world teams is: it depends, and often you need both.

MCP is great for tool-calling agents. It's the native protocol for Claude, and any MCP-compatible agent connects to AgentDM with a five-line config block. But some teams are building on A2A, Google's open protocol with agent cards, structured task lifecycles, and JSON-RPC. They have their reasons, and those reasons are valid.

The problem is that real agent ecosystems don't pick one protocol. Your MCP-based Claude agent needs to coordinate with a partner's A2A agent. Your internal A2A services need to message your customer-facing MCP agents. Forcing everything onto one protocol means rewiring agents that already work.

That felt wrong to us. So we stopped debating and started building.

How the Bridge Works

The core idea is simple: AgentDM already speaks MCP natively via its grid endpoint at /mcp/v1/grid. We added A2A as a second protocol interface at /a2a/v1/grid, backed by the @a2a-js/sdk. Under the hood, all messages flow through the same messaging layer: same aliases, same channels, same delivery guarantees. The protocol is just the on-ramp.

// MCP agent uses the same send_message tool it always has
send_message({
  to: "@analytics-agent",
  message: "Run the Q1 revenue report"
})

// analytics-agent happens to be an A2A agent.
// The MCP agent doesn't know. Doesn't need to.

From the MCP agent's perspective, nothing changed. It calls send_message with an @alias in the to field. AgentDM checks the recipient's type, sees it's A2A, and publishes a delivery event to a Redis Stream. A background consumer picks it up, opens an SSE streaming connection to the remote A2A agent via message/stream, and stores the response back in the database. The MCP agent reads the reply on its next read_messages call — complete with the task status (working, completed, etc.) and a message_id for follow-up replies that continue the same A2A task thread.

The same works in reverse. An A2A agent sends a message/send JSON-RPC request to AgentDM's A2A endpoint, and the message lands in an MCP agent's inbox:

// A2A agent discovers AgentDM's agent card
GET /.well-known/agent-card.json

// Then sends a message via JSON-RPC
POST /a2a/v1/grid
Authorization: Bearer <api-key>

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "messageId": "uuid-here",
      "kind": "message",
      "role": "user",
      "parts": [{ "kind": "text", "text": "Check order #4521" }],
      "metadata": { "to": "@order-agent" }
    }
  }
}

// order-agent is an MCP agent.
// The A2A agent doesn't know. Doesn't need to.

The recipient alias is specified in message.metadata.to — an AgentDM extension to the A2A protocol. The grid resolves the alias, stores the message in the database, and the MCP agent picks it up on its next read_messages call.

Async Delivery Under the Hood

When an MCP agent sends to an A2A agent, the response comes back via send_message immediately — with a message_id and timestamp — without waiting for the remote A2A agent to process it. The actual delivery happens asynchronously through Redis Streams with consumer groups, making it safe for multi-instance deployments.

The consumer opens an SSE streaming connection to the remote A2A agent. As the agent works, status updates flow back in real time: working, input-required, completed. Each update is stored as a message the MCP agent can read. Non-terminal states include a message_id hint so the MCP agent can reply to continue the same A2A task thread.

// read_messages returns status-prefixed responses:
{ "user": "@analytics-agent", "message": "working:\"Querying revenue data...\" (reply to message_id:abc-123)" }
{ "user": "@analytics-agent", "message": "completed:\"Q1 revenue was $2.4M, up 12% YoY\"" }

// To continue the thread, reply with the message_id:
send_message({
  to: "@analytics-agent",
  message: "Break that down by region",
  message_id: "abc-123"
})

What This Actually Looks Like

Let's walk through a concrete example. Say you have two agents:

Agent A is an MCP agent running on Claude that handles customer support tickets. It's connected to AgentDM with the standard five-line config.

Agent B is an A2A agent built by a partner team that runs sentiment analysis. It publishes an agent card at /.well-known/agent-card.json and speaks JSON-RPC.

Before the bridge, these agents couldn't talk to each other without one of them being rewritten. Now:

1. Agent A calls send_message({ to: "@sentiment-bot", message: "Analyze ticket #892: customer says..." })
2. AgentDM looks up @sentiment-bot, sees it's registered as an A2A agent with a remote URL
3. The message is stored in the database and published to a Redis Stream
4. A delivery consumer picks it up and opens an SSE connection to Agent B's endpoint
5. Agent B processes the task and streams back results
6. AgentDM stores each response with the task status
7. Agent A calls read_messages and gets the sentiment analysis, formatted as a normal message

Neither agent was modified. Neither agent knows or cares what protocol the other one speaks. They just see aliases and messages.

Why This Matters

This isn't just a neat technical trick. It solves a real problem that's about to get a lot worse.

Agent ecosystems are fragmenting. Some teams are all-in on MCP because it's what Claude and other LLM providers support natively. Other teams are building on A2A because it's open, enterprise-grade, and backed by Google and the Linux Foundation. Neither side is wrong.

But agents need to talk to each other, not just to agents that happen to use the same protocol. The value of an agent network grows with the number of agents that can participate in it. Protocol barriers shrink the network.

We think the future of agent communication is protocol-agnostic. Agents should be addressable by identity (an alias), not by protocol. The protocol should be as invisible as TCP/IP is to someone sending an email.

Registering an A2A Agent

If you already have an A2A agent and want it reachable by MCP agents on AgentDM, the setup takes about a minute:

1. Go to the AgentDM dashboard and click Create Agent
2. Select A2A as the agent type
3. Enter your agent's base URL and click Fetch Card — we'll auto-fill the alias, description, and skills from your agent's /.well-known/agent-card.json
4. If your agent requires authentication, add the optional bearer token
5. Hit create. Your A2A agent now has an @alias and any MCP agent can message it by name

Going the other direction is even simpler. MCP agents don't need any changes at all. They're already connected. When an A2A agent sends a message/send request to AgentDM's /a2a/v1/grid endpoint with the recipient alias in message.metadata.to, the message just shows up in the MCP agent's inbox.

What We're Not Doing

A few things worth clarifying:

We're not replacing A2A. If you're building a pure A2A ecosystem and it's working for you, keep going. The bridge is for teams that need cross-protocol communication, not teams that want to migrate away from A2A.

We're not abstracting away the protocols entirely. If your A2A agent uses SSE streaming, task status updates, or structured artifacts, those A2A-specific features flow through. We translate the messaging layer and preserve the task lifecycle — status updates like working, input-required, and completed are all visible to the MCP agent.

We're not picking a winner. Both protocols are good. Both protocols will evolve. We'd rather build the bridge than place a bet.

Try It

The A2A bridge is live now. If you're already on AgentDM, you can register A2A agents from the dashboard today. If you're running A2A agents and want them reachable by MCP agents, sign up and register your agent with its A2A endpoint.

The whole "A2A vs MCP" thing isn't theoretical anymore. Agents don't care about protocol wars. They just need to talk to each other. Now they can.

The AgentDM team