MCP vs ACP: Understanding the Difference

Two Protocols, Two Problems, One Ecosystem

If you've been following the AI tooling space lately, you've probably seen both MCP (Model Context Protocol) and ACP (Agent Client Protocol) pop up in the same conversations. I kept mixing them up at first — both use JSON-RPC 2.0, both run over stdio, both live in the AI-dev-tooling world. But once I actually read through the specs and built things with each, the distinction became very clear.

They solve different problems at different layers of the stack. This article is my attempt to clearly explain both and where they fit.

---

What is MCP (Model Context Protocol)?

MCP is an open-source standard — now part of LF Projects — for connecting AI applications to external systems: data sources, tools, and workflows.

The official analogy is apt: think of it as a USB-C port for AI applications. Just like USB-C provides a universal physical interface for charging, data transfer, and display output, MCP provides a universal protocol interface for an AI application to access:

• Files and databases (resources)

• APIs and executables (tools)

• Prompt templates (prompts)

MCP Architecture

MCP follows a client-server model with three distinct participant roles:

MCP Host (AI Application, e.g. VS Code, Claude Desktop)
  ├── MCP Client 1 ──── MCP Server A (e.g. Filesystem)
  ├── MCP Client 2 ──── MCP Server B (e.g. Database)
  └── MCP Client 3 ──── MCP Server C (e.g. Remote API)

• MCP Host: The AI application that manages clients (e.g. VS Code, Claude Desktop)

• MCP Client: One per server connection, maintained by the host

• MCP Server: Exposes context (tools, resources, prompts) to clients

MCP Transport

MCP supports two transport mechanisms:

Transport	Use case	Details
stdio	Local processes	stdin/stdout streams, zero network overhead
Streamable HTTP	Remote servers	HTTP POST + optional Server-Sent Events, supports OAuth

MCP Primitives

The three server-side primitives that define what an MCP server can offer:

Primitive	Purpose	Example
Tools	Executable functions the AI can call	run_query, read_file, http_get
Resources	Read-only data/context	Database schema, file contents
Prompts	Reusable LLM interaction templates	System prompts, few-shot examples

The client-side primitives that servers can request back from the host:

• Sampling — ask the host AI to run an LLM completion

• Elicitation — prompt the user for input or confirmation

• Logging — send log messages back to the client

MCP Protocol Flow

Everything is JSON-RPC 2.0:

// 1. Initialization — capability negotiation
{ "method": "initialize", "params": { "protocolVersion": "2025-06-18", "capabilities": { "elicitation": {} } } }

// 2. Tool discovery
{ "method": "tools/list" }

// 3. Tool execution
{ "method": "tools/call", "params": { "name": "read_file", "arguments": { "path": "/etc/hosts" } } }

// 4. Real-time updates (no id = notification)
{ "method": "notifications/tools/list_changed" }

---

What is ACP (Agent Client Protocol)?

ACP is an open standard that standardizes how code editors communicate with AI coding agents. It emerged from the same frustration that drove LSP (Language Server Protocol) — every editor was building custom integrations for every agent, and every agent had to implement editor-specific APIs.

ACP solves this the same way LSP did for language tooling: define one protocol, implement it once on each side.

ACP's Problem Space

Without ACP:

• Zed needs custom Cline integration, custom Copilot integration, custom OpenHands integration...

• Each agent needs to know Zed-specific APIs, VS Code-specific APIs, JetBrains-specific APIs...

With ACP:

• Editors implement ACP once

• Agents implement ACP once

• Everything interoperates

In 2026, agents like GitHub Copilot, Cline, Gemini CLI, OpenHands, Goose, Codex CLI, and Claude Agent all implement ACP.

ACP Architecture

Code Editor (ACP Client)
  │
  │  stdin/stdout (local subprocess)
  │  OR HTTP/WebSocket (remote)
  │
AI Coding Agent (ACP Server/Agent)
  │
  │  connects to
  │
MCP Servers (tools, file systems, APIs)

