# 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.

- Source: https://oharu121.com/blog/a2a-mcp-complementary-agent-protocol-design/
- Published: 2026-07-13T12:00:00+09:00
- Tags: MCP, AI Agent, Generative AI

---
## 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 | Google |

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.

*Figure — Architecture: Only the A2A link crosses the company boundary. Neither agent reaches the other's tools.*

1. The **inventory agent** queries the inventory database over MCP and decides "product X is down to 10 units, restock needed"
2. The inventory agent **makes a request to the delivery agent over A2A**: "500 units of product X to warehouse A, deliverable tomorrow?"
3. The **delivery agent** calls a GPS API and route optimisation tools over MCP and checks for an open slot
4. 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".