MCP vs A2A: what each protocol connects and which one you need

MCP and A2A don’t compete. MCP connects your agent to tools and data. A2A connects it to another agent. They’re two layers of the same system, and the question isn’t which one you choose, but which one you actually need today.

I’m assuming you already know the basics of MCP: a server exposes tools, resources, and prompts that your agent calls like functions. If not, start with what MCP is. If you’re comparing it to a REST API or to function calling, see MCP vs API; if it’s getting mixed up with RAG, see MCP vs RAG.

MCP vs A2A: the difference in one table

What changes is what’s on the other end of the wire; the last row is the one that decides.

	MCP	A2A
What it connects	An agent to tools and data	An agent to another agent
What’s on the other side	An MCP server: a function you execute that returns a result. It decides nothing	An autonomous system that reasons and can take hours
Who publishes the contract	The MCP server, with its tools’ schemas	The remote agent, in its Agent Card
How you find it	You configure it yourself: command, URL, or file	At /.well-known/agent-card.json on the other domain, or in a registry
When you need it	When your agent runs tools or touches data from a system you own	When you don’t control the other end

What is the A2A protocol?

A2A (Agent2Agent) is an open standard that lets autonomous agents from different frameworks discover each other, delegate tasks, and coordinate without sharing their internal memory, their tools, or their logic^[1]. Google created it, donated it to the Linux Foundation, and since August 2026 it’s a project of the Agentic AI Foundation, the same body that hosts MCP^[2]. Its technical steering committee is made up of AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow: it’s no longer just Google’s thing.

It’s all held up by the Agent Card: a JSON file published at https://{dominio-del-agente}/.well-known/agent-card.json with name, description, provider, the endpoint’s url, A2A capabilities (streaming, pushNotifications), authentication schemes, and the list of skills, each one an AgentSkill with an id, description, and input/output modes^[3].

The 1.0 specification defines three transport bindings (JSON-RPC 2.0, gRPC, and HTTP+JSON/REST, plus functionally-equivalent proprietary ones) and streaming runs over Server-Sent Events^[1]. Its vocabulary: the Task is the unit of work, with its own identifier, stateful, and with a lifecycle; the Message is communication with a user or agent role, made up of Parts (text, file, or JSON); the result is an Artifact^[1]. The practical difference: an MCP tool call goes out and comes back, a Message opens a task that can take half an hour and notify you by push.

When do I need A2A, and when is it overkill?

If everything on the other side is tools you wrote yourself, A2A gives you nothing. An agent that queries your database and calls your orders API is MCP, full stop. Your orchestrator’s subagents don’t need it either: they share a process, a deployment, and a team, and a protocol built for not trusting the other side just adds latency.

A2A matters when the other side is an agent you don’t control: another department’s, a vendor’s, a customer’s who isn’t going to publish their code. That’s where you need what A2A standardizes: discovering what the other one can do, authenticating, sending it work that can take a while, and getting the result back without having to hash anything out over email.

Both together in the same system

The official documentation sums it up well: “MCP is vertical, it goes deep into a single agent. A2A is horizontal, it connects agents across that boundary”^[4].

A purchasing agent speaks MCP inward (one server with your catalog, another with the ERP’s stock) and publishes outward an Agent Card with the skill solicitar-presupuesto. Your vendor’s agent reads it, sends a Message, a Task opens, and the quote arrives as an Artifact, without ever touching your ERP. The tools stay inside; a capability comes out.

Choosing the layer that actually solves each problem, instead of reaching for whichever protocol is trendy, is something you practice in the agentic patterns course.

Sources

1. A2A Protocol Specification — Agent2Agent Project — definition of Task, Message, Part, and Artifact, transport bindings, and protocol operations.
2. A New Chapter for A2A: Joining the Agentic AI Foundation — A2A’s entry into the Agentic AI Foundation, August 2026.
3. Agent Discovery — A2A Protocol — Agent Card fields, AgentSkill objects, and the /.well-known/agent-card.json path.
4. A2A and MCP — A2A Protocol — official stance on how the two protocols complement each other.
5. Agent Communication Protocol — official notice that ACP is becoming part of A2A under the Linux Foundation.
6. Agent Client Protocol — Zed — description of the protocol between editors and coding agents.

Frequently Asked Questions

Does A2A replace MCP? Do I need both?

It doesn’t replace it: A2A’s own documentation presents them as complementary. If your agent only touches tools and data you own, MCP is enough; the moment part of the work is done by an agent from another team or another company, you want both, MCP inward and A2A outward.

What is an Agent Card?

It’s the JSON where an agent declares its endpoint, its authentication, and its skills; the fields are listed above. Worth adding: /.well-known/agent-card.json isn’t the only path — the specification also allows for intermediate registries and direct configuration between tightly coupled systems.

Is A2A just a Google thing?

Google created it, but donated it to the Linux Foundation; today it’s governed, within the Agentic AI Foundation, by the eight-company technical steering committee listed above.

And ACP? Where does it fit into the comparison?

There are two things with that name. The Agent Communication Protocol, the agent-to-agent one that came out of BeeAI, is no longer an alternative: its site now announces that it’s merging into A2A under the Linux Foundation^[5]. Zed’s Agent Client Protocol is still alive, but it connects an editor to a coding agent, not two agents to each other^[6].