ACP agents can also be MCP clients — the editor passes MCP server configuration to the agent, and the agent connects to those MCP servers for tool access. Both protocols are in play simultaneously.

ACP Message Flow

1. initialize         (Client → Agent): version negotiation and capabilities
2. authenticate       (Client → Agent): if the agent requires auth
3. session/new        (Client → Agent): create a conversation session
4. session/prompt     (Client → Agent): send user message
   session/update     (Agent → Client): stream progress, diffs, tool calls (notification)
   session/request_permission (Agent → Client): ask user to approve a tool call
5. session/prompt response: stop reason, final output

ACP Client Capabilities (Editor → Agent)

The editor can expose these to agents:

Method	What it gives the agent
fs/read_text_file	Read any file in the project
fs/write_text_file	Write/patch files
terminal/create	Spawn and control a terminal
terminal/output	Retrieve terminal output and exit code
session/request_permission	Gate tool calls behind user approval

ACP's Design Principles

From the spec:

1. MCP-friendly — reuses MCP's JSON types so integrators don't have to build new representations

2. UX-first — designed to render diffs, show agent intent, stream output clearly

3. Trusted — assumes the user is in control; agents ask permission before acting

---

The Core Difference, Side by Side

	MCP	ACP
What it connects	AI apps ↔ data/tools/APIs	Code editors ↔ AI coding agents
Direction of capability	Servers expose context TO AI	Agents work inside editor, editor exposes FS/terminal TO agent
Primary analogy	USB-C port for AI	LSP for coding agents
Transport	stdio or Streamable HTTP	stdio (subprocess) or HTTP/WebSocket
Protocol	JSON-RPC 2.0	JSON-RPC 2.0 (reuses MCP types)
Core primitives	Tools, Resources, Prompts	Sessions, File system, Terminals, Diffs, Permissions
Lifecycle unit	Tool call / Resource read	Conversation session
Who's the "server"	The data/tool provider	The AI agent
Who's the "client"	The AI application	The code editor (IDE)
Scope	General AI applications	Code editors and coding agents
Relation to each other	Foundational layer	Builds on top — agents use MCP internally

---

How They Fit Together

The most important thing to understand: these two protocols are complementary, not competing.

┌─────────────────────────────────────────┐
│         Code Editor (e.g. Zed, VS Code) │
│              ACP Client                 │
└───────────────────┬─────────────────────┘
                    │  ACP (JSON-RPC/stdio)
                    ▼
┌─────────────────────────────────────────┐
│         AI Coding Agent (e.g. Cline)    │
│    ACP Agent  +  MCP Client             │
└──────┬──────────┬───────────────────────┘
       │          │  MCP (JSON-RPC/stdio or HTTP)
       ▼          ▼
  MCP Server   MCP Server
 (Filesystem) (Database)

The editor talks to the agent over ACP. The agent talks to external tools over MCP. The editor may optionally expose its own MCP server (proxied back through itself) to give the agent access to editor-native tooling.

---

When Would You Implement Each?

Implement MCP when you want to:

• Expose a database, API, or toolset to any AI application

• Add capabilities to Claude, VS Code Copilot, or any MCP-compatible AI

• Build a reusable integration that many AI tools can consume

Implement ACP when you want to:

• Build a coding agent that works inside any compatible editor

• Build a code editor that supports any ACP-compatible agent

• Create a first-class IDE experience for your AI assistant

---

Summary

MCP answers: "How does an AI application get context and call tools in external systems?"

ACP answers: "How does a code editor talk to an AI agent and give it access to the development environment?"

Both use JSON-RPC 2.0. Both run over stdio locally. ACP even reuses MCP's type definitions intentionally to reduce duplication. But their problem domains, their participants, and their lifecycles are fundamentally different.

Understanding the layer each protocol operates at makes it easy to know which one you need — or when you need both.

---

Further Reading

• MCP Official Docs

• MCP Architecture

• ACP Official Docs

• ACP Protocol Overview

• ACP Architecture