An AI coding agent holds many conversations at once. Not only is the user prompting it, the agent also talks to the IDE, showing diffs and asking before it touches a file. At the same time it talks to tools, pulling a failing build or querying a database.

Two open protocols standardize those conversations. This guide compares ACP vs MCP in practical terms: what each protocol does and when each applies.

ACP (Agent Client Protocol) connects a code editor to an AI coding agent. MCP (Model Context Protocol) connects that agent to tools and data. The “vs” framing suggests a choice, but they’re complementary layers, and running both at once is common practice.

What is the Agent Client Protocol (ACP)?

ACP is an open standard that connects code editors to AI coding agents. It solves a wiring problem: without a shared protocol, every editor builds a custom integration for every agent, and every agent implements every editor’s API. Each new editor or agent multiplies the glue code.

With ACP, both sides implement one protocol, and any ACP agent runs in any ACP editor. The Language Server Protocol (LSP), the standard that lets one autocomplete-and-diagnostics server work in every editor, did the same thing for language tooling. ACP applies the idea to agents.

For developers, the practical payoff is that your choice of agent and your choice of editor come apart. You can run Gemini CLI inside Zed today, try Goose tomorrow, and keep your editor, keybindings, and workflow the whole time. Or go the other direction: move from Zed to Neovim without giving up the agent you’ve already tuned.

Terminal agents gain something too. Instead of squinting at diffs in scrollback, you review the agent’s proposed changes in your editor’s native diff view, with syntax highlighting and your usual accept-or-reject flow.

How ACP works

The mechanics follow the same pattern as a language server. The editor launches the agent as a subprocess, a child program it starts and owns, and the two exchange JSON-RPC messages, a convention for sending named requests and responses as JSON. Both editor and agent communicate over stdio, the plain text input and output streams every program has.

On top of that transport, work happens in sessions. The editor opens a session and sends each of the developer’s prompts as a turn. The agent streams progress updates back as it works, which is how the editor shows what’s happening in real time rather than going quiet for two minutes and dumping a result.

The connection also runs both ways, and this is where ACP earns its keep over pasting code into a chat window. The agent can read the editor’s unsaved buffers, so it works on the code you’re actually looking at, not a stale copy on disk. It must request permission before an edit, so you stay in the loop on every change. And it can run commands in editor-managed terminals, where you can watch the output. The editor decides what the agent may do; the agent gets richer context than it would ever have on its own.

ACP is Apache 2.0 licensed and developed in the open. The official agent directory lists dozens of agents, including Google’s Gemini CLI, OpenAI’s Codex CLI, Block’s Goose, Cursor’s CLI agent, and GitHub Copilot CLI. Clients range from Zed and JetBrains IDEs to Neovim, Emacs, and the marimo notebook. The client directory tracks the full list. VS Code has no native support; community extensions fill the gap.

Which ACP is this?

Three unrelated protocols go by the name ACP. This article covers the Agent Client Protocol, the editor-to-agent standard defined above. Readers researching ACP may run into the other two:

Protocol	What it connects	Relevance here
Agent Client Protocol (Zed/JetBrains)	Editor and coding agent	The subject of this article
Agent Communication Protocol (IBM/BeeAI)	Agent and agent	Merged into A2A
Agentic Commerce Protocol (OpenAI/Stripe)	AI checkout and merchants	Unrelated to coding

IBM’s Agent Communication Protocol merged into A2A (Agent2Agent), a standard that lets agents delegate work to each other. Google created A2A and later moved it to the Linux Foundation. Agent-to-agent delegation is its own layer, one neither ACP nor MCP covers.

What is the Model Context Protocol (MCP)?

MCP is the open standard that connects AI applications and agents to tools and data. Anthropic created it and later donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation.

An MCP server wraps something an agent should reach, such as a CI system, a database, or an issue tracker. Servers run locally over stdio or remotely over HTTP. Each server exposes three primitives to any MCP client (the agent or AI app on the other end of the connection):

• Tools: actions the model can invoke
• Resources: data it can read
• Prompts: reusable templates

Adoption is broad: ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code all ship MCP support, and the official registry catalogs thousands of servers. MCP isn’t the only way to give an agent CI/CD access; our comparison of MCP vs CLI covers that tradeoff.

