MCP vs ACP: different layers, and three ACPs
ACP is an overloaded acronym: at least three unrelated protocols have used the name, so “MCP vs ACP” resolves to a different comparison depending on which one is in front of you. The one people usually mean today is the Agent Client Protocol, which standardises the connection between a code editor and a coding agent. Against MCP it is not really a rival at all; it sits one layer up. The editor speaks ACP to the agent, and the agent speaks MCP to its tools.
| Name | What it connects | Status |
|---|---|---|
| Agent Client Protocol | Code editors and IDEs to coding agents | Active. This is what people usually mean today. |
| Agent Communication Protocol (IBM) | Agent to agent | Merged into A2A |
| Various vendor-specific ACPs | Varies | Not general standards |
If you landed here after seeing IBM’s Agent Communication Protocol, that effort merged into A2A, and the comparison you want is MCP vs A2A. The rest of this page is about the Agent Client Protocol.
What is the Agent Client Protocol?
A standard for the connection between a code editor and a coding agent. In its own words it “standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios”. In practice the local case is the one you can use today: agents run as sub-processes of the editor over JSON-RPC on stdio. Remote hosting is the stated direction rather than a shipped transport, and ACP’s own transports page currently describes Streamable HTTP as “In discussion, draft proposal in progress.”
The pitch is the same one MCP makes, aimed one layer up. MCP is often described as “LSP for tools”, so that any agent can reach any tool. ACP is “LSP for agents”, so that any editor can host any agent. Today, supporting a new coding agent in an editor means bespoke integration work on both sides; ACP is the attempt to make that a standard interface.
It is also deliberately MCP-adjacent by construction. The ACP documentation states that “the protocol re-uses the JSON representations used in MCP where possible, but includes custom types for useful agentic coding UX elements, like displaying diffs.”
How do MCP and ACP fit together?
They stack, at adjacent layers of the same request.
Editor / IDE
| ACP (which agent am I hosting, and how do I render what it does?)
Coding agent
| MCP (which tools can I reach, and how do I call them?)
Tools, data, servicesA single action passes through both. You ask the agent in your editor to fix a failing test. The editor sends that request over ACP. The agent decides it needs to read a file and run the suite, and reaches those capabilities over MCP. Results come back up the MCP connection to the agent, and the agent’s proposed diff goes back up the ACP connection to the editor, which renders it as a diff you can accept.
Remove ACP and the agent still works, but only inside whichever editor someone integrated it into. Remove MCP and the agent still works, but only with tools someone hard-coded into it.
Which should you implement?
Rarely both, and the answer follows from what you are building:
- Exposing a capability (an API, a database, an internal service): MCP server. Any coding agent speaking a compatible MCP revision can then use it, whatever editor it is hosted in, subject to whatever authorisation you require.
- Building a coding agent: consume MCP for tools, and consider implementing ACP so editors other than your own can host you.
- Building an editor or IDE: implement ACP so you are not writing a bespoke integration per agent.
- Building anything that is not a coding tool: MCP only. ACP is scoped to the editor-agent relationship and has nothing to say about a chat app, a batch pipeline or a backend service.
Does the trust question transfer?
Partly. The two layers have different shapes of exposure.
MCP’s supply-chain problem is that servers are things you install or endpoints you call, largely written by people you have never met. That is why there is a registry, and why we score it. The population is large and mostly unvetted.
ACP’s trust surface is narrower today, because the set of coding agents is small and you are choosing one deliberately, the way you choose an editor. Agents are not a long-tail ecosystem you install twelve of.
The composition is where it gets interesting. An ACP-hosted agent that consumes MCP inherits every MCP server it connects to, and the editor at the top has the least visibility of all three layers into what those servers are. If you are evaluating a coding agent, the question is not only “is this agent trustworthy” but “what does it connect to, and can I see that list”. An agent that silently adds MCP servers is a supply chain you did not review.
Where to go next
- The agent-to-agent layer, and where IBM’s ACP went: MCP vs A2A.
- Whether your agent should use MCP at all for a given job: MCP vs CLI.
- Checking what a server actually exposes before an agent connects to it: the MCP Inspector.
ACP standardises which agent your editor can host. MCP standardises what that agent can reach. Because the acronym is shared, it is worth confirming which ACP a given document means before mapping it against MCP.