1. 协议栈解剖：不仅仅是 API
MCP 并非某种高级的 AI 魔法，而是一个运行在标准传输层之上的应用层协议。它的核心设计哲学是将 AI 模型（Host）与外部工具（Server）之间的交互标准化，从而解决 N×M 的集成复杂度问题。
Model Context Protocol (MCP) 是由 Anthropic 于 2024 年底开源，并在 2026 年确立为事实标准的开放协议。它的核心目标是解决 AI 模型与外部数据源、工具和服务之间的连接碎片化问题。
正如 USB-C 统一了硬件设备的物理接口，MCP 统一了 AI 模型与外部世界的数字接口。截至 2026 年 3 月，MCP SDK 月下载量已突破 9700 万，GitHub 星标数超过 8.1 万，并获得 OpenAI、Google、Microsoft、Meta 等全行业巨头的原生支持。
2025 年 12 月，MCP 的治理权正式移交至 Linux Foundation 旗下的 Agentic AI Foundation (AAIF)，标志着该协议从初创项目正式迈向企业级基础设施标准。
三大核心角色
| 角色 | 定义 | 典型示例 |
|---|---|---|
| MCP Host | 运行 LLM 的 AI 应用程序，负责发起连接。 | Claude Desktop, Cursor, VS Code, OpenClaw |
| MCP Client | 由 Host 创建的连接器，管理与 Server 的 1:1 会话。 | 内置于 Host 进程中的客户端库 |
| MCP Server | 暴露外部能力（工具、数据）的轻量级服务。 | GitHub Server, PostgreSQL Server, Slack Server |
三大基本原语 (Primitives)
MCP Server 通过以下三种原语向 AI 暴露能力：
- Tools (工具): 模型可以调用的可执行函数（如
execute_sql,send_email）。这是 Agent 执行动作的主要方式。 - Resources (资源): 模型可以读取的数据源（如文件、数据库视图、API 响应）。类似于 URI 可寻址的”文件”。
- Prompts (提示词): 预配置的模板，帮助模型理解如何与特定数据或工具交互。
1.1 传输层演进 (Transport Layer)
MCP 支持多种传输机制，以适应不同的部署环境。2026 年的规范中，传输层发生了重要演进：
- Stdio (标准输入输出): 本地部署的首选。Host 将 Server 作为子进程启动，通过 stdin/stdout 进行通信。零网络开销，天然隔离。
- HTTP + SSE (Server-Sent Events): 早期远程方案。POST 发送请求，SSE 接收响应和推送。需要两个端口或路径，状态管理复杂。
- Streamable HTTP (2026 新标准): 统一了双向通信。单端口支持请求-响应和服务器推送，原生支持会话 ID (
Mcp-Session-Id) 和断线重连 (Resumability)。
1.2 消息层：JSON-RPC 2.0
MCP 的所有消息均遵循 JSON-RPC 2.0 规范。这种选择确保了协议的轻量级和语言无关性。消息分为三类：
| 类型 | 结构特征 | 用途 |
|---|---|---|
| Request | 包含 id (number/string) |
Client 发起操作 (如 tools/list) |
| Response | 包含 id (匹配 Request) 和 result 或 error |
Server 返回结果 |
| Notification | 无 id 字段 |
单向通知 (如 notifications/resources/changed) |
2. 交互生命周期 (Deep Dive)
一个标准的 MCP 会话并非随意开始，而是遵循严格的状态机流转。理解这一过程是调试和开发自定义 Server 的关键。
2.1 握手与能力协商 (Handshake)
每个会话必须以 initialize 请求开始。这是双方交换”底牌”的时刻：
- 版本协商: Client 声明支持的协议版本（如
2024-11-05）。如果 Server 不支持，必须立即终止连接。 - 能力声明 (Capabilities):
- Client: 声明是否支持
roots(文件系统上下文) 和sampling(允许 Server 请求 LLM 调用)。 - Server: 声明是否提供
tools,resources,prompts,logging等。
- Client: 声明是否支持
只有在 Client 发送 notifications/initialized 后，Server 才能开始主动推送消息或处理业务请求。
2.2 运行时原语 (Runtime Primitives)
MCP 通过三个核心原语暴露能力，它们在底层均映射为特定的 JSON-RPC 方法：
- Tools: 映射到 LLM 的 Function Calling。
tools/list返回工具列表及 JSON Schema 定义。tools/call执行工具并返回content(Text, Image, 或 Resource)。 - Resources: URI 可寻址的数据源。
支持resources/list,resources/read。
支持订阅模式resources/subscribe，当数据变更时 Server 推送notifications/resources/updated。 - Prompts: 预定义的交互模板。
帮助 Client 快速构建复杂的上下文提示词。
3. 底层实现揭秘：手写 JSON-RPC
为了真正理解 MCP，我们抛开 SDK，直接观察底层的 JSON 报文。这是 AI 模型与工具交互的真实数据流。
3.1 工具发现 (Tool Discovery)
Client 询问 Server 有哪些可用工具：
// Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": { "cursor": null }
}
// Response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [{
"name": "get_weather",
"description": "Get weather for a city",
"inputSchema": {
"type": "object",
"properties": {
"city": { "type": "string", "description": "City name" }
},
"required": ["city"]
}
}]
}
}3.2 工具调用 (Tool Execution)
LLM 决定调用工具后，Client 转发请求：
// Request
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "Beijing" }
}
}
// Response
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [{
"type": "text",
"text": "Current weather in Beijing: Sunny, 25°C"
}],
"isError": false
}
}极客洞察： MCP Server 返回的 content 是一个数组，支持混合类型（文本、图片 Base64、资源引用）。这使得多模态模型能够同时接收多种格式的上下文。
4. 安全架构：OAuth 2.1 与动态注册
在 2026 年的企业级部署中，安全性是 MCP 的核心考量。对于远程 Server，MCP 规范强制推荐使用 OAuth 2.1。
4.1 认证流 (Authorization Flow)
MCP 采用了针对公共客户端优化的 OAuth 2.1 流程，核心包括：
- PKCE (Proof Key for Code Exchange): 防止授权码拦截攻击，无需 Client Secret。
- Protected Resource Metadata (RFC 9728): Server 必须在
/.well-known/oauth-protected-resource暴露元数据，Client 据此自动发现认证服务器地址。
4.2 动态客户端注册 (DCR)
由于 MCP 生态中存在海量 Client，静态注册 Client ID 是不现实的。MCP 支持 Dynamic Client Registration (DCR)：
- Client 首次连接时，向 Server 的
/register端点发送注册请求。 - Server 返回
client_id和client_secret(如果是机密客户端)。 - Client 使用凭据发起 OAuth 流程。
4.3 权限隔离 (Scopes & Least Privilege)
Server 应通过 Scope 实现细粒度权限控制。例如：
weather:read: 仅允许查询天气。github:write: 允许创建 PR 或 Issue。
Host 应在 UI 中明确展示请求的 Scope，并要求用户确认（Human-in-the-loop）。
5. 高级模式：Roots 与 Sampling
除了基础的工具调用，MCP 还定义了一些高级模式，用于增强 Agent 的上下文感知和自主性。
5.1 Roots (上下文感知)
Client 可以通过 roots/list 告知 Server 当前用户关注的”根目录”或”上下文范围”。例如，在 IDE 中，Root 可能是当前打开的项目文件夹。Server 可以利用这些信息优化搜索结果或过滤无关数据。
5.2 Sampling (反向 LLM 调用)
这是 MCP 最独特的设计之一。Server 可以向 Client 发送 sampling/createMessage 请求，要求 Client 调用其连接的 LLM 生成内容。
应用场景： Server 是一个代码分析工具，它需要 LLM 总结代码片段，但 Server 本身没有 LLM 接入能力。它通过 Sampling 请求 Client 代为调用 LLM，并将结果返回给 Server 继续处理。
5.3 MCP Gateway (企业网关)
随着 Server 数量增加，直接管理变得困难。MCP Gateway 模式应运而生：
- 统一鉴权: 网关处理 OAuth，后端 Server 无需重复实现。
- 路由与负载均衡: 将请求分发到多个 Server 实例。
- 审计与日志: 记录所有 Tool Call，满足合规要求。
