读懂 MCP：一个统一协议的机制拆解

读懂 MCP：一个统一协议的机制拆解
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年 11 月开源的协议，目的是给"LLM 应用连接外部数据与工具"这件事定一套标准接口。下面把它拆开讲清楚。

一、它到底解决什么问题
在没有统一标准之前，每个 AI 应用要接入文件系统、数据库、Git、Slack，都得为每个数据源单独写一份适配代码。集成数量是 模型侧数量 × 数据源数量，即 M×N 问题：N 个应用 × M 个工具就要维护 N×M 套胶水代码。

MCP 的思路和 USB-C、LSP（Language Server Protocol）一样：定义协议，而非定义实现。数据源实现一次 MCP Server，AI 应用实现一次 MCP Client，双方通过协议对接。集成量从 M×N 降到 M+N。协议本身与具体模型、具体框架解耦，谁实现都能互通。

二、三个角色：Host、Client、Server
Host（宿主）：面向用户的应用本体，比如 IDE、聊天客户端、Agent 运行时。它负责整体调度和权限决策。
Client（客户端）：位于 Host 内部，为每个 Server 维护一条独立连接。Host 里跑的是多个 Client 实例，一个 Client 对应一个 Server，连接之间互相隔离。
Server（服务端）：真正提供能力的一方，暴露资源、工具、提示词。可以是本地进程，也可以是远程服务。
关键点：Client 不是"服务器";它是 Host 与 Server 之间的连接端点。这种一对一设计让能力边界清晰，也让每个 Server 的权限能单独管控。

三、通信底座：JSON-RPC 2.0 + 传输方式
协议层之上只用了三种消息类型：

Request：带 id，要求对端返回 Response。
Response：与某个 id 对应，返回结果或错误。
Notification：不带 id，不需要回复，单向通知。
所有消息都是 JSON-RPC 2.0。传输方式目前主要有两种：

stdio：Server 作为本地子进程运行，通过标准输入/输出收发消息。适合本机、低延迟、天然隔离的本地工具。
Streamable HTTP：远程场景。早期版本用 HTTP+SSE 双端点，后来演进为单一的 Streamable HTTP 端点，支持流式返回和服务端主动推送。
传输层是可插拔的，协议不绑定某一种。

四、Server 侧的三大原语
这是 MCP 最核心的设计。Server 对外暴露的能力被归为三类，语义不同、用途不同：

Tools（工具）：可执行的函数。模型可以调用它完成动作，例如查询数据库、发请求、写文件。工具是"模型主动发起"的调用。
Resources（资源）：可读取的数据。类似 HTTP GET，用来把文件内容、日志、表结构等作为上下文喂给模型。资源是"应用/用户提供"的读取，天然更偏只读、可缓存。
Prompts（提示模板）：服务端预设的提示词模板，供用户显式选择后填充使用。它把某类任务的最佳提示固化在 Server 侧，而不是散落在客户端。
区分的意义在于可控性：Resources 偏被动读取，Tools 偏主动执行，Prompts 偏用户显式触发。权限模型可以据此分级，而不是把一切都当成"能调用的函数"。

五、Client 侧也有能力
MCP 不是单向的。Client（进而 Host）同样可以向 Server 暴露能力，形成双向协商：

Sampling（采样）：Server 反过来请求 Host 调用 LLM 生成内容。这让 Server 自身不需要内置模型密钥，把模型调用权交回 Host 管控。
Roots（根目录）：Host 告诉 Server 可以访问哪些文件系统边界，避免 Server 越界读取。
Elicitation（诱导/索要输入）：Server 在需要补充信息时，请求向用户提问，由 Host 负责呈现与收集。
这一层的价值是控制权归属明确：模型调用、文件边界、用户交互都留在 Host 手里，Server 只能请求，不能擅自决定。

六、一次交互的生命周期
初始化（initialize）：Client 发送协议版本、自身能力等信息。
能力协商：双方交换各自支持的 capabilities，确定这次会话能用哪些原语。
就绪通知（initialized）：握手完成后进入正常运行阶段。
正常运行：按需发 discover（列出工具/资源/模板）、调用请求、读取请求、通知等。
关闭：任一端终止连接，会话结束。
整个过程是有状态、有版本协商的。协议版本不匹配或能力不支持时，双方会在协商阶段就明确，而不是运行到一半才报错。

七、几个直白的结论
MCP 不是框架，也不是某个产品的私有接口，而是一份开放协议规范，有多语言 SDK 和大量第三方实现。
它的核心贡献是抽象出三种原语 + 双向能力协商，把"随便塞个函数列表"变成了有语义、可分级授权的能力模型。
安全边界不是自动的。协议给了 Roots、权限决策、用户确认这些挂载点，但具体怎么授权、怎么审核工具调用，仍然由 Host 决定。把 MCP 当成安全魔法是误读。
落地时要区分 Tools 和 Resources：能只读拿到的用 Resource，别都做成 Tool；需要用户显式选择的用 Prompt，别硬塞进对话。
一句话总结：MCP 把"AI 接入外部世界"从点对点的重复适配，变成了可复用、可协商、可管控的标准接口层。机制不复杂，难的是边界设计和权限治理。