MCP vs A2A vs ACP: How AI Agents Actually Talk to Each Other

Introduction

If you have seen the popular "MCP vs A2A vs ACP" diagrams making the rounds, you have absorbed a tidy but slightly outdated picture: three rival protocols, three columns, pick one. The reality in 2026 is both simpler and more interesting. These are not three competitors fighting for the same job. They describe different layers of the same stack, and one of the three — ACP — has already been absorbed into another.

Here is the short version. The Model Context Protocol (MCP) connects a single AI agent to tools and data. The Agent2Agent Protocol (A2A) connects separate agents to each other. The Agent Communication Protocol (ACP) was a third protocol that merged into A2A under the Linux Foundation in August 2025 and no longer exists as a standalone spec. So the honest 2026 framing is not "MCP vs A2A vs ACP" — it is "MCP and A2A, with ACP as the history that explains how we got here."

This article untangles the three, explains which layer each one occupies, and gives you a decision you can actually act on.

The mistake the "vs" framing makes

The word "vs" implies substitutes — like choosing between PostgreSQL and MySQL. But you do not choose between MCP and A2A any more than you choose between USB and Ethernet. One plugs a device into a machine; the other connects machines to each other. They compose.

The clean way to think about it is by who is talking to whom:

• Agent → Tools. A single agent needs to query a database, call an API, or read a file. This is MCP's territory. The agent stays in charge; the tools are passive resources it reaches for.
• Agent → Agent. One agent hits the limits of what it can do alone and needs to hand part of the task to another agent — often one built by a different team, running on different infrastructure, using a different framework. This is A2A's territory. Both sides are active, autonomous participants that negotiate.

Almost every non-trivial system needs both. An agent uses MCP to gather context and take actions on tools, and A2A to delegate sub-tasks to specialist agents it does not own. Confusing the two layers is the single most common mistake teams make when they start designing multi-agent systems.

MCP: the agent-to-tools layer

Anthropic introduced MCP in late 2024 as a universal, open standard for connecting AI applications to external systems. The problem it solves is combinatorial. Before MCP, every AI app needed a bespoke integration for every tool: one custom connector for GitHub, another for Postgres, another for Google Drive. With N apps and M tools, you faced N × M integrations. MCP turns that into N + M — each app speaks MCP once, each tool exposes an MCP server once, and they interoperate.

The architecture has three roles:

• MCP Host — the AI application the user interacts with: a chat interface like Claude Desktop, an IDE like Cursor or VS Code, or a custom app.
• MCP Client — instantiated by the host when external data is needed; it packages and routes requests to the right server.
• MCP Server — exposes a specific set of tools and resources (a database, an API, a filesystem) and returns structured responses.

Under the hood MCP uses JSON-RPC 2.0, and its notion of "tools" is a close cousin of function calling — the model decides which tool to invoke and with what arguments, and the protocol standardizes how that call travels and how the result comes back. If you have written a function-calling integration, MCP will feel familiar; the difference is that MCP makes the tool reusable across every host that speaks the protocol, not just your app.

MCP's adoption is the reason it anchors the stack. Within a year of launch it reported over 97 million monthly SDK downloads across Python and TypeScript and more than 10,000 active public MCP servers, with first-class client support across Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation — a directed fund under the Linux Foundation co-founded with Block and OpenAI, and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. That donation matters: it puts MCP under the same neutral, vendor-independent stewardship as Kubernetes and PyTorch, so no single company can steer the spec.

A2A: the agent-to-agent layer

A2A answers a different question: when your agent cannot finish a task alone, how does it find and work with another agent it did not build?

Google announced Agent2Agent in April 2025 and donated it to the Linux Foundation in June 2025, establishing neutral governance almost immediately. The protocol is built around three ideas:

• Agent Card — a structured JSON document, published at a well-known URL, that advertises an agent's identity, capabilities, and endpoints. It is how an agent describes what it can do so others can decide whether to delegate to it.
• Discovery — a client agent finds a capable peer, often through a registry of Agent Cards, and reads the card to confirm the peer can handle the task.
• Task delegation — the client sends the task, the remote agent executes it and returns results, which flow back so the originating agent can continue. Long-running work is supported through streaming rather than forcing a single blocking call.

A2A runs over HTTP, using JSON-RPC for structured calls and Server-Sent Events for streaming updates. Crucially, both agents remain autonomous — neither becomes a passive "tool" of the other. That autonomy is the whole point, and it is what distinguishes agent-to-agent coordination from the agent-to-tools relationship MCP describes.

By its first anniversary in April 2026, A2A had passed 150 supporting organizations, 22,000+ GitHub stars, and production SDKs in five languages (Python, JavaScript, Java, Go, and .NET), with GA support inside Microsoft Copilot Studio and Azure AI Foundry and support through Amazon Bedrock AgentCore. Its founding partners include AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow — with IBM Research joining the effort through the ACP merger described below. Version 1.0, shipped in early 2026, added Signed Agent Cards — a cryptographic signature proving a card was issued by the domain it claims — the kind of trust primitive agents need before they delegate real work across organizational boundaries. It is the same identity-and-trust problem that efforts like DNS-based agent identity and the Agent Payments Protocol (AP2) are tackling from other angles.

ACP: what it was, and where it went

