Agent Client Protocol and MCP are not the same layer (2026)

Quick answer

The Agent Client Protocol (ACP) is not a competitor to MCP and it is not "MCP for editors". They sit on opposite sides of the agent: MCP connects an agent to tools, ACP connects an editor to the agent. The protocol's own architecture page calls itself "MCP-friendly" and says it "re-uses MCP types where possible". In practice your editor hands the agent your MCP servers inside the session/new call. The part worth knowing before you wire anything: the spec says every agent must support MCP over stdio, while HTTP and SSE are optional capabilities negotiated at startup. So a remote HTTP MCP server that works fine in your editor can quietly not be there when the same job runs through an ACP agent. Read September 6, 2026.

I went looking for a straight answer to "is ACP replacing MCP" and could not find one, which is usually a sign the question is malformed. Two hours in the primary docs later, it is. The two protocols are not on the same axis, and once you see where each one attaches, a lot of confusing ecosystem chatter resolves itself. This is the field log, written September 6, 2026, from the specification rather than from summaries of it.

First, what ACP actually claims to be

Straight from the introduction on agentclientprotocol.com, read September 6, 2026:

"The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios."

And the analogy it reaches for is not MCP. It is LSP:

"ACP solves this by providing a standardized protocol for agent-editor communication, similar to how the Language Server Protocol (LSP) standardized language server integration."

That analogy is the whole thing. LSP did not compete with your compiler. It standardised how your editor talked to a language server so that N editors times M languages stopped being N times M integrations. ACP is making the same bet one layer up, with agents instead of language servers.

The setup is deliberately boring, which I mean as praise. Local agents run as a subprocess of the editor and talk JSON-RPC over stdio. One connection can carry several concurrent sessions.

Why "ACP vs MCP" is the wrong axis

Here is the sentence that settles it, from the ACP architecture page, in the section listing the protocol's design principles:

"MCP-friendly: The protocol is built on JSON-RPC, and re-uses MCP types where possible so that integrators don't need to build yet-another representation for common data types."

A protocol that deliberately re-uses another protocol's type definitions is not trying to replace it.

The same page is explicit about who gives the agent its capabilities:

"ACP works when you're using a code editor to talk to a model you trust. You still have controls over the agent's tool calls, but the code editor gives the agent access to local files and MCP servers."

So the editor is the thing holding your MCP configuration. The agent is the thing that ends up connected to those servers. ACP is the wire between them. Draw it once and you stop asking which protocol wins.

The handoff is literally a field in the request

This is where reading the spec beats reading a diagram. Session creation is not vague about it. From the session/new documentation:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "session/new",
  "params": {
    "cwd": "/home/user/project",
    "mcpServers": [
      {
        "name": "filesystem",
        "command": "/path/to/mcp-server",
        "args": ["--stdio"],
        "env": []
      }
    ]
  }
}

Your MCP servers are a parameter of the session. The client passes the connection details, and the agent connects to those servers itself. The spec's own summary of the call is that clients create a session with a working directory and "a list of MCP servers the Agent should connect to".

That is a genuinely nice design. It means the agent is not proxying your tool calls through the editor on the hot path, and it means an agent can be swapped without re-teaching it your tools.

The floor: stdio is mandatory, HTTP is not

Now the part I did not expect, and the reason I think this post is worth writing.

From the MCP Servers section of the session setup documentation, read September 6, 2026:

"All Agents MUST support the stdio transport, while HTTP and SSE transports are optional capabilities that can be checked during initialization."

And immediately after:

"While they are not required to by the spec, new Agents SHOULD support the HTTP transport to ensure compatibility with modern MCP servers."

Read those as the RFC keywords they are. MUST for stdio. SHOULD for HTTP, which means encouraged and not guaranteed. The HTTP path is gated behind an mcpCapabilities.http capability the agent advertises at initialize time, and SSE behind mcpCapabilities.sse, which the docs additionally flag with a warning that SSE "was deprecated by the MCP spec".

The practical consequence for anyone running remote MCP servers:

