> ## Content Index > Fetch the complete content index at: https://wuu73.org/aiguide-ghost/llms.txt > Use this file to discover other available public pages before exploring further. # MCP & ACP: The Protocol Wars - URL: https://wuu73.org/aiguide-ghost/coding-agents-protocols/ - Published: 2026-05-29T00:13:00.000Z - Updated: 2026-05-29T00:13:00.000Z - Description: Part of Agent Harness Field Guide. - Author: WUU73 - Tags: Deep Dives, Agent Harness Field Guide, #Deep Dive Child, #Import 2026-09-12 06:38 MCP • ACP • Transports • OAuth • Lifecycle 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. ![Hand-drawn side-by-side comparison of MCP and ACP showing MCP as agent-to-tool transport and ACP as IDE-to-agent session bridge.](https://wuu73.org/aiguide-ghost/content/images/imported/coding-agents/assets/diagrams/mcp-vs-acp.png) Most protocol confusion disappears once you separate tool transport from IDE session wiring: MCP is the tool pipe, ACP is the agent bridge. Shameless Plug[While we're deep-diving into complex CLI tools... let's be honest. Are you tired of feeling like nerds are trying to gatekeep the terminal life by having you memorize 30 key combos just to do basic stuff? Do you lie awake at night dreading the moment you have to edit a cryptic dotfile just to change a font size? Same. It's the AI age, we can have a crazy UI on top of the terminal with shameless amounts of AI built in to do things for you. We can even have AI nudge stalled coding agents for you when they stop for no reason.**ButtonsCLI**: The terminal for](https://buttonscli.com/?ref=wuu73.org) (Alright, ad over. Back to the serious technical analysis.) ## 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 Footprint | 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 | | **OpenCode** | High | Client | stdio, SSE, Streamable HTTP | Yes | Connection status, tool/resource/prompt discovery, auth callbacks | src/mcp/index.ts supports stdio plus remote transports, OAuth, prompt/resource listing, and bus events; ACP handles the agent-to-agent side. | | **Oh My Pi** | Broad | Client | stdio, HTTP, SSE | Yes | OMP-managed config, discovery, enable/disable, reauth | docs/mcp-config.md documents project and user .omp/mcp.json files, OAuth metadata, and schema validation, while the README frames MCP as one part of a larger discovery system that can import configuration from other AI tool ecosystems. | | **ADK-Rust** | Feature-gated | Client | stdio | — | McpServerManager spawn, monitor, auto-restart | MCP lives under adk-tool rather than dominating the whole framework; the README explicitly calls out MCP elicitation support and a managed server lifecycle. | | **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 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 | | **Pi Mono** | Deliberately absent | — | — | — | — | The README explicitly rejects built-in MCP. Pi expects CLI tools, skills, prompt templates, packages, or extensions instead. | ## 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: 1**MCP servers connect** Tools registered in DeferredToolRegistry, not exposed to agent ↓2**Agent needs a tool** Agent calls tool\_search("find me a web search tool") ↓3**Search returns match** DeferredToolRegistry finds matching tool, binds it to agent ↓4**Agent uses tool** 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 (`mcpServers` in 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 `` 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. ## Oh My Pi — MCP as configuration and discovery Pi Mono explicitly rejected built-in MCP. Oh My Pi makes the opposite choice, but it does it in a very OMP way: not as a one-off checkbox, but as part of a broader configuration and capability discovery model. The MCP docs define project `.omp/mcp.json` and user `~/.omp/agent/mcp.json` as the preferred homes, support stdio, HTTP, and SSE transports, and include explicit OAuth fields for servers that need client settings. The README then widens the frame by saying OMP can discover MCP servers, rules, skills, hooks, tools, slash commands, prompts, and context files from multiple neighboring coding-tool ecosystems. 🔌 #### Why this matters OpenCode treats MCP as part of a runtime bus. Oh My Pi treats MCP as one capability inside a broader discovery and extensibility system. That is a different product instinct. ## ADK-Rust — beyond MCP: A2A, AWP, and commerce adapters ADK-Rust is interesting on this page because MCP is only one slice of its protocol story. The workspace also includes A2A server support, Agentic Web Protocol crates, and a payment layer that exposes ACP and AP2 adapters. That is a broader protocol appetite than most of the CLI products in this directory. ### A2A server surface `adk-server` exposes REST and A2A routes, which makes agent-to-agent exchange part of the framework itself rather than a sidecar bridge. ### AWP deployment support `adk-awp` and `awp-types` add discovery, manifest, event, health, and A2A endpoint surfaces for web-native agent deployment. ### Commerce adapters `adk-payments` treats ACP and AP2 as real framework concerns with durable journals and transaction abstractions, not just an example plugin. ### MCP stays in proportion MCP is present and useful, but it is not allowed to define the whole repo's identity. ADK-Rust is broader than an MCP wrapper. ## ACP implementation: Kimi CLI, Neovate, and OpenCode ACP (Agent Communication Protocol) is primarily about IDE-to-agent communication. Three 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`. ### OpenCode — ACP as runtime plumbing OpenCode's `src/acp/agent.ts` is not a thin adapter. It wires ACP into session initialization, prompt submission, permission requests, usage updates, session forking, and mode switching. That makes OpenCode's ACP story more runtime-shaped than bridge-shaped: ACP is part of how the backend exposes itself to other clients, not just an integration afterthought. ## 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. ### 🏆 Most runtime-shaped ACP: OpenCode ACP is wired into session lifecycle, permissions, usage updates, and forked agent flows. It looks like product architecture, not a thin bridge. ## What this tells you about the landscape The MCP adoption spectrum reveals a clear split: - **MCP-native agents** (Claude Code, Qwen Code, DeerFlow, OpenCode) treat MCP as a first-class protocol with lifecycle management, OAuth, or deferred discovery. - **MCP-supporting agents** (Neovate, Crush, Pochi, Kimi CLI, Codex) connect to MCP servers seriously, but center their identity elsewhere. - **MCP-adjacent or absent agents** (Mux, OpenHands, Pi Mono) either de-emphasize MCP or deliberately omit it. The ACP story is simpler: it's primarily an IDE integration protocol, and the agents that support it split into two camps: bridge-oriented implementations like Kimi CLI and runtime-oriented implementations like Neovate and OpenCode.