Three protocols. Three different jobs. Here's a clear breakdown so you can stop reading spec docs and start building.
Three months ago, a product manager on our team dropped a question into Slack that derailed our entire afternoon.
"Should we be implementing A2A or ACP alongside MCP? Google has 150 companies on A2A. IBM has ACP under the Linux Foundation. Are we behind?"
We spent four hours reading spec documents, GitHub discussions, and blog posts. Most of them said the same thing: all three protocols are important and complementary.
Which is technically true and practically useless.
Here's what we actually needed to hear, and what this post will tell you: MCP is the only one that matters for 90% of teams right now. A2A becomes important when you're coordinating agents across organizational boundaries. And ACP is no longer a separate choice at all: IBM wound it down and folded it into A2A in August 2025.
That's the answer. The rest of this post is the reasoning.
What each protocol actually does (in plain English)
Before we compare them, let's make sure we're talking about the same things. Each protocol solves a different communication problem.

MCP: How your agent connects to tools
Model Context Protocol, created by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025. The current spec revision is 2026-07-28. Think of it as USB-C for AI agents. Before MCP, every agent-to-tool connection required custom code. Need your agent to read Gmail? Write a custom integration. Need it to query a database? Write another one. Need it to search the web? Another one.
MCP standardizes the plug. One protocol, any tool.
The numbers tell the story. When Anthropic handed MCP to the Linux Foundation's Agentic AI Foundation in December 2025, there were more than 10,000 active public MCP servers and 97M+ monthly SDK downloads across Python and TypeScript. Every major AI lab and IDE ships MCP support: Claude, ChatGPT, Gemini, Cursor, Windsurf, Zed, VS Code.
MCP is the one that matters now. If you're building an agent and you only adopt one protocol, this is the one. In practice, this is what a managed agent does when you add an MCP server to it: it connects as the client, and the server's tools show up next to the agent's built-in connectors.
A2A: How your agent talks to other agents
Agent-to-Agent Protocol, created by Google and also donated to the Linux Foundation. This one is about agents finding each other and delegating work across organizational boundaries.
The key concept is the Agent Card. It's a JSON file hosted at /.well-known/agent-card.json that advertises what an agent can do. Other agents discover it, read the capabilities, and send tasks via HTTP/SSE/JSON-RPC.
Signed Agent Cards (so you can verify an agent is who it says it is) arrived in v0.3.0 in July 2025. A2A v1.0.0 shipped on March 12, 2026 with native multi-tenancy and consistent protocol bindings (JSON-RPC, gRPC, HTTP), and v1.0.1 followed on May 28, 2026. Google, Microsoft, AWS, Cisco, Salesforce, SAP, ServiceNow, and IBM all sit on the project's Technical Steering Committee.
Here's when A2A actually matters: when you need agents built by different vendors to coordinate work. A Salesforce support agent handing off a billing question to a SAP finance agent. A company's internal scheduling agent requesting availability from a vendor's calendar agent. Cross-boundary, cross-vendor, cross-organization.
If all your agents live inside your own system, you probably don't need A2A yet.
ACP: Merged into A2A
Agent Communication Protocol was created by IBM Research for its BeeAI project and contributed to the Linux Foundation. It was a REST-based, HTTP-native standard for lightweight agent-to-agent messaging, aimed at simple request-response patterns inside a controlled environment rather than cross-company delegation.
It's no longer a standalone protocol. On August 25, 2025, the ACP team announced it was "winding down active development" and contributing its technology directly to A2A. IBM Research's Kate Blair joined the A2A Technical Steering Committee, the ACP repo was archived, and BeeAI moved to A2A with an official migration guide.
So if you're comparing A2A vs ACP in 2026, the answer is A2A. ACP's REST-first ideas live on inside it.
One naming trap: "ACP" now also refers to the Agent Client Protocol, a separate open standard for how code editors talk to coding agents. It has nothing to do with IBM's ACP, and it doesn't compete with MCP or A2A.
The real question: which one do you need?

