A2A and MCP: What's the Difference? Organizing the Design Philosophy of Agent-to-Agent Communication Protocols
This page has been translated by machine translation. View original
Introduction
"I want to connect agents together — can't I just use MCP for that?"
As AI agent development advances, have you ever had this question? While MCP (Model Context Protocol) is spreading as a standard for tool integration, another specification called A2A (Agent-to-Agent) protocol, proposed by Google, has also emerged.
Why do we need two protocols? What is MCP lacking on its own? And why did both choose HTTP as their foundation? — This article digs into these questions one by one.
A2A and MCP — Their Respective Domains
First, let's organize the roles of each.
| MCP | A2A | |
|---|---|---|
| Full Name | Model Context Protocol | Agent-to-Agent Protocol |
| Domain | Agent ↔ Tools/Data Sources | Agent ↔ Agent |
| Relationship | Client-Server (hierarchical) | Peer-to-peer, bidirectional |
| Typical Operations | tools/call, resources/read |
tasks/send, tasks/get |
| Proposed By | Anthropic |
In a nutshell, MCP is an agent's "hands and eyes" (using tools, reading data), while A2A is an agent's "mouth" (conversing and negotiating with other agents).
A Concrete Example: Logistics × Inventory Management
Let's look at an example of cross-organizational agent collaboration.
- The inventory agent queries the inventory DB via MCP → determines "Product X has 10 units left, replenishment needed"
- The inventory agent requests the delivery agent via A2A → "Can you deliver 500 units of Product X to Warehouse A tomorrow?"
- The delivery agent calls the GPS API and route optimization tools via MCP to check availability
- The delivery agent responds via A2A → "Delivery possible at 2 PM tomorrow. Truck B-12 assigned"
As shown here, tool operations (MCP) and inter-agent negotiation (A2A) have clearly distinct roles.
Why MCP Alone Is Insufficient for Inter-Agent Communication
The idea of "just registering the other agent as an MCP tool" is natural. However, there are several fundamental problems.
1. Lack of Parity
MCP is a client-server model. One side becomes the client (the caller), and the other becomes the server (the callee).
MCP: Agent(client) → Other Agent(server = treated as a tool)
A2A: Agent ←→ Agent (peer-to-peer)
Agents are entities that make autonomous decisions. Subordinating one as a tool means ignoring the other's autonomy — for example, its ability to decline with "I can't accept those terms."
2. No Capability Discovery Mechanism
MCP does provide a way to expose tool schemas (type definitions for inputs and outputs), but it is insufficient for expressing an agent's "capabilities," "policies," or "current state."
A2A uses a mechanism called the Agent Card, where each agent publishes its capabilities and policies as /.well-known/agent.json. You can discover in advance what the other party can do and under what conditions they accept requests.
3. Asynchronous Task Management
MCP is fundamentally a synchronous request-response model. It is not suited for managing the state of long-running tasks such as "Arranging delivery, will confirm in 3 hours."
A2A has built-in mechanisms for tracking task state transitions (submitted → working → input-required → completed / failed), and can receive progress updates via SSE or push notifications. input-required is the state where an agent is requesting additional information in order to proceed with processing.
4. Cross-Organizational Authentication and Trust
When crossing organizational boundaries, identity verification and permission negotiation between agents are required. MCP does not have mechanisms for this kind of cross-organizational authentication.
Summary
MCP: "Execute this tool" → Result (hierarchical relationship)
A2A: "Can you handle this?" → Negotiation → Agreement → Execution → Report (peer relationship)
Transport Layer Design Choices — Why HTTP?
Interestingly, both MCP and A2A have similar transport layer choices.
| MCP | A2A | |
|---|---|---|
| Message Format | JSON-RPC 2.0 | JSON-RPC 2.0 |
| Local Communication | stdio | — (assumes cross-org) |
| Remote Communication | Streamable HTTP (formerly: HTTP + SSE) | HTTP + SSE |
| gRPC | Not used | Not used |
Neither uses gRPC. Despite gRPC offering fast binary communication, why did they choose HTTP + JSON?
Reasons for Not Choosing gRPC / WebSocket
A2A's primary battlefield is cross-organizational communication. The premise is different from microservice-to-microservice communication within an internal LAN.
| Technology | Reason for Rejection |
|---|---|
| gRPC | Cannot be called directly from browsers. Sharing Proto definitions is cumbersome across organizations. Not as compatible with firewalls and proxies as HTTP |
| WebSocket | Tends to be disconnected by corporate proxies. Persistent connections consume server resources. Routing with load balancers is complex. Reconnection handling after disconnection is required |
Reasons HTTP + SSE Was Chosen
| Benefit | Explanation |
|---|---|
| Infrastructure Compatibility | Corporate firewalls, proxies, and load balancers are already built with HTTP in mind |
| Ecosystem | Mature tooling such as OAuth authentication, rate limiting, audit logging, and API Gateways can be used as-is |
| Discoverability | Agent Cards can be retrieved via HTTP GET as /.well-known/agent.json |
| Scalability | Stateless, with each request being self-contained. Easy to scale out |
| Streaming | Real-time notifications are possible with SSE. Can also pass through proxies |
Maximizing cross-organizational interoperability is the top design priority, and HTTP is the choice with the least friction for that purpose.
Note that for real-time inter-agent communication within the same organization, gRPC or WebSocket may be more appropriate in some cases. Protocol choice depends on the use case.
Summary
| Aspect | MCP | A2A |
|---|---|---|
| Role | Agents access tools/data | Agents communicate and negotiate with each other |
| Relationship | Hierarchical (client → server) | Peer-to-peer (bidirectional) |
| Transport | Streamable HTTP / stdio | HTTP + SSE |
| Capability Discovery | Tool schemas (input/output type definitions) | Agent Card (/.well-known/agent.json) |
| Message Format | JSON-RPC 2.0 | JSON-RPC 2.0 |
- MCP and A2A are not competing but complementary. If MCP is an agent's "hands and eyes," A2A is its "mouth"
- Agents are not tools. Precisely because they are entities that make autonomous decisions, a separate agent protocol (A2A) is needed alongside the tool protocol (MCP)
- HTTP was chosen for compatibility, not speed. In the use case of cross-organizational communication, it is a design decision that minimizes friction with existing infrastructure
When designing multi-agent systems, it is important to separately consider "which tools to connect to which agents via MCP" and "which agents to connect with each other via A2A."