• A local stdio MCP server will work with any conformant ACP agent. That is the guaranteed floor.
• A remote HTTP MCP server works only if that specific agent implemented an optional capability.
• If it did not, you do not get a loud protocol error at the point you would notice. You get a session where a tool you rely on is simply absent.

I have spent enough hours debugging "why did the agent not use that tool" to know that a missing capability and a badly worded prompt look identical from the transcript. Check the capability, not the vibe.

The proxy detail that only makes sense once you know the floor

The architecture page has a passage that reads as strange out of context, and obvious once you have read the transport rules:

"Instead of trying to run MCP and ACP on the same socket, the code editor can provide its own MCP server as configuration. As agents may only support MCP over stdio, the code editor can provide a small proxy that tunnels requests back to itself."

So when the editor wants to expose its own tools to the agent, it does not multiplex MCP over the ACP connection it already has open. It spawns a little stdio proxy and lets the agent phone home through it.

That looks like a workaround until you notice the two documents corroborating each other. The proxy exists precisely because stdio is the only transport with a guarantee behind it. One page states the constraint, the other page shows the design that falls out of it. I like finding that. It is the difference between a spec that was written and a spec that was thought about.

What the ecosystem actually looks like, counted

I counted the two roster pages on September 6, 2026 rather than trusting an impression.

• 40 agents listed as implementing ACP.
• 103 client entries across 8 categories: editors and IDEs (16), CLI and TUI, desktop and web, notebook and data tools, mobile, messaging, frameworks, and connectors.

The agent list is not a curiosity shelf. Cursor, Gemini CLI, OpenCode, Goose, Cline, OpenHands, Kimi CLI, Qwen Code and Junie by JetBrains are all on it. GitHub Copilot is listed as being in public preview, dated January 28, 2026 in GitHub's own changelog.

One caveat I would want told to me, though.

Several of the biggest names are reached through an adapter, not natively. The roster lists Claude Agent via Zed's SDK adapter, and Codex CLI via an adapter maintained in the ACP organisation itself. That is not a knock. Adapters are how a protocol bootstraps, and LSP grew the same way. But an adapter is a second thing that can lag a release, and it is maintained by someone other than the vendor whose name is on the row. Worth knowing which of the two you are actually depending on before you build a workflow on it.

Where the protocol is in its own lifecycle

The updates page gives dates, which I appreciate more than a version badge.

• June 25, 2026: the Rust and TypeScript SDKs reached 1.0.0.
• July 20, 2026: ACP v2 published in draft.
• July 22, 2026: elicitation stabilised, with clients explicitly advertising which interaction modes they support.

That last one made me smile, because elicitation is a concept I already wrote up on the MCP side. The same idea, structured input requested from the user mid-run, landed in both protocols. Which is exactly what "re-uses MCP types where possible" looks like when it stops being a design principle and starts being a shipped feature.

Note the shape of that list: v1 is what you build against today, v2 exists and is explicitly a draft. Do not read the v2 tab as the current target.

What I am still unsure about

Three things I could not settle from the documents, stated plainly rather than glossed.

How many of the 40 agents actually implement mcpCapabilities.http. The spec makes it optional and I did not test agents one by one. So I can tell you the guarantee is stdio only. I cannot tell you your specific agent is missing HTTP.

How remote agents behave in practice. The introduction says ACP suits local and remote scenarios, then adds that "Full support for remote agents is a work in progress." Both sentences are on the same page. I would treat remote as directional.

Whether the trust model holds up outside a single-developer machine. The architecture page states its assumption openly, that you are talking to a model you trust, and the editor hands over local file access. That is a reasonable default for my laptop. It is an assumption worth re-reading before anyone points this at a shared or production environment.

The one takeaway

If you remember one thing, make it this: ACP does not replace your MCP setup, it carries it, and the carry has a floor of stdio. Before you move a workflow onto an ACP agent, check whether your remote MCP servers are reachable over a transport that agent actually advertises. Local stdio servers are guaranteed. Everything else is a capability check you should make explicitly.