This is where the popular diagrams have aged. ACP — the Agent Communication Protocol — was real, and for a few months in 2025 it genuinely was a third option. It is worth understanding precisely, because "ACP" is an overloaded acronym and the story is easy to get wrong.

IBM Research launched ACP in March 2025 to power its open-source BeeAI platform. Its distinguishing choice was a REST-based design: where A2A leaned on JSON-RPC, ACP modeled agent interaction as ordinary REST over HTTP, with a metadata manifest describing an agent's capabilities and synchronous or asynchronous responses depending on the task. IBM donated it to the Linux Foundation, framework-agnostic, with Python and TypeScript SDKs.

Then A2A arrived a month later with heavy backing, and the two protocols were solving substantially the same problem under the same foundation. Rather than let two competing agent-to-agent standards fragment the ecosystem, LF AI & Data announced on August 29, 2025 that ACP would join forces with A2A. In the foundation's own words: "By bringing the assets and expertise behind ACP into A2A, we can build a single, more powerful standard for how AI agents communicate and collaborate." The ACP team ceased independent development, migration paths were published to move ACP users onto A2A, and BeeAI added adapters so its agents became A2A-compliant. IBM's Kate Blair joined A2A's Technical Steering Committee.

So the accurate 2026 status is: ACP is not a standalone specification. Its ideas — a manifest-driven, framework-agnostic approach to agent interoperability — live on inside A2A. If you are reading a diagram that still shows ACP as a live third column, it is a snapshot from mid-2025, before the merger.

(One caution on the acronym: "ACP" has also been used for the unrelated Agentic Commerce Protocol in the payments space. When you see ACP, check which one is meant. In the agent-communication context, it is IBM's now-merged protocol.)

The three side by side

The first row is the one that settles the confusion. MCP sits on a different line from the other two — it is the tool layer, not an agent-coordination layer. A2A and ACP shared a line, and two standards on the same row means fragmentation, which is precisely why they merged.

How they fit together in a real system

Picture a travel-planning assistant. A user asks it to book a trip.

1. The planning agent uses MCP to pull the user's calendar, query a flights API, and read a preferences file — all agent-to-tools work.
2. It realizes booking requires a specialist. It uses A2A to discover a booking agent (run by a travel provider, not by your team), reads its Signed Agent Card to confirm capabilities and authenticity, and delegates the booking task.
3. The booking agent, in turn, uses its own MCP connections to payment and inventory systems to complete the job, then returns the result over A2A.
4. The planning agent continues, using MCP again to write the confirmed itinerary back to the user's calendar.

MCP and A2A interleave naturally: MCP at every point an agent touches a tool, A2A at every point one agent hands off to another. Neither ever does the other's job, so "pick one" is a category error rather than a hard call. This is simply the shape an agentic workflow takes once it grows past a single agent.

What to actually adopt in 2026

A few rules cover most decisions:

• Start with MCP. If your system is one agent reaching tools and data, MCP is all you need, and it is the most mature, most widely supported piece of the stack. Building agentic workflows with an SDK will put you on MCP by default.
• Add A2A when — and only when — you have genuine multi-agent coordination: independent agents, often across organizational boundaries, that must discover each other and delegate at runtime.
• Do not build on ACP. It is not a live standard. If you inherit an ACP integration, follow the published migration path to A2A.
• Lean on the Signed Agent Card once agents cross trust boundaries. Delegating work to an agent you do not control is a security decision before it is an engineering one, and identity is the first thing to get right.

The case worth dwelling on is the one where the answer is neither new protocol. A great many systems described as "multi-agent" are really a single agent with several tools, or a fixed pipeline of steps the same team wrote and ships together. There, a discovery protocol and a delegation handshake are pure overhead: the components already know about each other at build time, share one trust domain, and can just call each other directly. A2A earns its cost only when the peer is genuinely independent — discovered at runtime, owned by someone else, not something you can import. Reaching for the protocol before you have that problem is the mirror image of ignoring it once you do.

The reassuring part of the 2026 picture is consolidation. A year ago the agent-protocol space looked like it might splinter into a dozen incompatible standards. Instead, the two that matter both sit under the Linux Foundation with broad cross-vendor governance, and the third folded cleanly into one of them. That is a healthier foundation to build on than the "three-way war" framing suggests.

Conclusion

"MCP vs A2A vs ACP" is the wrong question, and asking it better reveals the actual architecture. MCP is the agent-to-tools layer; A2A is the agent-to-agent layer; ACP was a second attempt at the agent-to-agent layer that merged into A2A in August 2025. In 2026 you build on MCP and A2A together — MCP everywhere an agent touches a tool, A2A wherever one agent must delegate to another — and you treat ACP as the history that explains why the agent layer has one winner instead of two. The diagrams that show three columns captured a real moment; the ecosystem has simply moved on from it.

Sources

• Introducing the Model Context Protocol — Anthropic
• Donating the Model Context Protocol and establishing the Agentic AI Foundation — Anthropic
• Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF)
• Announcing the Agent2Agent Protocol (A2A) — Google Developers Blog
• Google Cloud donates A2A to the Linux Foundation — Google Developers Blog
• A2A Protocol Surpasses 150 Organizations in Its First Year — Linux Foundation
• ACP Joins Forces with A2A Under the Linux Foundation — LF AI & Data
• An open-source protocol for AI agents to interact — IBM Research