ACP vs MCP vs A2A: Three Protocols, Three Different Problems

Three Protocols at a Glance

Three open-source specifications. Three different interface boundaries. MCP defines how an agent talks to tools. ACP defines how an agent talks to an editor. A2A defines how an agent talks to another agent. They are layers in a stack, not competitors in a category.

The Mental Model

Each protocol answers a different question from the agent's perspective:

A useful analogy: MCP is like a power strip (connecting to tools). ACP is like a desk (the workspace where work happens). A2A is like a phone line (coordinating with colleagues). You need a desk, you plug into the power strip, and you call your colleagues. None of these replace each other.

Full Comparison Table

This table covers every meaningful dimension across all three protocols. Updated April 2026.

MCP: The Tool Layer

MCP (Model Context Protocol) is the most widely adopted of the three. Anthropic released it in November 2024. Within 17 months, it became the default way AI agents connect to external tools.

What MCP Does

An agent needs to query a database. Without MCP, the developer writes a custom integration: parse the agent's intent, construct the query, execute it, format the response. With MCP, the database exposes an MCP server. The agent calls it using a standard protocol. The same agent can call a GitHub server, a Slack server, or a filesystem server using the same interface.

MCP defines four primitives: Tools (functions the agent can call), Resources (data the agent can read), Prompts (templates for common interactions), and Sampling (server-initiated LLM calls). Most implementations focus on Tools and Resources.

Architecture

MCP uses a client-server model. The agent (or its host application) is the MCP client. Tools and data sources are MCP servers. Communication happens over stdio for local processes or HTTP with Server-Sent Events for remote servers. The 2025-03 spec revision introduced Streamable HTTP, simplifying the remote transport.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({ name: "my-tool", version: "1.0.0" });

server.tool("search_docs", { query: z.string() }, async ({ query }) => {
  const results = await searchDocumentation(query);
  return { content: [{ type: "text", text: JSON.stringify(results) }] };
});

Strengths

• Massive ecosystem. 10,000+ public servers covering databases, APIs, SaaS tools, file systems, and developer tools.
• Simple to implement. A basic MCP server is under 50 lines of code. SDKs exist for TypeScript, Python, Java, Go, C#, and Rust.
• Universal adoption. Claude Code, Cursor, VS Code Copilot agent mode, Windsurf, Cline, Zed, and most other AI coding tools support MCP.
• Works locally. stdio transport means no network, no auth, no latency. The server runs as a subprocess on the same machine.

Weaknesses

• No agent discovery. MCP has no built-in way to find available servers. Users manually configure server connections. Third-party registries like Smithery and mcp.run partially fill this gap.
• Client-initiated only. The server cannot proactively push information to the agent. Notifications exist in the spec but are limited.
• No agent-to-agent. MCP models agent-to-tool relationships. If two agents need to collaborate, MCP has nothing to say about that.
• Auth still maturing. The OAuth 2.1 addition in the 2025-03 spec was overdue. Many servers still rely on API keys passed through environment variables.

ACP: The Editor Layer

ACP (Agent Control Protocol) is the newest of the three. The Zed editor team released it in August 2025 to standardize how AI agents integrate with code editors.

What ACP Does

An AI coding agent running inside Zed needs to do things MCP does not cover: show inline suggestions in the editor, request permission to modify a file, stream partial results as they are generated, display a diff preview before applying changes. These are editor-specific interactions that require a protocol between the agent and the editor itself.

ACP defines this interface. The editor spawns the agent as a subprocess. Communication flows over stdin/stdout using JSON-RPC. The protocol is bidirectional: the editor sends context to the agent, and the agent can request information or permissions back from the editor.

Architecture

ACP uses a subprocess model. The editor is the host. Agents are spawned as child processes. This is identical to how LSP (Language Server Protocol) works: the editor launches a language server as a subprocess and communicates over stdio. ACP applies the same pattern to AI agents.

Session management is built into ACP. The editor tracks which agents are running, their current state, and their permissions. When a user closes a project, the editor can gracefully shut down associated agents.