The CircleCI MCP server, for example, wraps CircleCI. With it connected, an agent can answer “Why did my latest build fail?” by calling the server’s get_build_failure_logs tool and reading the actual logs. The same server finds flaky tests, validates a .circleci/config.yml, and reruns workflows. The docs list every tool available to the CircleCI MCP server.

ACP vs MCP: key differences and when to use each

	ACP (Agent Client Protocol)	MCP (Model Context Protocol)
What it connects	The editor and a coding agent	An agent and its tools and data
Question it answers	Which agent, in what editor?	What can the agent touch?
The agent’s role	Serves the editor	Consumes tools
Created by / governance	Zed; governed jointly by Zed and JetBrains	Anthropic; governed by the Agentic AI Foundation
Wire format	JSON-RPC over stdio	JSON-RPC over stdio or HTTP
Core operations	Sessions, prompt turns, streamed updates, permission requests, diffs	Tool calls, resource reads, prompt templates
Analogy	LSP for agents	USB-C for AI tools

The agent sits between the two protocols, and the direction of each conversation is the difference that matters.

• Over ACP, the editor asks and the agent answers: prompts go in, progress and diffs stream back.
• Over MCP, the agent asks and the server answers: it calls a tool, the server returns the result.

The two protocols are designed to work together. ACP reuses MCP’s JSON representations where possible and adds custom types for editor UX, most notably diffs: how an editor renders an agent’s proposed change for review.

Where your agent is running determines which protocols are relevant to it. Agents can access MCP servers from just about anywhere, whether they are running from the command line or in an editor. But ACP is only relevant when an editor is involved. Think about where you are calling the agent from:

• Agents in a terminal (Claude Code, Codex CLI): ACP isn’t in the stack. It only matters when an agent runs inside an editor. MCP applies either way.
• Agents in an editor (Zed or a JetBrains IDE): Inside of these editors, ACP is how agents plug in to the IDE’s features. MCP is what those agents can reach.
• VS Code or Cursor: Neither editor hosts ACP agents natively, though Cursor’s own CLI is an ACP agent that runs in other editors. MCP fully applies. Both have first-class MCP support.

Is ACP a replacement for MCP?

No. They operate at different layers and don’t overlap. ACP standardizes the editor-to-agent conversation: sessions, prompts, edits, permissions. MCP standardizes the agent-to-tool conversation: tool calls and resources. Running both at once is common practice. One more protocol shaped them both.

Where LSP fits in

Both ACP and MCP borrow their core idea from the Language Server Protocol. LSP solved the same wiring problem for language tooling: implement the protocol once, and any language server works in any editor. The MCP spec credits it directly, saying it “takes some inspiration from the Language Server Protocol.” Zed says the same about ACP.

Set side by side, LSP, MCP, and ACP repeat the pattern. All three speak JSON-RPC, and each one unbundles a single relationship:

• LSP gives the editor language intelligence: completions, diagnostics, go-to-definition.
• ACP puts a coding agent in that editor.
• MCP hands the agent its tools and data.

LSP still has a place in an agentic stack. It’s how an agent gets compiler-grade code intelligence instead of grepping text.

Using ACP and MCP together

The full map fits in one line: ACP connects the editor to an agent and MCP connects that agent to tools.

One practical question is whether MCP servers configured in an agent, like the CircleCI server, survive the move into an editor. They do, and tools can arrive from either side. If you’ve configured your MCP servers inside an agent harness like Claude Code, connecting it to an ACP will carry that MCP setup into your editor. Servers configured in the agent travel with it.

Editors can forward their own servers too. When a session starts, the ACP client passes its configured MCP servers to the agent through the mcpServers parameter of session/new, the request the editor sends to open a session.

Security cuts across both protocols because an MCP tool is code the agent can run. Local servers authenticate with environment variables, so a narrowly scoped token beats an org-admin one. The client’s permission prompts are the guardrail, and when the agent runs inside an editor, ACP is what carries those prompts to the screen.

Conclusion

ACP and MCP occupy different layers of the same stack. ACP covers which agent runs in the editor and how the editor reviews its proposed changes. MCP covers what that agent can touch. An agent in a terminal needs only MCP; the moment it moves into an editor, both protocols are in play.

The fastest way to feel the difference is to run the stack: an ACP agent in Zed or a JetBrains IDE, the CircleCI MCP server, and one question about the last build. Sign up for a free CircleCI account and start building today.