Let's cut through the spec documents and talk about what teams actually need.
If you're building your first agent: You need MCP. Full stop. Your agent needs to talk to Gmail, Slack, databases, APIs, and other tools. MCP is how that happens. (For when to reach for a packaged skill instead of a raw MCP server, see our agent skills vs MCP breakdown.) It has the ecosystem and the tooling support (every major IDE and AI platform).
If you're running 3+ agents that need to coordinate: You probably still just need MCP plus your platform's native orchestration. Most multi-agent patterns (supervisor-worker, pipeline, peer collaboration) work fine within a single platform. A2A becomes necessary when the agents are built by different vendors or live in different organizations.
If you're a large enterprise with agents spanning multiple vendors: Now A2A makes sense. The Agent Card discovery mechanism and task lifecycle management solve real problems when your Salesforce agent needs to delegate to your SAP agent and both were built by different teams with different frameworks.
If you're evaluating ACP: Don't. It merged into A2A in August 2025, and even IBM's BeeAI platform now speaks A2A. Existing ACP agents have a documented migration path.
Most teams need MCP today, will consider A2A in 12 months, and will never need a third protocol.
The part most comparison articles get wrong
Every protocol comparison I've read treats MCP, A2A, and ACP as three options to choose between. They're not.
They're layers in a stack.
MCP handles the bottom layer: agent-to-tool connections. A2A handles the layer above: agent-to-agent coordination across boundaries. ACP used to offer a lighter alternative to A2A, but that layer has now consolidated into A2A.
The industry consensus (and we agree) is multi-protocol coexistence. Google adopted MCP across its own services in December 2025 while simultaneously pushing A2A for inter-agent communication. That's not contradiction. That's using different tools for different jobs.
The real question isn't "which protocol do I pick." The real question is: "how much protocol complexity do I want to manage myself?"
And that's where the choice gets interesting.
If you're a development team comfortable with spec documents and protocol adapters, you can absolutely implement MCP servers, wire up A2A Agent Cards, and configure the whole stack manually. It's well-documented. It's open-source. It works.
But if you'd rather skip the protocol layer entirely and just connect your agent to tools... that's a valid choice too.
We built BetterClaw with 200+ verified skills that handle the MCP-layer problem without requiring you to think about MCP at all. You pick a skill (Gmail, Slack, HubSpot, GitHub, whatever), click connect, and the agent uses it. The protocol complexity is abstracted away. Multi-agent orchestration is handled natively at the platform level. Free plan, $49/month on Pro, and you bring your own API keys across 28+ model providers.
That's not a dig at the protocols. They're excellent engineering. It's an acknowledgment that most founders and product managers don't want to become protocol experts. They want working agents.
Side-by-side: MCP vs A2A vs ACP
Here's the comparison table that would have saved us four hours.

