Agent Client Protocol vs MCP: What's the Difference (2026)

Agent Client Protocol (ACP) standardizes how a code editor talks to an AI coding agent running as a separate process, covering session setup, streaming updates, file edits, and permission prompts. Model Context Protocol (MCP) standardizes something else entirely: how an agent connects to tools and data sources. They sit at different layers of the same stack, and on a wire level ACP even reuses MCP's JSON types where it can. Most setups running both aren't choosing between them. They're using both at once.

That's worth saying up front because the two names get mixed up constantly, and the confusion has a second layer: there's an unrelated protocol also called "ACP," the Agentic Commerce Protocol from OpenAI and Stripe, built for AI checkout. Different spec, different governance, same three letters. We cover that one separately in our Agentic Commerce Protocol post. This piece is about the editor-agent protocol only.

What Agent Client Protocol actually is

ACP is an open protocol, originally published by Zed Industries in September 2025, that standardizes communication between code editors and coding agents. The editor is the "client." The agent, whether that's Claude Code, Gemini CLI, Codex CLI, or something else, is a separate process the editor launches and talks to over JSON-RPC. Zed's own docs describe the goal in one line: agents that implement ACP work with any compatible editor, and editors that support ACP get the entire ecosystem of ACP agents, without either side building custom glue for the other.

The comparison Zed reaches for is the Language Server Protocol. Before LSP, every editor had to write its own integration for every programming language's tooling: one for Python in VS Code, a different one for Python in Sublime, a different one again in Vim. LSP fixed that by giving every editor a single interface to speak to any language server. ACP is doing the same job for AI coding agents. Before it, "Claude Code inside Zed" or "Gemini CLI inside Neovim" each needed a bespoke integration. After it, one implementation on the agent side and one on the editor side is enough for every pairing.

Why it exists: the N-times-M problem

Picture the editors: Zed, Neovim, Emacs, JetBrains's IDE lineup, VS Code, Sublime Text. Now picture the agents: Claude Code, Gemini CLI, Codex CLI, GitHub Copilot, Goose, and a growing list of smaller ones. Without a shared protocol, every editor-agent pair is its own integration project. Add one new agent and every editor maintainer has to build support for it separately. Add one new editor and every agent maintainer has to do the same in reverse. That's the N-times-M problem, and it's exactly what killed a lot of early "bring your own agent" ambitions in 2024 and 2025.

ACP collapses that grid into N-plus-M. An agent builder implements ACP once. An editor builder implements ACP once. Every combination just works, the same logic that made LSP and, before it, HTTP, worth standardizing.

The core mechanism

Under the hood, ACP is JSON-RPC 2.0. The editor launches the agent as a subprocess and the two talk over stdin and stdout: the editor writes JSON-RPC messages to the agent's stdin, the agent writes responses and notifications to its stdout. That's the transport that both sides are expected to support. A Streamable HTTP transport for remote agents is listed in the spec as a draft proposal still in discussion, not something you can rely on in production today.

A session runs through a fixed sequence. The client calls initialize to negotiate protocol versions and capabilities, authenticates if the agent requires it, then opens a session with session/new (or resumes one with session/load, if the agent supports it). From there the client sends a session/prompt with the user's message, and the agent streams back session/update notifications as it works: message chunks, tool calls, plan updates, diffs. If the agent wants to edit a file or run a command, it can send a request back to the client, for example asking permission before a tool call executes, because ACP's JSON-RPC channel is bidirectional. The user stays in the loop on anything the agent wants to do to their machine.

One detail matters for anyone who already runs MCP servers in their editor: ACP is explicitly built to sit alongside them, not replace them. The spec's own architecture page says the editor commonly has user-configured MCP servers, and when it forwards a prompt to the agent it passes along the MCP server configuration so the agent can connect to those servers directly. If the editor wants to expose its own capabilities as MCP tools, it runs a small local MCP server and hands the agent that connection info too. ACP isn't trying to own the tool-calling layer. It's explicitly designed to hand that job to MCP and stay out of the way.

Real adoption vs announced adoption

This is where a lot of protocol posts get generous. Here's what's actually shipping as of mid-2026, based on the protocol's own maintained lists, not press releases.

Editors with native or first-party support: Zed built ACP and ships it natively as its agent panel. JetBrains committed to co-developing the protocol in October 2025 and has since shipped ACP support across its IDE lineup (IntelliJ IDEA, PyCharm, WebStorm, and the rest) through its AI Assistant.

