Agent Client Protocol vs MCP (2026)
Two protocols, two JSON-RPC interfaces, two very similar acronyms — and a lot of people treating them as rivals. They aren’t. The Model Context Protocol connects an agent to its tools and data. The Agent Client Protocol connects an editor to an agent. They sit on opposite sides of the agent and are built to run at the same time. This is the neutral walk-through of what each is for, where the line falls, and how the 2026 IDE wars made the distinction suddenly matter.
On this page · 10 sections▾
TL;DR — they’re two layers, not two options
- MCP is the agent-to-tools layer. The Model Context Protocol lets an agent reach file systems, APIs, databases, and SaaS apps through a standard set of tools, resources, and prompts. It answers the question “what can the agent reach?”
- ACP is the editor-to-agent layer. The Agent Client Protocol, created by Zed, lets a code editor host any agent inside its UI — diffs, approval prompts, follow-the-cursor session views. It answers the question “where does the agent live in my editor?”
- An agent usually speaks both at once. It is an ACP server to the editor and an MCP client to its tools, in the same session. ACP even reuses MCP’s JSON shapes where it can, so they interoperate by design.
- So “ACP vs MCP” is the wrong framing. It’s not a fork or a competition. It’s a stack. The only real question is which side of the agent you’re building on.
Why people confuse them
The confusion is understandable and almost entirely surface level. The names rhyme. Both protocols carry the word “protocol.” Both speak JSON-RPC. Both showed up inside roughly a year of each other, both ride the same agent hype wave, and both promise to collapse an N×M integration mess into something linear. If you only skim the headlines, they look like two attempts at the same job.
They’re not, and the cleanest way to see it is to put the agent in the middle and draw an arrow on each side. On the tools side of the agent sits MCP: the agent is an MCP client, and it connects out to MCP servers that wrap your GitHub, your database, your Linear, your file system. On the editor side of the agent sits ACP: now the agent is an ACP server, and the editor is the ACP client that drives it. Same agent, two boundaries, two protocols. Neither one can do the other’s job, because they’re pointed in opposite directions.
The community framing that stuck in 2026 is the LSP analogy, and it works for both — which is part of why people blur them. MCP is “LSP for tools”: one protocol so every agent can reach every tool. ACP is explicitly “LSP for agents”: one protocol so every editor can host every agent. Same shape of win, opposite end of the pipe.
Side-by-side matrix
The dimensions that actually separate them. Cells are drawn from each protocol’s own docs and primary launch material — sourced at the bottom.
| Dimension | ACP (Agent Client Protocol) | MCP (Model Context Protocol) |
|---|---|---|
| Boundary it standardizes | Editor ↔ agent | Agent ↔ tools / data |
| Question it answers | Where does the agent live in my editor? | What tools and data can the agent reach? |
| Roles | Editor = client, agent = server | Agent = client, tool wrapper = server |
| Origin | Zed Industries, August 2025; Apache-licensed | Anthropic, late 2024; open spec |
| Transport | JSON-RPC over stdio (local subprocess); HTTP / WebSocket for remote (WIP) | JSON-RPC over stdio or Streamable HTTP |
| Core primitives | Sessions, prompts, diffs, permission requests, editor UX events | Tools, resources, prompts |
| What it gives the agent | An editor / IDE surface to run inside | Tools and data to act on |
| Reuses the other? | Reuses MCP's JSON representations where possible | Unaware of ACP; tool-side only |
| Who implements it | Editor authors + agent authors | Agent authors + tool / service authors |
Read the matrix top to bottom and the pattern is obvious: every row is a mirror image, not a competition. The roles even flip — the agent is the server in ACP and the client in MCP. That role swap is the whole story in one detail. A single binary plays both parts at the same time, which is only possible because the two protocols never touch the same boundary.
ACP — what it actually is
The Agent Client Protocol is the newer and less familiar of the two, so it’s worth getting precise. Its own documentation describes it as a protocol that “standardizes communication between code editors/IDEs and coding agents.” Zed Industries built it and released it in August 2025, under the Apache license, and the motivation is the LSP story almost verbatim: before LSP, every editor needed a custom integration for every language; before ACP, every editor needed a custom integration for every agent. ACP collapses that.
Mechanically, it’s JSON-RPC. For a local agent, the editor launches the agent as a subprocess and exchanges messages over stdio; for remote agents the protocol defines HTTP and WebSocket transports, though its docs note that “full support for remote agents is a work in progress.” The message types go beyond raw text: ACP carries sessions, prompts, streamed responses, file diffs the editor can render and approve, and permission requests the user can grant or deny — the UX vocabulary an editor needs to show an agent working in place. Where it can, ACP “re-uses the JSON representations used in MCP,” adding custom types only for coding-specific UX like diffs.
Zed’s own framing is the cleanest pitch for why this matters: “Any agent that speaks ACP can plug into a powerful UI, where the user can follow the agent around the codebase as it works.” And to prove there’s no first-party tilt, Zed rewired its own in-house agent to run on the same ACP code paths as third-party agents. The early reference agents were Gemini CLI and Claude Code (now Claude Agent); on the editor side the list has grown to include JetBrains IDEs, Neovim, Emacs, marimo, Obsidian and more, with agents like Goose, OpenHands, Qwen Code and GitHub Copilot CLI on the other end. Membership shifts month to month, so treat any roster as a snapshot of mid-2026, not a fixed set.
MCP — the other layer
We cover MCP in depth elsewhere, so here it’s only worth drawing the contrast. The Model Context Protocol is the agent-to-tools standard: a server wraps a capability — a GitHub account, a Postgres database, a Linear workspace, a browser — and exposes it as tools, resources, and prompts over JSON-RPC. The agent, acting as an MCP client, discovers those tools and calls them. MCP says nothing about where the agent runs or which editor a human is watching from. It doesn’t need to. Its job ends at the tool boundary.
That boundary is also where MCP’s own hard problems live — authenticating a remote server, scoping what a tool can touch, keeping tool definitions from eating the context window. If you want the security side of the tool boundary, our OAuth 2.1 for remote MCP servers explainer covers the auth model in detail. None of that overlaps with ACP, because ACP never reaches the tools — it stops at the editor.
How they stack together
The most useful mental model is a single session with the agent in the middle wearing two hats. Picture a developer in an ACP-capable editor who picks an agent from a menu and asks it to fix a failing test.
- The editor launches the agent and speaks ACP to it — opening a session, streaming the prompt, and getting back diffs and permission requests it renders inline. Here the editor is the client and the agent is the server.
- As part of starting that session, the editor hands the agent the MCP server endpoints it should use. Now the same agent turns around and acts as an MCP client, connecting to a GitHub server, a file-system server, a test-runner server.
- The agent reads the repo and runs the test through its MCP tools, decides on an edit, and proposes the change back to the editor as an ACP diff. The human approves it in the editor’s UI — an ACP permission event — and the edit lands.
Two protocols, one workflow, zero overlap. ACP moved the intent and the UX between human and agent; MCP moved the actual work between agent and tools. Swap the editor and ACP keeps working. Swap the agent and both keep working. Swap a tool and only the MCP side changes. That independence is the entire payoff of splitting the stack into two standards instead of one god-protocol — and it’s why the portability conversation around agents keeps coming back to both, as our cross-agent portability piece gets into.
It also rhymes with a pattern playing out one layer up in the chat clients: a separate effort to standardize the UI surface an MCP server can render inside an AI app. If you’re tracking how the standards are layering across the whole agent stack, our MCP Apps vs OpenAI Apps SDK explainer covers that adjacent fight. The through-line: 2026 is the year the agent stack stopped being one protocol and became a set of them, each owning one boundary.
The Devin Desktop hook — why this got loud
ACP existed quietly for most of a year before a product launch pushed it into wider view. The backstory: Cognition acquired Windsurf — the IDE’s product, IP, brand, and team — on July 14, 2025. Cognition has not disclosed a price; valuation figures circulating elsewhere are third-party estimates, so treat them as reported, not official.
Then on June 2, 2026, Cognition relaunched Windsurf as Devin Desktop, and its positioning is what made ACP a talking point. The announcement frames the product as “a full IDE with an agent manager built in” and says it “supports Codex, Claude Agent, OpenCode, and any other ACP-compatible agents.” In other words, an IDE selling itself on agent-neutrality — and agent-neutrality, in 2026, means speaking ACP. That’s the news hook, and it’s a clean illustration of the thesis: ACP is the layer an editor adopts to stop being locked to one agent.
Two cautions worth stating plainly. First, ACP is Zed’s protocol, not Cognition’s; a Devin Desktop supporting ACP is adopting an open standard, not launching one, and ACP predates the rebrand by almost a year. Second, none of the Devin Desktop story changes the ACP-vs-MCP relationship one bit. Devin Desktop speaking ACP just means it can host any compliant agent; those agents still reach their tools through MCP exactly as before. The acquisition is context for why you’re hearing “ACP” more often — not a change to what ACP is.
Common confusions to avoid
“ACP is replacing MCP”
The single most common error. They occupy different boundaries and run together in the same session. An agent is an ACP server to the editor and an MCP client to its tools at the same time. There is no migration from one to the other, because they were never doing the same job.
“If I build an MCP server I need to add ACP support”
No. An MCP server lives on the tools side and never sees the editor. ACP is the editor’s and the agent’s concern. Keep building to the MCP spec; ACP-speaking agents pick up your server downstream without you touching ACP.
Assuming ACP gives the agent tools
ACP gives the agent an editor, not tools. It carries diffs, prompts, and permission events — the UX of running in an IDE. The agent still gets its actual capabilities (files, APIs, services) from MCP or built-in tools. Don’t expect ACP to wrap your database.
Treating the support lists as fixed
Both ecosystems move fast. The editor and agent rosters for ACP, and the server catalogue for MCP, change month to month. Any list in a blog post — including this one — is a snapshot. Check each protocol’s own registry before you depend on a specific integration existing.
Frequently asked questions
What is the Agent Client Protocol (ACP)?
The Agent Client Protocol is an open standard, created by Zed Industries and released in August 2025, that standardizes how a code editor or IDE talks to a coding agent. Its own docs put it plainly: it 'standardizes communication between code editors/IDEs and coding agents.' The editor is the client; the agent is the server. ACP uses JSON-RPC — over stdio for a local agent the editor launches as a subprocess, and over HTTP or WebSocket for remote agents (the remote path is still a work in progress). The point is the same one LSP solved for language servers: instead of every editor writing a bespoke integration for every agent, an agent that speaks ACP plugs into any editor that speaks ACP.
Is ACP a replacement for MCP?
No. They sit at different layers and are designed to coexist. MCP connects an agent to tools and data — file systems, APIs, databases, SaaS apps — by exposing tools, resources, and prompts over JSON-RPC. ACP connects an editor to an agent so the agent can run inside the IDE's UI with diffs, permission prompts, and follow-the-cursor session views. An agent typically speaks both: it is an ACP server to the editor and an MCP client to its tools at the same time. ACP even reuses MCP's JSON representations where it can, so the two are deliberately interoperable rather than competitive.
What is the difference between ACP and MCP?
MCP answers 'what can the agent reach?' — it standardizes the agent-to-tools boundary. ACP answers 'where does the agent live in my editor?' — it standardizes the editor-to-agent boundary. A quick way to remember it: MCP gives the agent its tools; ACP gives the agent its editor. Both use JSON-RPC and both reduce N×M integration work to N+M, but they solve that problem on opposite sides of the agent. You generally don't pick one over the other; a fully wired setup uses both at once.
What uses the Agent Client Protocol?
On the editor side, Zed shipped ACP first, and the ecosystem now includes JetBrains IDEs, Neovim, Emacs, marimo, Obsidian, and others, plus a growing list of community clients. On the agent side, Zed's reference implementations were Gemini CLI and Claude Code (now Claude Agent), and the registry has expanded to include agents such as Goose, OpenHands, Qwen Code, GitHub Copilot CLI, and more. The exact membership shifts month to month, so treat any list as a snapshot — check the protocol's own registry for the current set.
Did ACP come from Zed?
Yes. ACP originated at Zed Industries, which built it to make agentic editing in Zed extensible — so a user could switch between agents inside one editor rather than switching editors to chase a particular agent. Zed describes the motivation by analogy to the Language Server Protocol, which 'unbundled language intelligence from monolithic IDEs.' The protocol is open-source under the Apache license, and Zed rewired its own in-process agent onto the same ACP code paths as third-party agents so there's no first-party advantage.
Does an ACP agent still use MCP servers?
In most cases, yes. ACP governs the editor-to-agent channel; it does not give the agent any tools of its own. The agent still reaches files, APIs, and services through MCP (or built-in tools). In a typical ACP session the editor hands the agent the MCP server endpoints it should connect to, so the agent ends up wearing two hats at once — ACP server to the editor, MCP client to the tools. The two protocols compose; they don't overlap.
Is ACP related to the Cognition Windsurf and Devin Desktop news?
It's connected, with caveats. Cognition acquired Windsurf's product, IP, brand, and team on July 14, 2025 (Cognition has not disclosed the price; figures around $250M reported elsewhere are third-party estimates, not official). On June 2, 2026, Cognition relaunched Windsurf as Devin Desktop, and its announcement positions the product as an agent manager wrapped in an IDE that 'supports Codex, Claude Agent, OpenCode, and any other ACP-compatible agents.' So ACP is part of how a 2026 IDE markets agent-neutrality — but ACP itself is Zed's protocol, not Cognition's, and predates the rebrand by nearly a year.
If I'm building an MCP server, do I need to care about ACP?
Mostly no, and that's the clean part. An MCP server exposes tools and data; it doesn't know or care which editor the agent is running in. ACP is the editor's concern, not the tool's. You care about ACP when you're building an agent (you'd implement ACP to be embeddable in editors) or building an editor (you'd implement ACP to host any agent). If you're shipping an MCP server from this directory, you keep building to the MCP spec and let ACP-speaking agents pick you up downstream.
Sources
Agent Client Protocol
- agentclientprotocol.com — Introduction — the “standardizes communication between code editors/IDEs and coding agents” definition, the LSP analogy, the MCP JSON-reuse note, transport details
- github.com/agentclientprotocol/agent-client-protocol — the protocol repo, SDKs, schema, Apache license
- zed.dev/blog/bring-your-own-agent-to-zed — Zed’s launch framing, the “follow the agent around the codebase” quote, Gemini CLI / Claude reference agents
- zed.dev/acp — the editor and agent ecosystem roster (mid-2026 snapshot)
Model Context Protocol
- modelcontextprotocol.io — the MCP spec: tools, resources, prompts, transports
Cognition / Devin Desktop
- cognition.com/blog/windsurf — Cognition’s acquisition announcement (July 14, 2025); no price disclosed
- devin.ai/blog/windsurf-is-now-devin-desktop — the June 2, 2026 rebrand; the “any other ACP-compatible agents” quote
Related on mcp.directory
- /blog/what-is-mcp — the MCP protocol primer
- /blog/mcp-apps-standard-vs-openai-apps-sdk-2026 — the UI-in-chat standards fight
- /blog/oauth-21-for-remote-mcp-servers-streamable-http-explained-2026 — the auth model at the tool boundary
- /blog/cross-agent-skills-cursor-codex-cline-antigravity-gemini-mastra-portability — agent portability across editors