ACP vs MCP: The Editor-Agent Protocol Explained

If you have tried to figure out the Agent Client Protocol vs MCP question and come away confused, the confusion is the whole problem. They sound like rivals. They are not. ACP connects your code editor to an AI coding agent; MCP connects that agent to tools and data. They sit on opposite sides of the agent and run at the same time. This guide draws the one mental model that makes it click, then gets practical about which editors and agents speak ACP today.

TL;DR: ACP and MCP are complementary

Picture the agent in the middle. On one side is your editor — Zed, Neovim, JetBrains. On the other side are the tools and data the agent reaches for — a database, a filesystem, a web API. ACP wires the editor to the agent. MCP wires the agent to its tools. Both protocols can be active in a single session. There is no "winner" to pick, because they solve different halves of the same workflow.

What is the Agent Client Protocol?

The Agent Client Protocol (ACP) standardizes communication between code editors and coding agents. It was created and open-sourced by Zed Industries in August 2025, and it is now community-governed rather than solely Zed's project.

Technically, ACP uses JSON-RPC 2.0 over stdin and stdout. If you have worked with the Language Server Protocol, the shape is familiar: the editor launches the agent as a subprocess and they exchange JSON-RPC messages over standard streams. That subprocess-and-stdio model is deliberately boring and portable, which is exactly why it can work across many editors.

What is MCP, in one paragraph

MCP, Anthropic's Model Context Protocol, connects an AI agent to external tools and data sources. It gives the agent a standard way to call a database, read a filesystem, or hit a third-party API without a bespoke integration for each one. MCP is about what the agent can reach. That is the fair comparison point: MCP looks outward from the agent to services, while ACP looks inward from the agent to the editor driving it.

ACP vs MCP: the one diagram that makes it click

Here is the mental model as a single line:

Editor ⟶ (ACP) ⟶ Agent ⟶ (MCP) ⟶ Tools & Data

ACP is the left arrow. MCP is the right arrow. The agent is the hinge. And they cooperate directly: when an ACP session starts, the editor passes MCP server endpoints and credentials to the agent, so the agent knows which tools it may use. The editor never talks to the tools itself; it hands the agent what it needs and lets the agent do the reaching. Once you see it as two arrows around one agent, "ACP vs MCP" stops being a versus at all.

How ACP works under the hood

The runtime flow is concrete. Using Zed as the reference implementation:

1. Spawn. Zed launches the agent as a subprocess.
2. Context handoff. At session start, the editor passes codebase context — the file tree, open files, terminal output — plus the MCP server details the agent may use.
3. Streaming. The agent streams token-by-token responses back to the editor's UI, so you see output as it is generated rather than waiting for a full reply.

Because transport is JSON-RPC over stdio, the agent can be written in any language that can read and write standard streams. The protocol is at version 1 today; the version number only increments for breaking changes, while non-breaking additions are handled through capability negotiation. That keeps existing integrations from shattering every time a feature lands.

Editor support in 2026

Support moves quickly, so treat this as a snapshot as of early-to-mid 2026 and check the ACP registry for the current state.

The VS Code line is the one to read carefully: support is community-extension only, not native. If native VS Code support matters to you, verify before you commit.

Agent support: which agents speak ACP

On the other end, the agent ecosystem has grown fast — reportedly 25-plus ACP-compatible agents as of March 2026. Notable ones:

• Gemini CLI — the first external integration.
• GitHub Copilot CLI — native support landed January 2026.
• Goose — Block's open-source agent.
• Claude Code — works via a Zed bridge adapter.
• Cline and OpenHands — both in the compatible set.

The practical upshot: the agentic coding models that plug into these editors are increasingly reachable from whatever editor you already use, without a custom integration per pair.

Why a shared protocol matters

Without a standard, connecting editors to agents is an N×M problem. Five editors and five agents means twenty-five bespoke integrations, each maintained separately, each breaking on its own schedule. A shared wire protocol collapses that to N + M: every editor implements ACP once, every agent implements ACP once, and any editor can talk to any agent. Add a new agent and it works everywhere; add a new editor and every existing agent is instantly available to it.

That math is why the ecosystem grew from a single Zed integration to 25-plus compatible agents so quickly. Each new implementer expands the reach of everyone already in the set, which is the network effect a good protocol is supposed to create.

That is the same argument that made LSP succeed for language tooling. "Any editor, any agent" is only possible if they agree on how to talk, and ACP is that agreement for the editor-to-agent link — while MCP plays the same role on the agent-to-tools side. If you are choosing which model to run behind the agent, our live model leaderboard compares the models behind each agent.

Try it: wiring an external agent into Zed

A quickstart mental model for Zed, the fullest implementation:

1. Install or update Zed (Zed reached version 1.0 on April 29, 2026 and is open source).
2. Pick an ACP-compatible agent — Gemini CLI is a common first choice as the original external integration.
3. Configure Zed to launch that agent; Zed spawns it as a subprocess and hands over your codebase context at session start.
4. Start a session and watch responses stream into Zed's UI token by token.

Because the transport is standardized, the same "add an external agent" flow generalizes across ACP-capable editors. Check each editor's docs and the ACP registry for exact configuration, since details differ by client.

Where ACP is headed

A few threads to watch, some firmer than others:

• The ACP registry. Zed announced an official registry of compatible agents ("The ACP Registry is Live"), giving a canonical place to discover what speaks ACP. Treat the specifics as reported and check the registry directly.
• Governance. ACP started at Zed but is community-governed now, which matters for long-term neutrality across editors and agents.
• JetBrains GA. JetBrains support was in progress via the October 2025 partnership; general availability is the milestone that would broaden reach considerably.
• Devin Desktop. On June 2, 2026, Cognition reportedly relaunched Windsurf as "Devin Desktop," an IDE with a built-in agent manager supporting Codex, Claude Agent, OpenCode, and any ACP-compatible agent. Verify against primary sources before relying on it.

The through-line: momentum is toward more editors and more agents speaking one protocol, with a registry and community governance to keep it honest.

Once the two-arrows picture lands, the Agent Client Protocol vs MCP question dissolves. They are not fighting for the same slot — ACP standardizes the editor-to-agent link, MCP standardizes the agent-to-tools link, and a real session uses both at once, with the editor even handing MCP credentials to the agent as ACP starts up. Pick your editor, pick your agent, wire in the tools your agent needs, and let the protocols do the boring, important work of making them talk. If you also want help picking the model itself, our roundup of the best coding LLMs of 2026 is a good next stop.