A2A vs MCP — why agent-to-agent needs its own protocol, and why only A2A added gRPC
Why MCP alone is not enough between agents: peer refusal, Agent Card discovery, task state, and why A2A v1.0 offers gRPC while MCP stays on 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 A2A added gRPC while MCP kept HTTP are the questions this article works through in order, against A2A v1.0 and the MCP 2026-07-28 specification.
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 | SendMessage, GetTask |
| 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”.
A2A writes that refusal into the protocol. TASK_STATE_REJECTED is a terminal task state meaning the agent has decided not to perform the task, either when the task is created or later once it finds it can’t or won’t proceed.
MCP has no counterpart, and its 2026-07-28 specification makes the direction explicit: servers do not initiate JSON-RPC requests, so the callee only ever answers.
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-card.json. You can discover in advance what the other side can do and on what terms it accepts work.
3. Asynchronous task management
MCP’s core is request-response. Long-running work like “delivery is being arranged, it will be confirmed in three hours” goes through the opt-in Tasks extension: the server returns a task handle instead of a result, and the client polls tasks/get or subscribes to status notifications.
In A2A the task is part of the core protocol. A task moves from TASK_STATE_SUBMITTED to TASK_STATE_WORKING and ends in TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED or TASK_STATE_REJECTED. It can pause in TASK_STATE_INPUT_REQUIRED, where the agent asks for more information, or TASK_STATE_AUTH_REQUIRED, where it waits for authentication. Progress arrives over SSE streaming, webhook push notifications, or polling.
State names drop the TASK_STATE_ prefix. Only REJECTED records that the agent itself declined the work.
4. Cross-organisation authentication and trust
Crossing an organisational boundary requires identity verification and permission negotiation between agents. MCP’s authorization is an optional OAuth 2.1 flow for HTTP transports, built around a client calling a server on behalf of a resource owner.
A2A puts the requirements in the Agent Card instead. Its securitySchemes field declares API keys, HTTP auth, OAuth 2, OpenID Connect or mutual TLS, so the calling agent learns what the other organisation demands before its first request.
Put simply
MCP: "run this tool" → result (subordinate)A2A: "can you take this on?" → negotiate → agree → execute → report (peers)Transport choices: where A2A and MCP split on gRPC
Both protocols started on JSON-RPC 2.0 over HTTP, with SSE for streaming. A2A v0.3 added gRPC as a binding, and v1.0 made a Protocol Buffers definition the canonical data model that every binding must represent. MCP went the other way: its 2026 roadmap says “we are not adding more official transports this cycle”.
| MCP (2026-07-28) | A2A (v1.0) | |
|---|---|---|
| Message format | JSON-RPC 2.0 | Protocol Buffers data model, carried as JSON-RPC 2.0, gRPC, or HTTP+JSON |
| Local communication | stdio | — (assumes cross-organisation) |
| Remote communication | Streamable HTTP: each message an HTTP POST, replies as JSON or an SSE stream | JSON-RPC over HTTP, HTTP+JSON (REST), or gRPC |
| gRPC | Not an official transport. Proposed in SEP-1352; usable only as a custom transport | Optional binding since v0.3 |
The MCP roadmap calls keeping the transport set small a deliberate decision grounded in its design principles, and spends the cycle on letting servers scale horizontally without holding state.
Why gRPC is not the default for cross-organisation traffic
A2A’s main arena is cross-organisation communication. The assumptions differ from microservice communication on an internal LAN.
| Technology | Why it is not the default |
|---|---|
| gRPC | Cannot be called directly from a browser. 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 |
A2A v1.0 publishes one canonical a2a.proto, so two organisations no longer have to agree on proto definitions between themselves. The network objections to gRPC still stand.
How A2A offers gRPC without giving up HTTP
The Agent Card lists every binding an agent speaks in supportedInterfaces. Each entry names a protocolBinding (JSONRPC, GRPC or HTTP+JSON) and a URL, so a client uses gRPC where both sides support it and HTTP everywhere else.
| HTTP 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-card.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. The Agent Card is fetched over HTTP whatever binding follows it.
Inside a single organisation, where both sides control the network, an agent can advertise gRPC next to JSON-RPC and let clients that speak it take the faster path.
Summary
| Aspect | MCP | A2A |
|---|---|---|
| Role | Agent accesses tools/data | Agents communicate and negotiate |
| Relationship | Subordinate (client → server) | Peer (bidirectional), and may reject a task |
| Transport | Streamable HTTP / stdio; gRPC only as a custom transport | JSON-RPC, HTTP+JSON or gRPC, listed in the Agent Card |
| Capability discovery | Tool schema (input/output types) | Agent Card (/.well-known/agent-card.json) |
| Message format | JSON-RPC 2.0 | Protocol Buffers data model; JSON-RPC 2.0 on the JSON-RPC binding |
| Long-running work | Opt-in Tasks extension | Task lifecycle in the core protocol |
- 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 is the baseline for compatibility, and A2A makes gRPC an option for speed. MCP keeps gRPC outside its official transports
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”.
References
- Agent2Agent (A2A) Protocol Specification, v1.0
- Model Context Protocol specification, 2026-07-28
- MCP Tasks extension for long-running operations
- MCP authorization for HTTP transports
- The 2026 MCP Roadmap, including the decision to add no official transports this cycle
- SEP-1352: Add gRPC as a transport for MCP
