A2A vs MCP — why agent-to-agent needs its own protocol, and why both chose HTTP over gRPC
Why MCP alone is not enough for agent-to-agent communication: peer equality, Agent Card discovery, async task state, and why both protocols chose HTTP.
On this page
Introduction
“I want to get agents talking to each other, but can’t I just connect them with MCP?”
As AI agent development picks up, this is a question people run into. MCP (Model Context Protocol) is spreading as the standard for tool integration, and alongside it a separate specification has appeared: the A2A (Agent-to-Agent) protocol proposed by Google.
The short answer is that they cover different ground. MCP is an agent’s hands and eyes; A2A is its mouth. A tool protocol cannot stand in for an agent protocol because a tool cannot refuse a request, and an agent can.
Why two protocols are needed, what MCP is missing, and why both picked HTTP as their foundation are the questions this article works through in order.
A2A and MCP, and what each covers
First, the roles.
| MCP | A2A | |
|---|---|---|
| Full name | Model Context Protocol | Agent-to-Agent Protocol |
| Area of responsibility | Agent ↔ tools/data sources | Agent ↔ agent |
| Relationship | Client-server (subordinate) | Peer, bidirectional |
| Typical operations | tools/call, resources/read |
tasks/send, tasks/get |
| Proposed by | Anthropic |
In one line: MCP is an agent’s “hands and eyes” (using tools, reading data), and A2A is an agent’s “mouth” (conversing and negotiating with other agents).
A concrete example: logistics and inventory management
Here is what cross-organisation agent integration looks like.
Only the A2A link crosses the company boundary. Neither agent reaches the other’s tools.
- The inventory agent queries the inventory database over MCP and decides “product X is down to 10 units, restock needed”
- The inventory agent makes a request to the delivery agent over A2A: “500 units of product X to warehouse A, deliverable tomorrow?”
- The delivery agent calls a GPS API and route optimisation tools over MCP and checks for an open slot
- The delivery agent answers over A2A: “deliverable tomorrow at 14:00, truck B-12 assigned”
Tool operations (MCP) and inter-agent negotiation (A2A) have clearly separated roles.
Why MCP alone is not enough for agent-to-agent communication
“Can’t I just register the other agent as an MCP tool?” is a natural thought. But there are several fundamental problems.
1. No peer equality
MCP is a client-server model. One side is the client (the caller), the other is the server (the callee).
MCP: agent(client) → other agent(server, treated as a tool)A2A: agent ←→ agent (peers)An agent is something that judges autonomously. Subordinating it as a tool means ignoring the other side’s autonomy, including its ability to say “I cannot accept under those conditions”.
2. No capability discovery mechanism
MCP has a mechanism for publishing tool schemas (type definitions for input and output), but that is not enough to express an agent’s capabilities, policies, or current state.
A2A uses a mechanism called the Agent Card, where each agent publishes its own capabilities and policies at /.well-known/agent.json. You can discover in advance what the other side can do and on what terms it accepts work.
3. Asynchronous task management
MCP is fundamentally a synchronous request-response protocol. It is not suited to managing the state of long-running tasks like “delivery is being arranged, it will be confirmed in three hours”.
A2A has task state transitions built in (submitted → working → input-required → completed / failed) and can push progress over SSE or push notifications. input-required is the state where an agent is asking for additional information in order to proceed.
4. Cross-organisation authentication and trust
Crossing an organisational boundary requires identity verification and permission negotiation between agents. MCP does not anticipate that kind of inter-organisation authentication.
Put simply
MCP: "run this tool" → result (subordinate)A2A: "can you take this on?" → negotiate → agree → execute → report (peers)Transport layer design choices: why HTTP
Interestingly, MCP and A2A made similar transport layer choices.
| MCP | A2A | |
|---|---|---|
| Message format | JSON-RPC 2.0 | JSON-RPC 2.0 |
| Local communication | stdio | — (assumes cross-organisation) |
| Remote communication | Streamable HTTP (formerly HTTP + SSE) | HTTP + SSE |
| gRPC | Not used | Not used |
Neither one adopted gRPC. With gRPC available and offering fast binary communication, why choose HTTP and JSON?
Why gRPC and WebSocket were not chosen
A2A’s main arena is cross-organisation communication. The assumptions differ from microservice communication on an internal LAN.
| Technology | Reason it was not adopted |
|---|---|
| gRPC | Cannot be called directly from a browser. Sharing proto definitions across organisations is cumbersome. Works less well with firewalls and proxies than HTTP does |
| WebSocket | Tends to get cut by corporate proxies. Persistent connections consume server resources. Routing through load balancers is complex. Reconnection handling after a drop is required |
Why HTTP + SSE was chosen
| Advantage | Explanation |
|---|---|
| Infrastructure compatibility | Corporate firewalls, proxies, and load balancers are already built around HTTP |
| Ecosystem | Mature tooling such as OAuth authentication, rate limiting, audit logs, and API gateways works as-is |
| Discoverability | An Agent Card can be fetched with an HTTP GET at /.well-known/agent.json |
| Scalability | Stateless, with each request self-contained. Easy to scale out |
| Streaming | SSE allows real-time notification, and it passes through proxies |
The top design priority is maximising interoperability across organisations, and HTTP is the lowest-friction choice for that purpose.
That said, for real-time agent communication inside a single organisation, gRPC or WebSocket can be the better fit. Protocol choice depends on the use case.
Summary
| Aspect | MCP | A2A |
|---|---|---|
| Role | Agent accesses tools/data | Agents communicate and negotiate |
| Relationship | Subordinate (client → server) | Peer (bidirectional) |
| Transport | Streamable HTTP / stdio | HTTP + SSE |
| Capability discovery | Tool schema (input/output types) | Agent Card (/.well-known/agent.json) |
| Message format | JSON-RPC 2.0 | JSON-RPC 2.0 |
- MCP and A2A are complementary, not competitors. If MCP is an agent’s “hands and eyes”, A2A is its “mouth”
- An agent is not a tool. Precisely because it judges autonomously, it needs an agent protocol (A2A) separate from a tool protocol (MCP)
- HTTP was chosen for compatibility, not speed. For the cross-organisation use case, it is the design decision that minimises friction with existing infrastructure
When designing a multi-agent system, it matters to think separately about “which tools each agent connects to over MCP” and “which agents are integrated with each other over A2A”.