MCP vs A2A: How Agent Protocols Fit Together
MCP connects an agent to tools and data sources. A2A (Agent2Agent) connects an agent to other agents, treating each as an opaque peer that accepts tasks. The A2A documentation describes the two as complementary: MCP for agent-to-tool communication, A2A for agent-to-agent communication. Most single-agent products need MCP and can ignore A2A until they delegate work to agents owned by someone else.
The Model Context Protocol (MCP) and the Agent2Agent protocol (A2A) both standardize how an AI agent talks to something outside itself. They differ in what that something is: a tool in one case, another agent in the other.
What is MCP?
The Model Context Protocol lets an application give a model access to external capabilities. Messages use JSON-RPC 2.0, the same format many web APIs use for remote calls. A server offers tools (functions the model can call), resources (data used as context), and prompts (templated messages). The model's counterpart is a system with a defined interface: a database, a ticket tracker, a file store.
What is A2A?
The Agent2Agent protocol (A2A) was developed by Google and donated to the Linux Foundation. It standardizes how independent agents, often built on different frameworks, communicate as peers. Its specification aims at communication between independent, potentially opaque agent systems, without requiring them to share internal state or tool implementations.
Three concepts carry most of the design. An Agent Card is a metadata document describing an agent's identity, capabilities, skills, endpoint, and authentication requirements. A task is the unit of work, which moves through defined states from submission to completion or failure. A message is one turn of communication between the two agents. The specification defines bindings over JSON-RPC 2.0, gRPC (a remote procedure call framework), and HTTP with JSON.
How do MCP and A2A differ?
| Criteria | MCP | A2A |
|---|---|---|
| What connects | An agent and a tool or data source | An agent and another agent |
| The other side is | A system with a defined interface | An opaque peer with its own reasoning |
| What is exchanged | Tool calls, resources, prompts | Tasks and messages |
| Discovery | The server lists its tools and resources | The agent publishes an Agent Card |
| Unit of work | A single call and its result | A task with a lifecycle |
| How the A2A project frames it | Vertical: gives one agent depth | Horizontal: connects agents across boundaries |
The vertical and horizontal wording comes from the A2A project's own comparison page, which presents the two as layers of the same stack.
Can one protocol do the other's job?
Partly, and the trade-offs are real. You can put an agent behind an MCP tool so another agent calls it like any function. For a short request and response, that works. A2A adds structure for the cases where it stops fitting: work that takes time and passes through states, and discovery of what a remote agent can do before you call it.
Going the other way, A2A is not meant for reaching a database. Its design treats the other party as an agent that reasons and keeps its internals private, which is more than a tool call needs.
When do you need each?
Start with MCP. A single agent with good tools is the simpler design, and it needs only MCP.
Add A2A when the second agent is not yours to change: a partner's agent, a vendor's agent, or a team on a different framework. The test is whether you can rewrite the other side. If you can, wiring it in as a tool or a function is often simpler. If you cannot, a shared protocol is what keeps the integration from being bespoke.
What does it look like in Metorial?
Metorial is built around MCP. The agent's tool calls go through the gateway: per-user OAuth so a call runs as the person the agent works for, access control over which tools each user reaches, and Tracing that records the tool name, arguments, and result. Integrations are organized as providers, with 1,000+ available in the catalog.
Metorial does not document support for A2A. If you run a mesh of A2A agents, each agent can still reach its tools through Metorial over MCP, which gives you one access and logging layer under agents that otherwise keep their internals private. Metorial does not manage the agent-to-agent hop itself.
Frequently asked questions
Does A2A replace MCP?
No. The A2A project describes itself as complementary to MCP. MCP standardizes how an agent connects to tools and resources. A2A standardizes how independent agents communicate with each other. An agent can use both at once.
Do I need A2A if I already use MCP?
Probably not yet. If one agent calls tools, MCP covers it. A2A becomes relevant when your agent needs to hand work to a separate agent built on another framework or run by another team or company, without sharing that agent's internals.
Who maintains A2A?
A2A was originally developed by Google and donated to the Linux Foundation, which hosts it now. The project's site lists 1.0.0 as the latest released version of the specification.
What is an A2A Agent Card?
It is a metadata document an A2A server publishes to describe itself. According to the specification it covers the agent's identity, capabilities, skills, service endpoint, and authentication requirements, so another agent can discover how to work with it.
Does A2A handle access control for the tools an agent uses?
Not directly. A2A is built so agents collaborate without exposing their internal tools or memory, which means tool access stays inside each agent. Controlling what an agent can call, and recording it, is the job of the layer on the MCP side.