| MCP | A2A | ACP | |
|---|---|---|---|
| Created by | Anthropic (Nov 2024) | Google (Apr 2025) | IBM Research (BeeAI) |
| Governance today | Agentic AI Foundation (Linux Foundation) | Linux Foundation | Merged into A2A (Aug 2025) |
| Current version | Spec 2026-07-28 | v1.0.1 (May 2026) | Archived |
| What it connects | Agent to tools (Gmail, databases, APIs) | Agent to agent, across vendors | Agent to agent, inside one environment |
| Transport | JSON-RPC over stdio or Streamable HTTP | JSON-RPC, gRPC or HTTP bindings | REST over HTTP |
| You need it when | Your agent uses any external tool | Agents from different vendors or orgs must coordinate | You don't: migrate to A2A |
| Complexity | Moderate (many pre-built servers) | High (Agent Cards, task lifecycle, discovery, signatures) | n/a |
What's actually coming next
The protocol story isn't over. Three things to watch:
MCP security is the hot topic. A CVSS 9.8 vulnerability was disclosed in May 2026 in an MCP integration (nginx-ui). MCP tool poisoning is a documented attack vector with success rates above 60% in research. (If your tool calls are failing rather than malicious, our MCP debugging guide covers the common fixes.) The spec is maturing fast, but security is the open frontier. This is exactly why BetterClaw's 4-layer security audit for every skill matters. 824 malicious skills have been rejected from our marketplace.
A2A and MCP are converging. Google adopted MCP while pushing A2A. Microsoft is integrating both. The future is almost certainly a single agent that uses MCP to talk to tools and A2A to talk to other agents. The question is who builds the unified developer experience.
The field already consolidated once. We used to list "ACP might get absorbed" here. It did: IBM folded ACP into A2A in August 2025. That leaves two protocols with two clearly separate jobs, which is healthier for everyone building on them.
MCP itself just changed shape. The 2026-07-28 spec revision made MCP stateless: no more initialize handshake or Mcp-Session-Id header, every request carries its own protocol version, and a new server/discover call advertises capabilities. It also deprecated Roots, Sampling, and Logging, and replaced server-initiated requests with a multi round-trip pattern. If you maintain MCP servers, budget time for the upgrade.
Is MCP still needed? The 2026 debate
In September 2026 a post titled "Why MCP Was Always a Bad Idea" hit the Hacker News front page and pulled in more than 300 comments. It's worth knowing both sides, because the answer changes what you build.
The case against MCP. The author's argument: MCP was designed when models were weak. Today's models can read --help, write scripts, and call documented HTTP APIs directly, and most remote MCP servers just wrap APIs that already exist. Stack up enough MCP servers and their tool schemas bloat the context window. The proposed fix is to delete most MCP servers and standardise how agents consume plain HTTP, for example servers returning Markdown when an agent sends Accept: text/markdown.
The case for MCP. The most upvoted replies pushed back hard. Simon Willison's top comment agreed that a terminal agent with unrestricted internet access can skip MCP, then listed what you lose everywhere else: control over exactly which services an agent can reach, authentication that never hands the agent your raw API keys, a sane UI for users to connect accounts, and audit logs of every call. Others pointed out that agents without shell access (most chat and business agents) can't "just run the CLI", that the one-click connector stores in the ChatGPT and Claude apps are MCP under the hood, and that plenty of sites exposed a usable API for the first time only because MCP made it worth doing.
Where it landed. Roughly: context bloat is a real problem, and CLIs or direct API calls are often the better tool for a coding agent on a developer's machine. But for sandboxed agents, business users, and anything that needs scoped permissions and credential isolation, MCP is still the standard way to do it.
That matches what we see. The permission, credential, and audit layer is the part that matters for agents touching real inboxes and CRMs, whichever wire format sits underneath. It's also why BetterClaw users pick verified skills and connect accounts through OAuth rather than pasting API keys into a prompt.
The honest takeaway
Protocols are plumbing. Important plumbing, but plumbing.
The teams that are actually shipping AI agents right now aren't debating which protocol to implement. They're connecting tools, building workflows, and putting agents in front of real users.
MCP won the tool-connection layer, even if some developers now argue for going without it. A2A won the agent-coordination layer, and absorbed ACP along the way. That's the state of play.
If you want to build on those protocols directly, the documentation is excellent and the ecosystems are real. Go for it.
If you'd rather skip the protocol layer and get your first agent running in the time it took to read this article, give BetterClaw a look. Free plan with 1 agent and 100 credits a month. $49/month for Pro. Your first deploy takes about 60 seconds. We handle the protocol complexity. You handle the part that actually matters to your business.
Frequently Asked Questions
What is the difference between A2A, MCP, and ACP protocols?
MCP (Model Context Protocol) connects your AI agent to external tools like Gmail, databases, and APIs. A2A (Agent-to-Agent) connects agents built by different vendors so they can discover each other and delegate tasks. ACP (Agent Communication Protocol) was IBM's lightweight REST-based agent messaging standard, but it merged into A2A in August 2025. In practice there are now two layers: MCP for agent-to-tool, A2A for agent-to-agent.
How does MCP compare to A2A for AI agents in 2026?
MCP has far larger adoption: it's supported by every major AI lab and IDE, and its current spec revision is 2026-07-28. A2A reached v1.0 in March 2026 and is backed by Google, Microsoft, AWS, Salesforce, SAP, and IBM. They're complementary, not competing. Most teams start with MCP for tool connections and add A2A later when they need cross-vendor agent coordination.
Do I need to implement all three AI agent protocols?
No. Most teams only need MCP. If your agent connects to tools (Gmail, Slack, databases), MCP covers that. Add A2A only when you need agents from different vendors or organizations to coordinate. You don't need ACP at all: it merged into A2A in August 2025. Platforms like BetterClaw abstract the protocol layer entirely through pre-built verified skills.
Is MCP still needed in 2026?
For most agents, yes. A September 2026 Hacker News debate argued that capable models can call CLIs and HTTP APIs directly, and for a coding agent with full terminal access that's often true. But MCP still provides scoped access to services, credential isolation, account-connection UI, and audit logging, which sandboxed and business-facing agents need. The 2026-07-28 spec also made MCP stateless and easier to scale.
How much does it cost to implement MCP for AI agents?
MCP itself is free and open-source. The cost is in implementation time and infrastructure. Building custom MCP servers takes developer hours. Using pre-built servers is faster but requires maintenance. BetterClaw offers 200+ pre-built, security-audited skills (which handle the MCP layer) starting at $0/month on the free plan, with Pro at $49/month.
Is MCP secure enough for production AI agents?
MCP is a well-designed protocol, but the ecosystem has real security gaps. A CVSS 9.8 vulnerability was found in an MCP integration in May 2026, and tool poisoning is a documented attack vector. The protocol itself isn't the risk. The risk is unvetted MCP servers from unknown sources. BetterClaw addresses this with a 4-layer security audit that rejected 824 malicious skills out of 1,024 submitted.