{
  "id": "my-coding-agent",
  "name": "My Coding Agent",
  "version": "1.0.0",
  "capabilities": ["code-generation", "code-review", "refactoring"],
  "transport": { "type": "stdio" },
  "permissions": ["file-read", "file-write", "terminal-execute"]
}

Strengths

• Real-time streaming. Agents stream partial results as they work. The editor renders output incrementally, similar to how LSP provides real-time diagnostics.
• Permission model. ACP defines structured permission requests. The agent asks to modify a file, the editor shows a confirmation dialog, the user approves or denies. This is cleaner than MCP's tool-level permissions.
• Editor-native features. Inline diffs, progress indicators, diagnostic overlays. ACP agents can use editor UI primitives that MCP servers cannot access.
• Growing editor support. Zed has native ACP support. JetBrains, Neovim, and Emacs have community implementations. VS Code support is in progress.

Weaknesses

• Editor-centric. ACP requires an editor host. Standalone agents (CLI tools, server-side agents, workflow automation) have no use for ACP.
• Smaller ecosystem. 25+ agents compared to MCP's 10,000+ servers. The spec is 8 months old and adoption is still early.
• Subprocess-only transport. No remote execution. The agent must run on the same machine as the editor. This limits deployment options for resource-intensive agents.
• Overlapping concerns with MCP. Some capabilities (file reading, code search) could be exposed through either protocol. The boundary is not always clear.

A2A: The Agent Collaboration Layer

A2A (Agent-to-Agent) is Google's protocol for inter-agent communication. Released in April 2025, it addresses a problem neither MCP nor ACP touches: how do agents built by different vendors discover each other and collaborate on tasks?

What A2A Does

A company has a customer support agent built on LangGraph and a billing agent built on Google ADK. A customer asks the support agent to issue a refund. The support agent needs the billing agent to process it. Without A2A, the developer builds a custom bridge. With A2A, the support agent discovers the billing agent via its Agent Card, sends a task request, and receives status updates as the billing agent processes the refund.

Architecture

A2A defines three core concepts: Agent Cards (capability advertisements served at /.well-known/agent.json), Tasks (units of work with lifecycle states: submitted, working, input-required, completed, failed), and Messages (communication within a task containing Parts like text, files, or structured data).

Communication happens over HTTP using JSON-RPC. For long-running tasks, A2A supports Server-Sent Events for streaming updates and push notifications via webhooks. Version 0.2 of the spec (late 2025) added stateless interactions for simple request/response patterns and standardized authentication.

{
  "name": "Billing Agent",
  "description": "Processes refunds, invoices, and payment disputes",
  "url": "https://billing-agent.example.com",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    { "id": "process-refund", "name": "Process Refund" },
    { "id": "generate-invoice", "name": "Generate Invoice" }
  ],
  "authentication": { "schemes": ["oauth2", "apiKey"] }
}

Strengths

• Agent discovery. Agent Cards at a well-known URL let agents find and understand each other's capabilities. No other protocol provides this.
• Cross-vendor interoperability. A LangGraph agent can delegate to a Google ADK agent can delegate to a CrewAI agent. The protocol is framework-agnostic.
• Task lifecycle. Built-in states (submitted, working, completed, failed, input-required) with streaming updates. Enterprise workflows need this kind of observability.
• Enterprise backing. 50+ launch partners including Salesforce, SAP, Atlassian, ServiceNow, MongoDB, Deloitte. This is the enterprise-grade option.

Weaknesses

• No Anthropic, OpenAI, or Microsoft at launch. The three largest AI providers were not among A2A's initial partners. Anthropic has MCP. Microsoft has Azure AI Agent Service. OpenAI has its own agent SDK. Adoption from these vendors would significantly strengthen A2A.
• HTTP-only transport. No local subprocess execution. Every inter-agent call goes over the network, adding latency. For agents on the same machine, this is unnecessary overhead.
• Enterprise complexity. Agent Cards, capability negotiation, task lifecycle management, push notifications, authentication schemes. A2A is more complex than MCP or ACP because it solves a harder problem. But that complexity raises the barrier to entry.
• Early real-world adoption. Most A2A implementations as of April 2026 are demos and proof-of-concepts. Production multi-agent systems using A2A for cross-vendor communication are still uncommon.

