TL;DR
ACP connects a code editor to a coding agent. MCP connects that agent to its tools. They are not competing choices, because the editor hands the agent its MCP server list inside the ACP session that starts the conversation. The session/new request carries an mcpServers array, so one protocol literally transports the other's configuration. A coding agent running in your editor is an ACP server and an MCP client at the same time, in the same process.
If you are comparing all three agent protocols rather than this pair, the three-way comparison covers where A2A fits and which ACP people mean. This post is only about the editor layer.
Building a coding agent, or an internal tool that has to host one? We build AI agents against the protocol boundaries teams usually discover three months in.
Key Takeaways
- ACP is the editor-to-agent link. MCP is the agent-to-tool link. Nothing about them overlaps, which is why "should we use ACP or MCP" has no answer.
- The composition is explicit in the spec:
session/newaccepts anmcpServersarray, so the editor tells the agent which MCP servers to connect to for that session. - The MCP capability negotiation is one-directional. The agent advertises
mcpCapabilitiesdescribing which transports it can use to reach servers. The editor never becomes an MCP server itself. - ACP is JSON-RPC over stdio, the same mechanism LSP uses, not REST. Several current comparisons describe ACP as REST-based, which is a description of IBM's discontinued protocol, not this one.
- Both protocols are now vendor-neutral, but by different routes. MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025. ACP is Apache-licensed and still maintained by Zed with its community.
First, which ACP
Two protocols share the acronym, and mixing them up is the single biggest source of wrong answers on this question. This post is about Zed's Agent Client Protocol, the one that connects coding agents to editors. The other one, IBM's Agent Communication Protocol, wound down in August 2025 and merged into A2A. The three-way comparison covers that history properly.
The practical tell: if something describes ACP as REST-based, or as a lighter alternative to A2A for multi-agent coordination, it means IBM's. Zed's ACP is JSON-RPC over stdio and has nothing to do with agent-to-agent orchestration.
What ACP actually does
ACP standardises the conversation between an editor and an agent process. Without it, every editor-and-agent pair needs a bespoke integration, which is the same fragmentation LSP solved for language servers, and ACP borrows the mechanism deliberately: the editor spawns the agent as a child process and they speak JSON-RPC over stdin and stdout.
The flow is short. The editor calls initialize to negotiate protocol version and capabilities. It optionally calls authenticate. It opens a conversation with session/new, or resumes one with session/load. Then each turn goes through session/prompt, and the agent streams progress back until it returns a stop reason.
That is the entire surface. ACP has nothing to say about what the agent can do, only about how the editor talks to it.
Where MCP fits, and why this is not a choice
Here is the part most comparisons miss. When the editor opens a session, it can tell the agent which MCP servers to use:
{
"jsonrpc": "2.0",
"id": 1,
"method": "session/new",
"params": {
"cwd": "/home/user/project",
"mcpServers": [
{ "name": "filesystem", "command": "/path/to/mcp-server", "args": ["--stdio"], "env": [] }
]
}
}
The spec's language is that clients may include connection details for MCP servers the agent should connect to. So the MCP configuration originates in the editor, travels across ACP, and is used by the agent to open a completely separate set of MCP connections outward to tools. Two protocols, one handoff between them, and the handoff is a documented field rather than an integration someone bolted on.
The negotiation only runs one way. The agent advertises mcpCapabilities during initialize, declaring which transports it can use to reach MCP servers, for example { "http": true, "sse": true }. The editor never exposes itself as an MCP server. It provides file system and terminal access to the agent through ACP's own client capabilities instead, which is a separate mechanism with a separate permission model.
The order things happen in
Side by side
| ACP | MCP | |
|---|---|---|
| Connects | An editor to a coding agent | An agent to tools and data |
| Direction | The editor spawns and drives the agent | The agent reaches outward to servers |
| Created by | Zed, with JetBrains and a community of editors | Anthropic |
| Governance | Apache 2.0, maintained by Zed | Agentic AI Foundation, Linux Foundation, since Dec 2025 |
| Transport | JSON-RPC over stdio, HTTP or WebSocket when remote | JSON-RPC over stdio or Streamable HTTP |
| Unit of work | A prompt turn inside a session | A tool call |
| You touch it when | You ship a coding agent, or an editor that hosts one | Your agent needs to reach anything external |
Which one do you actually work on?
Most people never implement either. You configure them. If you run Claude Code or Gemini CLI inside Zed or a JetBrains IDE, ACP is already carrying that conversation and your mcpServers entries are already being forwarded through it.
You implement ACP in exactly two situations: you are building a coding agent and want it usable in editors you do not own, or you are building editor tooling and want to accept agents you did not write. JetBrains shipped an agent registry in January 2026 on that second premise, and Zed lists 11 editors and more than 50 agents on the first.
You implement MCP whenever an agent of any kind needs to reach a system. That is a far broader case, and with 97 million monthly SDK downloads and roughly 10,000 active servers as of December 2025, it is the one most teams meet first. Our guide on building a server that survives day two covers the parts the quickstarts skip.
If you are choosing where to spend effort, MCP is almost always the answer, because ACP only matters at the editor boundary and most agents are not coding agents.
Frequently asked questions
Is ACP a replacement for MCP?
No, and the spec makes the relationship explicit rather than leaving it to interpretation. The session/new request carries an mcpServers array, so an ACP session is where an agent is told which MCP servers to use. Replacing MCP with ACP would mean removing the tools an agent reaches through the configuration ACP delivers.
Is ACP REST-based?
No. Zed's Agent Client Protocol is JSON-RPC, over stdio for local agents and HTTP or WebSocket for remote ones. Descriptions of a REST-based ACP are describing IBM's Agent Communication Protocol, which is a different protocol that merged into A2A in August 2025.
Can an editor act as an MCP server for the agent?
Not through this mechanism. MCP capability negotiation in ACP runs one way: the agent declares which transports it can use to reach servers. Editors expose their own abilities, such as reading and writing files or running terminal commands, through ACP's client capabilities instead, which carry their own permission model.
Do I need ACP if my agent already uses MCP?
Only if the agent should run inside an editor you do not control. An agent with MCP tools and no editor integration is complete for most use cases. ACP is what you add when the delivery surface is somebody else's IDE.
Are both protocols vendor-neutral?
Both are open, by different routes. MCP was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, in December 2025, with project autonomy preserved. ACP is Apache-licensed and still maintained by Zed together with the editors and agents that adopted it, rather than sitting under a foundation.
