MCP（Model Context Protocol）：AI 世界的"USB-C"接口
一句话总结：MCP 是 AI 模型连接外部世界的"通用插头"------写一次，到处用。
一、为什么需要 MCP？
想象你买了 10 个不同品牌的手机，每个都需要专属充电器。更糟的是，每换一个新电器，你都要再买一根新线。这就是AI 集成在 MCP 出现之前的现状。
在 MCP 之前，如果 Claude 要连 GitHub、ChatGPT 要查数据库、Cursor 要调 Slack------每个组合都要写一套专属集成代码。10 个 AI 客户端 × 20 个数据源 = 200 个定制连接器，每个都有自己的认证逻辑、错误处理和运维负担。
MCP（Model Context Protocol，模型上下文协议） 由 Anthropic 于 2024 年 11 月提出，目标很简单：
让 AI 模型像插 USB-C 一样，一次对接，通吃所有工具和数据源。
二、MCP 核心架构：三个角色一台戏
MCP 采用经典的客户端-服务器架构，但拆得更细：
| 角色 | 是什么 | 例子 |
|---|---|---|
| Host（宿主） | 用户直接交互的 AI 应用 | Claude Desktop、Cursor、VS Code、ChatGPT |
| Client（客户端） | Host 内的连接管理器，负责与 Server 通信 | Claude 里的 MCP Client 实例 |
| Server（服务器） | 暴露外部能力的程序，通过 MCP 协议与 Client 对话 | GitHub MCP Server、数据库 MCP Server |
传输层（怎么通信）：
-
STDIO：本地子进程通信，适合本机工具（如文件系统、本地数据库）
-
Streamable HTTP：远程 HTTP 通信，适合云服务（2026 年新版主推）
-
HTTP+SSE：旧版远程方案，已正式废弃
三、MCP 的四大"原语"
MCP 不是让你随便暴露一个 API，而是规范了四种核心交互方式：
1. Tools（工具）------"帮我执行这个"
服务器暴露的可执行函数，带名称、描述和参数 Schema。模型看到工具描述后，决定要不要调用。
{ "name": "search_github_issues", "description": "搜索 GitHub 仓库的 Issues", "inputSchema": { "type": "object", "properties": { "repo": { "type": "string" }, "query": { "type": "string" } }, "required": ["repo", "query"] } }
2. Resources（资源）------"给我看看这个"
只读的结构化数据，通过 URI 标识。比如文件内容、数据库查询结果、API 响应。
URI: file:///project/README.md URI: db://users/active
3. Prompts（提示）------"按这个模板来"
服务器提供的预定义提示模板，用户可以选择使用。比如"生成代码审查报告"的标准模板。
4. Tasks（任务）------"这个活儿比较久"
2026 年新版将 Tasks 提升为正式扩展，支持长时间运行的后台任务，带轮询和状态更新。
四、一次完整的 MCP 调用长什么样？
假设你对 Claude 说："帮我查一下最近 3 天数据库里的异常订单"
① 用户输入 → Host（Claude Desktop） ↓ ② Claude（LLM）分析意图，发现需要调用数据库工具 ↓ ③ MCP Client 向 MCP Server（数据库）发送 tools/call 请求 ↓ ④ MCP Server 执行 SQL 查询，拿到结果 ↓ ⑤ 结果返回给 MCP Client，注入对话上下文 ↓ ⑥ Claude 基于真实数据生成回答 ↓ ⑦ 用户看到："最近 3 天有 12 笔异常订单，分别是..."
关键点：模型不知道"内置工具"和"MCP 工具"的区别------对它来说，都是可调用的函数。
五、2026 年最重大升级：MCP 变"无状态"了
2026 年 7 月 28 日，MCP 发布了迄今为止最重要的一版规范 2026-07-28。核心变化只有一个词：
Stateless（无状态）
5.1 之前的问题：有状态协议
旧版 MCP 要求客户端先"握手"（initialize），服务器返回一个 Mcp-Session-Id，后续每次请求都要带上这个 ID。
这在本机运行 时没问题，但放到生产环境就麻烦了：
-
负载均衡器后面有 100 台服务器，每台都要知道其他机器发的 Session ID
-
需要"粘性会话"（Sticky Sessions）或共享存储
-
运维复杂、成本高、扩展难
5.2 新版：每个请求自成一体
# ❌ 旧版（有状态） POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b {"jsonrpc":"2.0","id":2,"method":"tools/call",...} # ✅ 新版（无状态） POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}, "_meta":{"clientInfo":{"name":"my-app","version":"1.0"}}}}
好处：
-
✅ 任何请求可以落到任何服务器实例（普通轮询负载均衡即可）
-
✅ 不需要 Session 存储、不需要粘性路由
-
✅ 像普通 Web API 一样简单部署
-
✅ 网关可以直接根据
Mcp-Method和Mcp-Name头部做路由和限流
5.3 其他重要更新
| 特性 | 说明 |
|---|---|
| MRTR | 多轮往返请求------工具执行中需要用户确认时，服务器可以返回 input_required，客户端补充后再重试 |
| 缓存提示 | tools/list 等列表响应带 ttlMs 和 cacheScope，减少重复拉取 |
| 授权强化 | 支持 RFC 9207、Client ID Metadata Documents，更安全 |
| 废弃政策 | 已废弃功能（Roots、Sampling、HTTP+SSE）保证至少 12 个月兼容窗口 |
六、实战：5 分钟写一个 MCP Server
用 Python 写一个最简单的"天气查询" MCP Server。
6.1 安装依赖
pip install mcp
6.2 写 Server
python
# weather_server.py
from mcp.server import Server
from mcp.types import Tool, TextContent
import asyncio
app = Server("weather-server")
@app.list_tools()
async def list_tools():
return [
Tool(
name="get_weather",
description="查询指定城市的当前天气",
inputSchema={
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如'北京'"
}
},
"required": ["city"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "get_weather":
city = arguments["city"]
# 这里调用真实天气 API
result = f"🌤️ {city} 当前天气：晴，25°C，湿度 60%"
return [TextContent(type="text", text=result)]
raise ValueError(f"未知工具: {name}")
if __name__ == "__main__":
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(app))6.3 配置到 Claude Desktop
编辑 ~/Library/Application Support/Claude/claude_desktop_config.json（Mac）：
{ "mcpServers": { "weather": { "command": "python", "args": ["/path/to/weather_server.py"] } } }
重启 Claude Desktop，在对话里输入"北京天气怎么样？"，Claude 就会自动调用你的 MCP Server！
七、MCP 生态有多火？
| 指标 | 数据 |
|---|---|
| SDK 月下载量 | ~5 亿（2026 年 7 月） |
| 公开 MCP Server 数量 | 17,000+ |
| 支持 MCP 的 AI 平台 | Claude、ChatGPT、Gemini、Cursor、VS Code、Windsurf、JetBrains |
| 治理 | 2025 年 12 月捐赠给 Linux Foundation（AAIF），与 Kubernetes 同级 |
八、MCP vs API：不是替代，是封装
很多人问：MCP 和普通 REST API 有什么区别？
| 维度 | 普通 API | MCP |
|---|---|---|
| 发现机制 | 需要读文档 | 自动 tools/list 发现 |
| 参数描述 | 文档里写 | JSON Schema 标准化，模型直接理解 |
| 上下文管理 | 自己拼 Prompt | 协议层自动注入 |
| 多工具编排 | 自己写代码 | 模型自主决定调用哪个 |
| 集成成本 | 每个客户端单独对接 | 一次 MCP，到处可用 |
MCP 不是替代 API，而是给 API 套了一个"AI 友好的标准化外壳"。
九、MCP 与 A2A：互补而非竞争
Google 推出的 A2A（Agent-to-Agent） 协议和 MCP 经常被拿来比较，其实它们解决不同问题：
| 协议 | 解决什么问题 | 类比 |
|---|---|---|
| MCP | Agent 怎么连工具和数据源 | USB-C 接口 |
| A2A | Agent 之间怎么协作 | 微信/邮件（Agent 间的通信） |
一个 Agent 可以用 MCP 查数据库，再通过 A2A 把结果发给另一个 Agent 处理------两者是**垂直连接（MCP）+ 水平协作（A2A）**的关系。
十、总结：MCP 是 AI 基础设施的"最后一公里"
MCP 最大的价值，是把**"AI 连外部世界"**这件事从"每个项目定制开发"变成了"标准化插拔"。
| 阶段 | 状态 |
|---|---|
| 2024.11 | Anthropic 发布 MCP |
| 2025.12 | 捐赠给 Linux Foundation，中立治理 |
| 2026.07 | 发布无状态核心，正式生产级 |
| 未来 | 更多 SaaS 厂商提供第一方 MCP Server，企业级授权和审计成熟 |
🎯 核心心法：如果你在做 AI 应用，MCP 是你必须了解的"通用语言"。它让模型从"只会聊天"变成"真的能干活"------而且不需要为每个工具写一遍胶水代码。