MCP & ACP: The Protocol Wars
Model Context Protocol (MCP) and Agent Communication Protocol (ACP) are the two main protocols for connecting agents to external tools and services. This page audits how each agent implements, supports, or ignores them.
What are MCP and ACP?
MCP — Model Context Protocol
Anthropic's open protocol for connecting LLMs to external tools and data sources. MCP servers expose capabilities as named tools with JSON schemas. Agents act as MCP clients, discovering and invoking tools via JSON-RPC over stdio, SSE, or HTTP transports.
Think of it as "USB-C for AI" — a standard way for any agent to connect to any tool server without custom integration code.
ACP — Agent Communication Protocol
A protocol for agent-to-agent communication, primarily used for IDE-to-agent integration. ACP defines how an IDE (the client) communicates with an agent (the server) — session management, tool calls, and result formatting.
Think of it as "LSP for agents" — a standard way for IDEs to talk to any ACP-compatible agent without custom plugins.
MCP implementation matrix
| Agent | MCP Mentions | Role | Transports | OAuth | Lifecycle | Notable Features |
|---|---|---|---|---|---|---|
| Claude Code | 5,313 | Client + Server | stdio, SSE | McpAuthTool (built-in) | Full lifecycle + deferred loading | MCP as core nervous system; ToolSearch for deferred discovery; ListMcpResourcesTool, ReadMcpResourceTool |
| Qwen Code | 4,008 | Client | stdio, SSE | Yes | Discovery, connection, health | Explicit MCP lifecycle management; health monitoring; runtime snapshots |
| OpenHands | 2,839 | Client | stdio | — | Legacy tool mapping | MCP tools mapped into actions; partial snapshot (V1 core elsewhere) |
| Neovate | 750 | Client + Server | stdio | — | Connection state tracking | MCP server management with retry/connection state; neovate mcp subcommand |
| DeerFlow | 690 | Client | stdio, SSE, HTTP | OAuth bearer tokens | Deferred registry + tool_search | langchain-mcp-adapters; deferred tool loading; OAuth token support |
| Pochi | 956 | Client | stdio | — | Mixed with vendor tools | MCP blended with vendor-specific agent packages |
| Crush | 860 | Client | stdio | — | MCP instruction injection | MCP server instructions as <mcp-instructions> block in system prompt |
| Kimi CLI | 1,518 | Client | stdio | — | ACP bridge conversion | MCP results converted through ACP bridge layer |
| Mux | 1,898 | Client | — | — | — | MCP mentions present but less front-and-center than provider routing |
| Codex | — | Client + Server | stdio | ChatGPT sign-in, API key | Deferred tool loading (MCP tools not loaded until agent requests) | codex-mcp crate connects to external MCP servers on startup; [[mcp_servers]] in config.toml; per-tool approval overrides; codex-mcp-server crate (codex mcp-server); codex mcp subcommand (add/list/get/remove); codex-rmcp-client alternative MCP implementation |
Claude Code — MCP as the core nervous system
With 5,313 mentions of MCP, Claude Code doesn't just "support" MCP — it uses MCP as the core mechanism for all tool execution beyond its built-in tools. The architecture:
MCP tools built into the runtime
Claude Code has dedicated MCP tools: MCPTool (invoke
MCP tool), ListMcpResourcesTool, ReadMcpResourceTool,
and McpAuthTool (handle MCP OAuth authentication).
Deferred tool discovery
The ToolSearchTool enables deferred tool loading — MCP
tools can be sent with defer_loading: true and only
loaded on-demand, reducing prompt size when many MCP servers are
connected.
Claude Code as MCP server
Claude Code can also run as an MCP server
(src/entrypoints/mcp.ts), exposing its own capabilities
to other MCP clients. This makes it both a consumer and provider
in the MCP ecosystem.
DeerFlow — Deferred tool loading with OAuth
DeerFlow has the most sophisticated MCP discovery system in this set.
When tool_search.enabled: true, MCP tools are not bound
directly to the agent. Instead:
Tools registered in DeferredToolRegistry, not exposed to agent
Agent calls tool_search("find me a web search tool")
DeferredToolRegistry finds matching tool, binds it to agent
Now the MCP tool is available for this session
This is brilliant for environments with many MCP servers: rather than polluting the agent's context with hundreds of tool descriptions, the agent searches for tools on demand. Only tools it actually needs get loaded.
DeerFlow's MCP client also supports OAuth bearer token authentication — the only agent in this set that explicitly handles OAuth for MCP server authentication.
Qwen Code — Explicit MCP lifecycle management
Qwen Code's MCP handling is notable for explicit lifecycle management:
- Discovery — MCP servers discovered from config (
mcpServersin settings) - Connection — Servers started as subprocesses (stdio transport) or connected via SSE
- Health monitoring — Connection state tracked explicitly; failed servers don't break other servers
- Tool registration — MCP tools registered as declarative function declarations
- Runtime snapshots — MCP state captured in runtime snapshots for debugging
The MCP system is cleanly separated from model config, confirmation rules, and discovery — a sign of mature systems engineering.
Crush — MCP instructions in system prompt
Crush takes a unique approach: MCP server instructions are injected as a
separate <mcp-instructions> block appended to the system
prompt at runtime. The coder.md.tpl template renders with
runtime data including available skill XML, and MCP instructions are
appended separately.
This means the LLM reads MCP server capabilities as natural language instructions rather than as structured tool schemas. It's a simpler approach that works well for Go's type-safe binary — no need for complex MCP client infrastructure when you can just describe the tools to the model.
Codex — MCP client, server, and IDE integration
Codex has a multi-faceted MCP architecture spanning several dedicated crates:
MCP Client: codex-mcp crate
The codex-mcp crate connects to external MCP servers on startup.
Configuration lives in config.toml under [[mcp_servers]]
entries. Supports per-tool approval overrides and deferred tool loading —
MCP tools are not loaded into the prompt until the agent explicitly requests them,
keeping context lean when many servers are configured.
MCP Server: codex-mcp-server crate
The codex-mcp-server crate lets Codex run as an MCP tool provider
via codex mcp-server, making it usable as a tool by other agents.
Testable with npx @modelcontextprotocol/inspector codex mcp-server.
MCP management: codex mcp subcommand
The codex mcp subcommand provides add,
list, get, and remove operations
for managing MCP server launchers — a CLI-native way to configure
the MCP ecosystem without editing config files directly.
App Server Protocol
The app-server, app-server-client, and
app-server-protocol crates enable IDE integration with
VS Code, Cursor, and Windsurf. Handles initialization, client info
(TUI reports "codex-tui"), and turn lifecycle events.
Authentication
ChatGPT sign-in flow via the codex-login crate, plus
API key support and a keyring store (codex-keyring-store)
for persistent credential storage.
State DB
SQLite-backed state via the codex-state crate, configured
under sqlite_home in config or the CODEX_SQLITE_HOME
environment variable.
Custom CA certificates
The CODEX_CA_CERTIFICATE environment variable supports
enterprise proxy configurations — multiple PEM certs accepted, with
OpenSSL TRUSTED CERTIFICATE labels and X509 CRL sections.
RMCP client
The codex-rmcp-client crate provides an alternative MCP
implementation, giving Codex flexibility in how it connects to and
communicates with MCP servers.
ACP implementation: Kimi CLI and Neovate
ACP (Agent Communication Protocol) is primarily about IDE-to-agent communication. Two agents in this set have explicit ACP support:
Kimi CLI — ACP bridge with conversion
Kimi CLI runs as an ACP agent via kimi-cli acp,
communicating via stdin/stdout with newline-delimited JSON. The
ACP bridge layer converts internal tool results into
protocol-transportable content blocks.
Notably, the docs honestly list current gaps — missing
session/set_mode and session/set_model —
rather than implying perfect coverage.
Neovate — ACP with full session management
Neovate runs as an ACP agent via neovate acp, using
@agentclientprotocol/sdk for protocol compliance.
Includes NeovateACPAgent class with session management,
tool call history tracking, and message adapter.
ACP sessions persist as JSONL with different entry types:
config, message, snapshot.
DeerFlow — ACP agent invocation
DeerFlow has an invoke_acp_agent tool that calls external
ACP-compatible agents. It expects ACP adapters (e.g.,
@zed-industries/claude-agent-acp,
@zed-industries/codex-acp), not raw CLI binaries.
This means DeerFlow can delegate work to Claude Code or Codex through the ACP protocol as a first-class tool call — effectively using ACP agents as sub-agents within its orchestration framework.
MCP transports compared
| Transport | How it works | Used by |
|---|---|---|
| stdio | MCP server runs as subprocess; JSON-RPC over stdin/stdout | Claude Code, Qwen Code, Neovate, Crush, Kimi CLI, Pochi, DeerFlow, OpenHands, Codex |
| SSE | Server-Sent Events for server-to-client streaming; HTTP POST for client-to-server | Claude Code, Qwen Code, DeerFlow |
| HTTP | Full HTTP transport (REST + WebSocket or similar) | DeerFlow |
Protocol verdicts
🏆 Most MCP-native: Claude Code
5,313 MCP mentions, dedicated MCP tools, deferred discovery, and the ability to run as an MCP server itself. MCP is Claude Code's core nervous system, not an afterthought.
🏆 Most sophisticated MCP discovery: DeerFlow
Deferred tool loading via tool_search is unique in this set. OAuth bearer token support for MCP servers is also unique.
🏆 Most explicit MCP lifecycle: Qwen Code
Discovery → Connection → Health → Tool Registration → Runtime Snapshots. Clean separation from model config. Mature systems engineering.
🏆 Most honest ACP documentation: Kimi CLI
Explicitly lists feature gaps (missing session/set_mode and session/set_model) rather than implying perfect coverage. A sign of healthy protocol mindset.
What this tells you about the landscape
The MCP adoption spectrum reveals a clear split:
- MCP-native agents (Claude Code, Qwen Code, DeerFlow) treat MCP as a first-class protocol with lifecycle management, OAuth, and deferred discovery.
- MCP-supporting agents (Neovate, Crush, Pochi, Kimi CLI) connect to MCP servers but don't build their architecture around it.
- MCP-adjacent agents (Mux, OpenHands) have MCP mentions but it's not the primary design driver.
The ACP story is simpler: it's primarily an IDE integration protocol, and the agents that support it (Kimi CLI, Neovate) do so to enable IDE communication rather than as a core architectural choice.