If you have spent any time reading about AI agents in the last year, you have been hit with an alphabet soup: MCP, A2A, ACP, ANP, AGNTCY, SLIM. They all promise "interoperability." They are not all the same thing, several of them share acronyms with completely unrelated technologies, and the most repeated framing in blog posts — "MCP vs A2A" — sets up a rivalry that does not exist.
This is the map. By the end you will know what each protocol actually does, which layer of the stack it lives at, and which ones are worth your attention versus which are still moving too fast to bet on.
The M×N problem these protocols exist to solve
Every integration standard is born from the same pain. Suppose you have M AI applications (Claude Code, a customer-support agent, an internal research bot) and N things you want them to reach — databases, ticketing systems, file stores, or other agents. Without a shared protocol, you build a custom connector for each pairing: that is M×N bespoke integrations to write, secure, and maintain. Change one tool's API and you patch every app that touched it.
A shared protocol collapses that to M+N. Each application implements the protocol once; each tool or agent implements it once; everything interoperates. This is the exact problem the Language Server Protocol solved for code editors and language tooling, and it is the explicit design goal MCP borrowed from LSP.
The agent ecosystem actually has two M×N problems, on two different axes:
- Agent → tools/data (vertical): one agent needs to reach many tools, APIs, and data sources.
- Agent → agent (horizontal): many independent agents need to discover each other and collaborate.
Different axis, different protocol. That distinction is the whole game.
MCP vs A2A: complementary layers, not rivals
Here is the misconception to kill first. MCP and A2A are not competitors. They sit at the two axes above.
MCP — Model Context Protocol (Anthropic, launched late November 2024) standardizes the vertical axis. It is an open, JSON-RPC 2.0 client-server protocol that lets a single agent or LLM application discover and connect to external tools, data, and prompts in a uniform way — the "USB-C for AI integrations." One agent reaching down to its capabilities.
A2A — Agent2Agent (Google Cloud, announced April 2025) standardizes the horizontal axis. It lets autonomous agents — built on different frameworks like LangGraph, CrewAI, or ADK, and run by different vendors — discover each other's capabilities and collaborate on tasks. Agents reaching across to peers.
The two are designed to stack. A typical system uses MCP so each agent can call its tools, and A2A so those agents can delegate to and coordinate with one another. This is not our spin — Google and the A2A documentation explicitly position A2A as complementary to MCP (the A2A docs ship a dedicated "A2A and MCP" page), and IBM frames its own protocol the same way. If you remember one sentence from this article: MCP is how an agent uses tools; A2A is how agents talk to each other.
A quick note on naming, because it bites people: A2A here means Google's Agent2Agent protocol. It is not the Yamaha/AV receiver "A2A" linking feature, and it is not "account-to-account" (A2A) payments in fintech. Same three characters, three unrelated worlds.
Building an A2A agent? Generate a valid Agent Card manifest (the JSON other agents read to discover yours) from a simple form.
A2A Agent Card Generator
Build a Google A2A (Agent2Agent) Agent Card JSON manifest — name, capabilities, input/output modes, and skills — served at /.well-known/agent-card.json. Copy-ready.
Open the full A2A Agent Card Generator tool →The comparison table
Here is how the three headline protocols line up. Note the ACP row is doing double duty — that acronym hides two completely different specs, covered below.
| Protocol | Maker | Layer / purpose | Transport | Status (mid-2026) |
|---|---|---|---|---|
| MCP (Model Context Protocol) | Anthropic (Dec 2025: Linux Foundation / AAIF) | Agent → tools, data, prompts (vertical) | JSON-RPC 2.0 over stdio or Streamable HTTP (optional SSE) | De-facto standard for agent-to-tool; widest adoption; current spec 2025-11-25 |
| A2A (Agent2Agent) | Google Cloud → Linux Foundation (donated Jun 23, 2025) | Agent ↔ agent collaboration (horizontal) | HTTP + JSON-RPC 2.0; SSE for streaming; webhooks for async | Most-adopted agent-to-agent standard; 100+ backers; maturing |
| ACP (Agent Communication Protocol) | IBM Research / BeeAI | Agent ↔ agent interoperability (overlaps A2A) | REST/HTTP-first (JSON-RPC over HTTP/WebSockets) | Open-source, real but niche; consolidation pressure vs A2A |
| ACP (Agent Client Protocol) | Zed | Editor/IDE/CLI ↔ one agent ("LSP for coding agents") | JSON-RPC 2.0 over stdio | Active and well-scoped; used by Zed, gemini --acp, Neovim |
A brief, honest tour of the rest
The landscape is wider than three names, and most of it is moving fast. Track these, but bet carefully.
ACP — the acronym collision. Two unrelated specs:
- IBM's Agent Communication Protocol came out of IBM Research's open-source BeeAI project. It is an agent-to-agent protocol — a REST/HTTP-first wire format with agent manifests for discovery and structured task envelopes, emphasizing local-first, production-friendly integration. Conceptually it overlaps heavily with A2A, and with both now in the Linux Foundation orbit, expect convergence pressure.
- Zed's Agent Client Protocol is a different layer entirely: it standardizes how a code editor or CLI drives one AI coding agent — the "LSP for AI coding agents," JSON-RPC 2.0 over stdio. It is not about agents talking to each other at all. You see it in the wild as
gemini --acpand in Neovim plugins. (There is even a third ACP — OpenAI and Stripe's Agentic Commerce Protocol for agent-driven checkout — which is about payments, not interop.)
ANP — Agent Network Protocol. Aims to be the "HTTP of the agent internet," and is more decentralized and peer-to-peer than A2A: it is built on Decentralized Identifiers (DIDs) for identity with a layered architecture, and is associated with a W3C Community Group white paper effort. It is the earliest-stage and most speculative of the bunch, with limited production adoption — interesting vision, not a 2026 bet.
AGNTCY / "Internet of Agents." An open-source initiative for the infrastructure layer of multi-agent systems — discovery, composition, deployment, evaluation. Launched by Cisco (Outshift), LangChain, and Galileo, open-sourced March 2025, now a Linux Foundation project with backing from Cisco, Dell, Google Cloud, Oracle, and Red Hat. Its components include OASF (an agent schema/identity framework) and SLIM (secure low-latency agent messaging). Critically, AGNTCY positions itself as plumbing — the DNS/TCP-IP analogy — that can carry A2A and MCP rather than compete with them.
The honest summary: A2A, AGNTCY, and IBM ACP all now sit under Linux Foundation governance. Expect overlap to shrink and boundaries to shift quarter to quarter. The acronym chaos and the consolidation are both real.
Security: the part teams skip
Connecting your agent to arbitrary tools and other agents is exactly as risky as it sounds. MCP in particular has a documented and growing catalogue of attack classes — tool poisoning (hidden instructions in a tool's description), indirect prompt injection via returned content, the confused-deputy problem with broad OAuth tokens, rug pulls where an approved server silently changes its behavior, and command-injection RCE across many community servers. These are not hypothetical: there are verified disclosures from Invariant Labs and Check Point, and assigned CVEs.
If you are wiring up MCP servers — especially unvetted community ones — read our dedicated breakdown first: MCP security risks and how to mitigate them. The short version: allowlist servers, enforce least privilege, keep a human in the loop for irreversible actions, and treat every tool description and every tool output as untrusted input.
Not sure which one you need? Answer a few questions and get a recommendation — MCP, A2A, function calling, or ACP — with what it's for and when to combine them.
Which Agent Protocol Do You Need?
Answer a few questions and get the right agent protocol — MCP, A2A, function calling, or ACP — with what it is for and who built it. MCP and A2A are complementary, and the tool says when to use both.
Open the full Which Agent Protocol Do You Need? tool →How to start today
You do not need to pick a side in a war that does not exist. Start where the adoption and the immediate payoff are: MCP. It is supported across OpenAI, Google, and Microsoft tooling and most agent frameworks, and it solves the concrete problem of giving your agent reliable access to tools and data.
The fastest on-ramp is your existing coding CLI. Our config generators produce a correct mcpServers block (transport, scope, secrets handling, and the field-name gotchas) for each tool:
- Claude Code config generator
- Codex CLI config generator
- Gemini CLI config generator
- Qwen Code config generator
- Oh My Pi config generator
- Ollama config generator
Then walk through the wiring end to end in How to add an MCP server to any AI coding CLI. If you want the conceptual foundation first, start with what the Model Context Protocol actually is and what an MCP server is. And if you are weighing MCP against the other extension mechanisms inside an agent, MCP vs subagents vs skills vs hooks draws those lines.
Add A2A later, when you genuinely have multiple independent agents — across teams or vendors — that need to coordinate. Until then, the horizontal layer is a problem you do not have yet. Get the vertical layer right first.