You already understand what MCP does — it gives AI coding agents access to your tools, databases, and APIs. But there’s a parallel problem that gets less attention: how does an AI coding agent actually plug into your editor? Right now, each agent ships its own extension per IDE, and each IDE does its own thing. Claude has a VS Code extension, a JetBrains plugin, a Zed integration — all maintained separately, all diverging. The Agent Client Protocol (ACP) is Zed Industries’ answer to that fragmentation. One open protocol, any compatible agent, any compatible editor. It’s working in Zed and JetBrains. VS Code is the wall.
What ACP Is (and Why the LSP Analogy Isn’t Hyperbole) #
The Language Server Protocol solved editor-language fragmentation in 2016. Before LSP, every editor team had to build language support from scratch — autocomplete, go-to-definition, error checking — for every language they wanted to support. That’s n×m integrations. After LSP, language server authors wrote their implementation once, and any LSP-compatible editor picked it up. n+m.
ACP applies the same logic to AI coding agents. Write the agent integration once, and any ACP-supporting editor can use it. Zed Industries published the first version in August 2025 under an Apache 2.0 license. The official ACP specification is public and open to contribution.
How ACP Works: Subprocess, Stdio, Diffs #
The technical model is more straightforward than you might expect. ACP uses JSON-RPC 2.0 over standard input/output. The editor spawns the agent as a subprocess, passes codebase context — file tree, open files, terminal output — at session start, and the agent streams responses back. Diffs render inline in the editor UI. The user accepts or rejects changes without leaving their editor.
This subprocess model has a security advantage worth noting: agents run in separate processes with their own memory space. The agent doesn’t have direct access to editor internals. It can only act through the structured protocol messages. It’s not a sandboxed environment in the WASM sense, but it’s a cleaner boundary than embedding agent logic directly in an extension.
Any language that can read from stdin and write to stdout can implement ACP. That’s intentional. The Zed external agents documentation lists available agents and configuration options.
ACP vs MCP: They Do Different Things #
This trips people up, so let’s be direct. MCP connects an agent to its tools and data. ACP connects an editor to an agent. They sit on opposite sides of the agent and run simultaneously.
| ACP | MCP | |
|---|---|---|
| Created by | Zed Industries (Aug 2025) | Anthropic (Nov 2024) |
| Purpose | Editor ↔ Agent | Agent ↔ Tools/Data | | Transport | JSON-RPC over stdin/stdout | JSON-RPC over HTTP or stdio | | Native editor support | Zed, JetBrains, Kiro | VS Code, most major editors | | Ecosystem size | 25+ agents in registry | 10,000+ servers |
In practice: Claude Code talks to your GitHub repository via MCP while Zed talks to Claude Code via ACP. Both protocols are active in the same workflow. Developers who understand the distinction will stop treating ACP and MCP as competing choices — they’re both necessary.
Who’s In (and Who Isn’t) #
In January 2026, JetBrains joined ACP as a co-adopter and launched the ACP Agent Registry alongside Zed. That registry now lists 25+ agents including Claude Code, Gemini CLI, OpenAI Codex, GitHub Copilot, Goose, Cline, Grok Build, and Qwen Code. Amazon’s Kiro IDE has native ACP support. Devin Desktop added ACP support in June 2026. JetBrains alone brings over 12 million developers into the ACP ecosystem.
VS Code doesn’t have native ACP support. GitHub issue #265496 has been open since late 2025. Microsoft standardized VS Code’s agent mode on MCP when it shipped GA in April 2025, and the team has not committed to adding ACP. Community extensions exist — formulahendry/vscode-acp
on GitHub — but they’re unofficial and incomplete.
Getting Started Today #
If you use Zed or a JetBrains IDE, the setup is minimal.
In Zed: Open the Command Palette, type acp registry
, and select Zed: ACP Registry. Search for your agent — Claude Agent, Codex, Gemini CLI — enter your API key, and you’re done. To give the agent project-specific context, create an AGENTS.md
file in your project root. To forward your MCP servers to the agent, add them to your Zed settings under the ACP section. Debug logs are accessible via dev: open acp logs
in the Command Palette.
In JetBrains: Open AI Chat, click Install From ACP Registry, pick your agent, enter your API key. The registry auto-updates hourly so new agent versions appear without manual action.
The VS Code Problem #
VS Code has roughly 70% of the developer editor market. ACP’s “any editor” promise currently means “any editor that isn’t the most-used editor.” That’s a real limitation, and it’s fair to name it.
The optimistic case: JetBrains and Zed together represent 20+ million developers, enough to sustain a healthy ecosystem without VS Code. The pessimistic case: without Microsoft, ACP stays a minority protocol while the majority of developers stick with proprietary per-agent VS Code extensions.
The honest answer is that this depends on whether Microsoft sees enough developer pressure to add ACP support. If you want that, the place to say so is the open GitHub issue.
Bottom Line #
ACP is a well-designed protocol solving a real problem. The LSP comparison is earned — the problem structures are nearly identical, and the solution follows the same pattern. If you use Zed or any JetBrains IDE, start using it now. The registry gives you access to the best open-weight and proprietary agents without writing a single line of glue code.
If you’re on VS Code: watch the GitHub issue, use the community extension for now, and consider whether the ACP-native editors are worth a look. The agent ecosystem is evolving faster than editor integrations can keep up with. ACP is the right abstraction. Whether it wins depends on the editor with the biggest install base deciding to ship it.