How They Work Together

The key insight: these protocols are complementary layers in an agent stack. They do not compete. A single coding session can use all three.

The Layered Architecture

This layering is not hypothetical. It describes how agent architectures are already evolving. Today, most agents use only MCP because tool integration is the most immediate need. As editor integrations deepen and multi-agent systems mature, ACP and A2A fill the gaps that MCP was never designed to address.

Which Protocol Should You Care About?

Decision Matrix

Practical Recommendations

For most developers in April 2026, MCP is the only protocol that matters immediately. It has critical mass: 10,000+ servers, universal tool support, and a spec that is stable enough for production use.

ACP is worth tracking if you build editor extensions or agents that need rich editor integration. The LSP analogy is apt. LSP took years to become ubiquitous, but once it did, it became the foundation for every language server. ACP could follow the same trajectory for AI agents in editors.

A2A is worth tracking if you work in enterprise environments where multiple agent vendors coexist. The discovery mechanism (Agent Cards) is the most interesting primitive. Whether A2A achieves the cross-vendor adoption it needs depends on whether Anthropic, OpenAI, and Microsoft eventually participate.

Frequently Asked Questions

What is the difference between MCP, ACP, and A2A?

MCP connects agents to tools and data (databases, APIs, file systems). ACP connects agents to code editors (Zed, JetBrains, Neovim). A2A connects agents to other agents (cross-vendor task delegation and capability discovery). They solve different problems at different layers of the agent stack. All three use JSON-RPC, but the relationships they model are distinct.

Does A2A replace MCP?

No. A2A handles agent-to-agent communication. MCP handles agent-to-tool communication. An agent uses MCP to call a database, and A2A to delegate a task to another agent. They are complementary. Google explicitly positions A2A as a companion to MCP, not a replacement.

Does ACP replace MCP?

No. ACP defines the interface between an agent and its editor host (permissions, streaming, UI primitives). MCP defines the interface between an agent and external tools. An ACP-connected agent inside Zed still uses MCP to access tools. ACP is the editor layer; MCP is the tool layer.

Who created each protocol?

Anthropic created MCP (November 2024). Zed Industries created ACP (August 2025). Google created A2A (April 2025). All three are open-source specifications with community governance. MCP has the broadest contributor base. A2A has the largest enterprise consortium.

Can I use all three protocols together?

Yes. A coding agent can run inside Zed over ACP, call tools over MCP, and delegate tasks to other agents over A2A. The protocols are designed for different layers and interoperate naturally. In practice, most agents today use only MCP because tool integration is the most mature use case.

Which protocol has the largest ecosystem?

MCP, by a wide margin. 10,000+ public servers, adopted by every major AI coding tool. ACP has 25+ agents with support in Zed, JetBrains, Neovim, and Emacs. A2A has 50+ enterprise launch partners. Ecosystem size reflects maturity: MCP is 17 months old, ACP is 8 months old, and A2A is 12 months old.

Which transport does each protocol use?

MCP uses stdio for local servers and HTTP + SSE for remote servers (Streamable HTTP in the 2025-03 spec revision). ACP uses stdin/stdout between the editor and agent subprocess. A2A uses HTTP with optional SSE for streaming and push notifications via webhooks. All three chose JSON-RPC 2.0 as the message format.

Is MCP the only protocol I need for building AI agents?

For tool integration, yes. MCP covers connecting your agent to databases, APIs, file systems, and external services. You need ACP if your agent runs inside a code editor and requires editor-native features (inline diffs, permission dialogs, streaming output). You need A2A if your agents must discover and collaborate with agents from other vendors. Most agents today need only MCP.