Editors with real community implementations: Neovim has several independent plugins (CodeCompanion, avante.nvim, agentic.nvim, hermes.nvim). Emacs has agent-shell. Sublime Text, Qt Creator, Obsidian, and Pulsar all have working ACP clients built by their communities rather than the vendor. VS Code has multiple third-party ACP extensions, but no first-party Microsoft implementation as of this writing, which is a meaningfully different claim than "VS Code supports ACP."

Agents with real support: Gemini CLI was the original launch partner and remains the reference implementation. Claude Code runs through an open-source adapter Zed built and maintains, translating the Claude Agent SDK into ACP's JSON-RPC shape. Codex CLI has an adapter too. Goose (Square's open-source agent) implemented ACP natively. GitHub Copilot CLI added ACP support in public preview in January 2026.

The distribution layer: In January 2026, Zed and JetBrains shipped an ACP registry, a shared catalog so an agent maintainer registers their implementation once and it becomes installable from any ACP-compatible client without a separate submission per editor. That's a genuine sign of the ecosystem maturing past "the two companies that built it," even though Zed still runs the blog and drives most of the public communication.

Governance: the protocol now lives under its own GitHub organization, separate from Zed's own repos, with public meeting notes and SDKs in Rust, TypeScript, Python, Kotlin, and Java maintained there. It's not a neutral standards body the way, say, the JSON-RPC spec is, but it's also no longer just an internal Zed project. JetBrains is a genuine co-developer with commits and a stated roadmap, not a logo on a launch page.

Read that adoption list for what it is: strong for a protocol that shipped a year ago, concentrated among a handful of committed vendors, and still missing first-party buy-in from Microsoft and a couple of the largest editor players.

Agent Client Protocol vs MCP: the actual difference

Here's the distinction the rest of this post has been building toward, stated plainly.

MCP standardizes agent-to-tool communication. It defines how a model or agent connects to external data and tools: databases, APIs, file systems, SaaS products. If you want the model to read a Notion page or call a Stripe API, MCP is the layer that makes that connection portable across hosts. We cover this in depth in our MCP explainer, including how MCP Apps extends it to render interactive UI instead of plain text.

ACP standardizes editor-to-agent communication. It defines how the application you're typing in talks to the AI process doing the coding work: starting sessions, streaming progress, requesting file edits, asking permission before running something. It doesn't care what tools the agent uses internally. It cares about the conversation between the editor and the agent process itself.

Put the two side by side and the boundary is clean: MCP is inside the agent, connecting it outward to tools and data. ACP is outside the agent, connecting it upward to the editor's UI. A single ACP session can have the agent calling out to a dozen MCP servers in the background, and neither protocol needs to know the other exists at that layer, they just happen to share JSON conventions because Zed built ACP to reuse MCP's types instead of inventing a parallel format.

That makes "ACP vs MCP" a slightly misleading framing if it's read as either-or. They're not competing for the same job. A coding agent built today is likely to speak both: ACP so it can run inside any editor that adopts it, MCP so it can reach any tool a user has configured. If you're deciding what to build, the actual question isn't which protocol to pick. It's whether you're building the thing the editor talks to (ACP) or the thing the agent talks to (MCP), and most serious coding-agent projects end up needing both.

FAQ

Is Agent Client Protocol the same as MCP? No. MCP connects an agent to tools and data. ACP connects an editor to an agent process. They operate at different layers and are usually used together, not as alternatives.

Who created ACP? Zed Industries published it in September 2025, launching with Google as a partner for the Gemini CLI integration. JetBrains joined as a co-developer in October 2025. The protocol now lives in its own GitHub organization with a small multi-vendor governance group, though Zed still leads day-to-day development and communication.

Is the "ACP" in this post the same as the Agentic Commerce Protocol? No, and this is a genuinely confusing overlap. Agentic Commerce Protocol is OpenAI and Stripe's separate spec for AI-driven checkout, unrelated to code editors. See our breakdown of that protocol if that's the one you're looking for.

Does Claude Code support ACP natively? Not built in. It runs through an open-source adapter that Zed built and maintains, which wraps the Claude Agent SDK and translates its behavior into ACP's JSON-RPC messages. That's how Claude Code shows up in Zed, and any other ACP client, including several Neovim plugins.

Does VS Code support ACP? Not officially. There are several third-party extensions that add ACP client support to VS Code, but Microsoft hasn't shipped first-party support as of mid-2026.

Can an agent use ACP and MCP at the same time? Yes, and that's the common case, not an edge case. The editor forwards its configured MCP servers to the agent over the ACP connection, so the agent can call those tools directly while still reporting everything back to the editor through ACP's session updates.

Does ACP replace function calling or tool-calling APIs? No. Those live inside the agent's own model-calling logic, same as they always did. ACP sits a level above that, between the finished agent and the editor UI showing its work.