Agent Protocols — MCP vs A2A vs ACP
How AI agents actually talk to each other. You just learned MCP, the standard that connects an agent down to its tools. This lesson adds the other axis — agents talking sideways to other agents — and then dismantles the question in its own title, because “MCP vs A2A vs ACP” compares three things that are not competing, and one of them isn’t even one thing.
Explain the two axes of agent communication and place MCP and A2A on them; describe an A2A Agent Card, Task lifecycle, and transport bindings; disambiguate the four protocols currently called “ACP” and state which one is no longer maintained; explain why A2A’s own documentation calls it complementary to MCP; recognize the supporting protocols (AGNTCY, AP2, ANP) without confusing them for rivals; and decide, for a given integration, whether you need MCP or A2A.
Imagine a builder at work. She picks up a hammer — the hammer doesn’t think, it just does exactly what it’s told. That’s MCP: an agent picking up a tool. Now she phones the electrician to come do the wiring. The electrician does think, has his own tools, and his own way of working. That’s A2A: an agent talking to another agent. Different kinds of talking, so you need different rules for each — and you use both on the same job.
“Versus” is the wrong question
☺ Like you’re 10: Asking “hammer versus telephone — which one wins?” makes no sense. You use the hammer on the nail and the phone on your friend. They’re for different jobs, so nobody wins.
Search for “MCP vs A2A” and you will find a great deal of writing framing these as rivals in a standards war, with a winner to be crowned. That framing is wrong, and unusually for a contested tech question, one side says so in writing — A2A’s own documentation devotes a page to why the two are complementary. (The courtesy is not returned: the MCP specification never mentions A2A at all. That silence is not disagreement — MCP simply scopes itself to context exchange and leaves agent-to-agent coordination out.)
A2A’s documentation puts the distinction in terms of what an agent is interacting with: A2A is about agents partnering on tasks; MCP is about agents using capabilities. It calls the two “highly complementary,” and the A2A v1.0 announcement carries the heading “Complementary to MCP, not a replacement.” The MCP documentation draws the same boundary from its side: MCP “focuses solely on the protocol for context exchange” — it defines no mechanism at all for one agent to discover or delegate to another.
The two axes
☺ Like you’re 10: Think of a plus sign. Going down is reaching for your tools. Going across is talking to a teammate. Every agent does both, and there’s a rulebook for each direction.
Everything clicks into place once you see that these protocols live on different axes, not different rungs of a ladder:
The A2A documentation offers an analogy worth stealing: an auto repair shop. You talk to the shop manager — multi-turn, conversational, negotiating an outcome you can’t fully specify up front (“the car’s making a noise”). That conversation is A2A. The mechanic then picks up a diagnostic scanner and a lift — structured, bounded, no negotiation. Those are MCP tool calls. And when the shop needs a part it doesn’t stock, its agent talks to a parts-supplier agent: A2A again. One job, both protocols, no conflict.
Ask what is on the other end of the connection. A primitive with a fixed contract — a database, an API, a file system — is a tool, so you want MCP. Something that reasons, plans, holds state across a long task, and may say no — that’s a peer, so you want A2A. Modeling a reasoning peer as a stateless tool call is the classic beginner mistake.
A2A: the horizontal axis
☺ Like you’re 10: Before you can work with someone new, you need to know who they are and what they’re good at. A2A gives every agent a little “business card” on the internet saying what it can do, and then a shared to-do ticket you both watch while the work gets done.
A2A (Agent2Agent) was announced by Google in April 2025 with more than 50 launch partners, and donated to the Linux Foundation in June 2025 — so despite the origin, it is not “Google’s protocol” any more than MCP is Anthropic’s. Its technical steering committee seats eight organizations — AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow — so Google holds one vote of eight. Version 1.0 landed in March 2026. Four ideas carry the whole design:
- The Agent Card. An agent publishes a JSON document at a well-known HTTPS path —
/.well-known/agent-card.json— describing its identity, its skills, which transports it speaks, and how to authenticate. This is discovery: you find out what an agent can do by fetching a URL, not by reading its documentation. Cards can be cryptographically signed. - The Task. Work is a stateful, long-running object with a lifecycle — not a request/response. A task moves through states (submitted, working, input-required, completed, failed, canceled) and both sides can watch it. This is the key difference from a tool call: an A2A task can run for hours and can stop to ask you a question.
- Messages, Parts and Artifacts. A Message is one turn in the conversation; it’s made of Parts (text, files, structured data) so multimodal content travels in one envelope; an Artifact is a durable output the task produced.
- Transport bindings. A2A defines JSON-RPC 2.0, gRPC, and HTTP+JSON/REST bindings, plus room for custom ones. No single transport is mandated, but every binding must be functionally equivalent — the same operations with the same semantics. The Agent Card’s
supportedInterfaceslist advertises which ones an agent speaks, in preference order — the first entry is the preferred one.
Long-running work is a first-class concern. If a task will outlive an HTTP connection, A2A supports streaming updates over Server-Sent Events and push notifications to a webhook — both advertised as capabilities on the Agent Card, so a client knows in advance what it can rely on.
The ACP trap
☺ Like you’re 10: Imagine four different kids in your class are all nicknamed “Alex.” If someone says “ask Alex,” you have to figure out which Alex first. “ACP” is like that — three totally different things share the nickname.
Here is the part most articles get wrong, and the reason this lesson exists. “ACP” currently refers to at least four unrelated protocols, and the one that most “MCP vs A2A vs ACP” comparisons mean has not existed as an independent standard since August 2025.
| Which “ACP” | Who | What it actually does | Status |
|---|---|---|---|
| Agent Communication Protocol | IBM Research (the BeeAI team) | Agent-to-agent, deliberately REST-shaped rather than JSON-RPC, async-first, with offline discovery via package metadata. The direct A2A alternative. | Merged into A2A under the Linux Foundation, announced August 2025. Repository archived; final release v1.0.3. Its own site now says “ACP is now part of A2A.” |
| Agent Client Protocol | Zed Industries, now co-developed with JetBrains | Editor ↔ coding agent. Your IDE runs the agent as a subprocess; the agent calls back for file reads/writes, terminals, and permission prompts. Think “LSP for agents.” | Alive and growing fast — JetBrains brought it to the IntelliJ family, and a shared agent registry lists Claude Code, Codex CLI, Copilot CLI, Gemini CLI and others. A different axis entirely from the other two. |
| Agentic Commerce Protocol | OpenAI + Stripe | Buyer ↔ AI agent ↔ merchant checkout flows; the merchant stays merchant of record. Powers instant-checkout experiences. | Alive — nothing to do with any of the others. |
| Agent Connect Protocol | AGNTCY (originally Cisco Outshift), Linux Foundation | A REST/OpenAPI interface for invoking and configuring a remote agent — auth schemes, configuration, and an Agent Manifest describing its capabilities. | Alive — part of the AGNTCY discovery stack described below. |
An enormous amount of mid-2025 blog content presents a genuine three-way MCP/A2A/ACP horse race — and much of it still ranks well in search. That comparison has been obsolete since IBM’s ACP folded into A2A. If you are reading a protocol comparison, check its date first, and check which ACP it means. This is the single most likely thing to get wrong about agent protocols in 2026.
The merge itself is the interesting lesson: IBM’s ACP made real design arguments — plain REST instead of JSON-RPC so ordinary proxies and load balancers work unmodified, async-first execution for long jobs, and offline discovery for air-gapped or scale-to-zero deployments. Rather than sustaining a parallel standard, the team brought those concerns into A2A’s governance, taking a seat on its technical steering committee. Consolidation, not defeat.
Side by side
☺ Like you’re 10: Here are the live rulebooks on one page — who they connect, how they find each other, and what a single job looks like in each.
With the ambiguity cleared up, the honest comparison is between two live, complementary protocols — plus the third axis the Agent Client Protocol occupies:
| MCP | A2A | Agent Client Protocol | |
|---|---|---|---|
| Connects | Agent → tools & data (down) | Agent ↔ agent (across) | Editor → coding agent (out) |
| Other end is | A primitive with a fixed contract | A reasoning peer with its own agenda | An agent running as a subprocess |
| Discovery | tools/list after an initialize handshake | Agent Card at /.well-known/agent-card.json | Editor launches the agent directly |
| Unit of work | A tool call — request, response | A Task — stateful, long-running, resumable | A prompt turn, with callbacks into the editor |
| Wire format | JSON-RPC 2.0 over stdio or Streamable HTTP | JSON-RPC, gRPC, or HTTP+JSON — equivalent bindings | JSON-RPC 2.0 over the subprocess pipe |
| Stewardship | Agentic AI Foundation (Linux Foundation), Dec 2025 | Linux Foundation, June 2025 | Zed Industries with JetBrains, Apache-licensed |
| Reach for it when | You want one integration usable by every AI client | You’re crossing a team or vendor boundary | You’re wiring a coding agent into an editor |
A common objection — “isn’t MCP just Anthropic’s thing, and A2A just Google’s?” — is out of date. Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation entity, in December 2025 (co-founded with Block and OpenAI, with AWS, Bloomberg, Cloudflare, Google and Microsoft among its members). Google donated A2A to the Linux Foundation in June 2025. Both are governed in the open; adopting either is not a bet on one vendor.
Foxy: So which one wins — MCP or A2A? I want to learn the one that survives.
Olly the Octopus: Wrong question, Foxy! I use eight arms at once. One arm reaches down for a tool — that’s MCP. Another reaches across to a teammate — that’s A2A. I don’t pick.
Pip the Hummingbird: And I fly both routes! Down to a tool I carry a tidy little order form. Across to another agent I carry a whole conversation — one that might take days and come back with questions.
Foxy: Then what about ACP? My article says there are three.
Timmy the Turtle: Check the date on that article. The ACP it means joined A2A back in August 2025. At least three other things are also called ACP — one for editors, one for shopping, one for agent discovery. Always ask which one before you compare.
Professor Owl: Well caught, Timmy. Class — in a field this young, half of learning a standard is learning when what you read was true.
The rest of the alphabet soup
☺ Like you’re 10: Beyond “talk to a tool” and “talk to a teammate,” there are helpers for other jobs: a phone book for finding agents, and a rulebook for letting an agent spend money safely.
You will meet more acronyms. Almost none of them compete with MCP or A2A — they fill gaps those two deliberately leave open:
- AGNTCY — originally from Cisco, donated to the Linux Foundation in 2025. Infrastructure beneath the protocols: a decentralized agent directory (“DNS for agents”), an identity service, and a schema framework. A2A agents and MCP servers are discoverable through it.
- AP2 (Agent Payments Protocol) — Google plus 60-odd payment partners, adding the payments layer A2A deliberately omits. Uses cryptographically signed Mandates that bound what an agent is allowed to buy and spend.
- ANP (Agent Network Protocol) — a community effort toward fully decentralized, W3C DID-based agent identity. Intellectually influential, common in academic surveys, far less deployed. Worth knowing the name.
- AGENTS.md — not a protocol at all. A convention for a file in your repository telling coding agents how to work in that codebase, donated by OpenAI as a founding Agentic AI Foundation project. You will see it grouped with protocols; it’s a file format.
These protocols standardize message shape, discovery, and transport. They do not give you an authorization policy, a durable agent identity, or an audit trail. “We use A2A” is not a security posture. The trust boundary you cross when you delegate a task to someone else’s agent is exactly as dangerous as the one in AI Security — an agent that reasons over untrusted input and can act is the pattern to fear, and it does not stop being that because the message was well-formed. Separate projects exist precisely to fill these gaps.
Choosing, in practice
For a concrete integration, the decision is usually quick:
- Wrapping a database, an internal API, a file store, a SaaS product? Build an MCP server. One integration, every AI client can use it.
- Exposing something your team’s agent can do, to another team’s agent — possibly at another company? Publish an Agent Card and speak A2A. You get discovery, long-running tasks, and a real trust boundary.
- Coordinating several agents you own, inside one process? You may need neither. A framework’s in-process handoffs (see Multi-Agent Systems) are simpler than a network protocol. Reach for A2A when you cross a process, team, or vendor boundary — that’s the problem it’s paid to solve.
And a caution that applies to both: “supports MCP” or “supports A2A” is not a binary. It can mean a full implementation, or read-only tool calls behind an enterprise allowlist. Check the specific features you need, not the logo on the compatibility page.
These specs are moving fast. MCP’s current revision is 2025-11-25. A substantial revision, 2026-07-28, was locked as a release candidate in May 2026 and is scheduled to become current on 28 July 2026 — it makes the protocol core stateless and reworks several primitives, so if you are reading this after that date, expect 2026-07-28 to be the live one. A2A is at v1.0.1. Any tutorial written against an older MCP revision may teach concepts that have since been deprecated. When you build, read the spec site, not a blog post — modelcontextprotocol.io and a2a-protocol.org. True at time of writing.
Make the two axes concrete. (a) Read a real Agent Card. Find a public A2A agent and fetch its /.well-known/agent-card.json — note its skills, its supportedInterfaces list, and its auth scheme. Ask yourself what you now know about it that you could not have learned from an MCP tools/list. (b) Classify five integrations. For each — a Postgres database, a colleague’s résumé-screening agent, your company’s Slack, a partner company’s pricing agent, a local file folder — write down MCP or A2A and one sentence of justification. (c) Date-check an article. Find any “MCP vs A2A vs ACP” post, note its publication date, and identify at least one claim in it that is no longer true.
(1) State the one-line test for choosing between MCP and A2A. (2) What is an Agent Card, where does it live, and what does it replace? (3) Name the protocols called “ACP” and say which is no longer independently maintained. (4) Why is “which protocol will win?” the wrong question — and what evidence settles it? (5) Give one thing these protocols explicitly do not provide.
Check your answers
- The one-line test: Look at what is on the other end. If it is a primitive with a fixed contract that does not reason — a database, an API, a file system — use MCP. If it reasons, plans, holds state across a long task and may push back, it is a peer: use A2A. Treating a reasoning peer as a stateless tool call is the classic beginner error.
- The Agent Card: A JSON document an agent publishes at the well-known path
/.well-known/agent-card.json, listing its identity, skills, transportsupportedInterfaces, and authentication requirements — optionally signed. It replaces reading documentation or hand-configuring an integration: discovery becomes fetching a URL. - The ACPs — there are at least four: IBM Research’s Agent Communication Protocol (agent-to-agent, REST-based — merged into A2A under the Linux Foundation in August 2025, repository archived, no longer independently maintained); Zed’s Agent Client Protocol (editor ↔ coding agent, alive); OpenAI/Stripe’s Agentic Commerce Protocol (agent-mediated checkout, alive); and AGNTCY’s Agent Connect Protocol (a REST/OpenAPI interface for invoking and configuring remote agents, alive). Only the first is defunct.
- Why “which wins” is wrong: They occupy different axes — MCP connects an agent down to tools, A2A connects it across to peers — and a production agent typically speaks both simultaneously. The evidence is the specs’ own documentation: A2A frames it as agents partnering (A2A) versus using capabilities (MCP), calls the two “highly complementary,” and titles a section “Complementary to MCP, not a replacement.”
- What they don’t provide: Authorization policy, durable agent identity, and auditability — they standardize message shape, discovery, and transport only. (Also acceptable: they don’t define how an agent reasons or plans, and protocol support does not imply feature parity between implementations.)