这份报告基于2026年5月31日的最新数据,协议版本为2024年11月5日发布的稳定版,目前由Linux Foundation Agentic AI Foundation(2025年11月起)维护。先简单说几个核心判断:MCP正在从一个实验性协议快速演变为AI应用与外部系统互操作的事实标准,其生态规模、平台支持和社区热度都已经到了不容忽视的阶段。
一、MCP 是什么?
Model Context Protocol(模型上下文协议,MCP) 是由 Anthropic 于 2024 年 11 月 25 日发布的开放标准协议,旨在解决 AI 应用与外部系统之间的标准化连接问题。
核心类比
| 类比 | 说明 |
|---|---|
| USB-C 接口 | MCP 是 AI 应用的"通用接口",任何支持 MCP 的客户端都能接入任何 MCP 服务器 |
| 插件协议 | 类似浏览器插件、VSCode 扩展的协议层,但专为 AI 设计 |
| 解决的核心痛点 | 每个 AI 平台(Claude/Cursor/GitHub Copilot)都要重复适配相同的外部工具,MCP 让"开发一次,到处运行"成为现实 |
发展历程
2024-11-25 Anthropic 发布 MCP 协议(初版) 2025-06 社区月度新增 MCP 服务器从 135 个激增至 5,069 个 2025-09 MCP Registry 发布预览版 2025-11 MCP 正式移交 Linux Foundation Agentic AI Foundation 治理 2025-11 MCP 规范更新:新增 Tasks 原语 + Authorization 扩展(企业级能力) 2026-03 OpenAI、Google DeepMind、Microsoft 相继宣布支持 MCP 2026-05 GitHub MCP Registry 上线,awesome-mcp-servers 累计 85,000 Stars
二、核心架构
MCP 采用客户端-服务器架构,三个核心角色各司其职:
┌─────────────────────────────────────────────────┐
│ Host 主机应用 │
│(Claude Desktop / Cursor / IDE) │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ MCP Client│ │ MCP Client│ │
│ │ (1:1) │ │ (1:1) │ │
│ └────┬─────┘ └────┬─────┘ │
└───────┼──────────────────────┼───────────────────┘
│ Transport Layer │
│ (stdio / HTTP SSE) │
▼ ▼
┌────────────┐ ┌────────────┐
│ MCP Server │ │ MCP Server │
│ (独立进程) │ │ (独立进程) │
└────────────┘ └────────────┘
提供:文件系统 提供:GitHub API
角色定义
| 角色 | 定义 | 职责 | 示例 |
|---|---|---|---|
| Host | 发起连接的 LLM 应用 | 管理 MCP 客户端生命周期,聚合结果 | Claude Desktop、Cursor、Windsurf |
| Client | 运行在 Host 内的组件 | 与单个 Server 维持 1:1 持久连接,处理消息帧、请求/响应关联 | 内嵌在 Host 中的 MCP 客户端实例 |
| Server | 提供能力的独立进程 | 暴露上下文/工具/提示词模板,响应请求,推送通知 | filesystem、postgres、slack 等服务器 |
关键约束:每个 Client 只连接一个 Server;每个 Server 同时只服务一个 Client;一个 Host 可运行多个 Client 并行工作。
三、传输层(Transport Layer)
所有传输均使用 JSON-RPC 2.0 作为消息编码格式。
3.1 Stdio(标准输入输出)
适用场景:本地进程通信、命令行工具、简单 IPC
| 特性 | 说明 |
|---|---|
| Client → Server | 写入 Server 的 stdin |
| Server → Client | 写入 Server 的 stdout |
| 日志输出 | Server 的 stderr 用于日志 |
| 优点 | 无需网络配置,进程管理简单 |
| 缺点 | 仅限本地,不支持远程访问 |
Python 服务端示例:
from mcp.server import Server
from mcp.server.stdio import stdio_server
app = Server("example-server")
async def main():
async with stdio_server() as streams:
await app.run(streams[0], streams[1], app.create_initialization_options())
if __name__ == "__main__":
import asyncio
asyncio.run(main())
3.2 HTTP + SSE(服务端推送事件)
适用场景:远程通信、跨网络访问、需要服务端主动推送的场景
| 方向 | 协议 | 实现方式 |
|---|---|---|
| Server → Client | SSE | 长连接 HTTP 响应,服务端推送消息 |
| Client → Server | HTTP POST | 客户端向 /messages 端点发送请求 |
关键安全补充:HTTP SSE 传输必须额外实现认证(OAuth 2.1)和授权逻辑。
Python(Starlette)服务端示例:
from mcp.server.sse import SseServerTransport
from starlette.applications import Starlette
from starlette.routing import Route
sse = SseServerTransport("/messages")
async def handle_sse(scope, receive, send):
async with sse.connect_sse(scope, receive, send) as streams:
await app.run(streams[0], streams[1], app.create_initialization_options())
async def handle_messages(scope, receive, send):
await sse.handle_post_message(scope, receive, send)
starlette_app = Starlette(routes=[
Route("/sse", endpoint=handle_sse),
Route("/messages", endpoint=handle_messages, methods=["POST"]),
])
3.3 自定义传输
可实现 Transport 接口以支持专有协议、遗留系统对接等场景。
四、消息类型(JSON-RPC 2.0)
| 类型 | 是否有id | 是否需要响应 | 说明 |
|---|---|---|---|
| Request | ✅ 有 | ✅ 需要 | 发起操作调用 |
| Notification | ❌ 无 | ❌ 不需要 | 单向通知,即发即忘 |
| Result | ✅ 有(匹配 Request 的 id) | N/A | 请求成功响应 |
| Error | ✅ 有(匹配 Request 的 id) | N/A | 请求失败响应 |
标准错误码
| 代码 | 名称 | 说明 |
|---|---|---|
-32700 | ParseError | JSON 解析失败 |
-32600 | InvalidRequest | 无效的请求对象 |
-32601 | MethodNotFound | 方法不存在 |
-32602 | InvalidParams | 参数无效 |
-32603 | InternalError | 内部错误 |
-32000 以下 | 自定义错误 | 各服务器可自行扩展 |
五、连接生命周期与能力协商
初始化握手(Initialize Handshake)
Client ---> Server: initialize 请求(含 protocolVersion、capabilities、clientInfo) Server ---> Client: initialize 响应(含 protocolVersion、capabilities、serverInfo) Client ---> Server: notifications/initialized(单向通知,无 id) === 连接就绪,开始正常消息交换 ===
能力协商核心逻辑:
- Client 和 Server 在
initialize阶段交换capabilities对象 - 只有双方都声明支持的能力才会被启用
- 这确保了前后端能力匹配,避免不支持的功能被调用
Client 能力示例:
{
"capabilities": {
"roots": { "listChanged": true },
"sampling": {}
}
}
Server 能力示例:
{
"capabilities": {
"resources": { "subscribe": true, "listChanged": true },
"prompts": { "listChanged": true },
"tools": { "listChanged": true },
"logging": {}
}
}
六、三大核心原语
MCP 服务器可暴露三种能力原语,均在初始化阶段通过 capabilities 声明。
6.1 Resources(资源)—— 只读上下文数据
控制方:应用层(Client 决定如何使用) 用途:为 LLM 提供额外的上下文信息
| 属性 | 类型 | 必填 | 说明 |
|---|---|---|---|
uri | String | ✅ | 资源唯一标识符(如 file:///tmp/data.txt) |
name | String | ✅ | 人类可读名称 |
description | String | ❌ | 详细描述 |
mimeType | String | ❌ | MIME 类型 |
annotations | Object | ❌ | 附加元数据 |
工作流:
resources/list→ 获取资源列表(支持分页)resources/read→ 读取资源内容(文本或二进制 base64)resources/subscribe(可选)→ 订阅资源变更通知
6.2 Prompts(提示词模板)—— 可复用交互模板
控制方:用户层(通常作为斜杠命令或可选操作暴露) 用途:标准化常见 LLM 交互模式
| 属性 | 类型 | 必填 | 说明 |
|---|---|---|---|
name | String | ✅ | 模板唯一名称 |
description | String | ❌ | 用途描述 |
arguments | Array | ❌ | 模板参数列表(含 name/description/required) |
工作流:
prompts/list→ 获取可用提示词模板列表prompts/get→ 传入参数,获取渲染后的提示词内容
示例:代码审查提示词模板,接受 code(必填)和 language(可选)两个参数。
6.3 Tools(工具)—— 可执行函数 ⭐
控制方:模型层(LLM 自主决定是否调用) 用途:让 LLM 能够执行操作、调用外部 API、查询数据库等 这是 MCP 最核心、应用最广泛的能力原语
| 属性 | 类型 | 必填 | 说明 |
|---|---|---|---|
name | String | ✅ | 工具唯一名称 |
description | String | ✅ | 详细描述(LLM 据此决定是否调用,至关重要) |
inputSchema | Object | ✅ | JSON Schema 对象,定义输入参数 |
工作流:
tools/list→ 获取可用工具列表(LLM 读取description和inputSchema来决定是否调用)tools/call→ 执行工具,传入参数- 返回结果(
isError: false为成功,isError: true为失败)
