& 为什么这次改版是大地震

MCP 是 AI 工具调用的“通用接口协议”。无论你使用的是 Claude、GPT 或 Gemini 等大模型，都能通过同一套标准调用外部工具、访问数据源与对接服务。

从基础调用示例来看。

const result = await client.callTool({
name这方面，"search",arguments:{ q:"otters" }
});

自2025年底起，MCP 成为 AI Agent 的主流协议。被 GitHub、主流 AI 开发编辑器等原生支持，并被 Anthropic 捐赠给 Linux 基金会，推动其成为领域通用标准。

这次改版的主要是彻底移除协议层有状态设计：旧版本依赖 initialize 握手 + Mcp‑Session‑Id 来维持会话；新版本转为完全无状态架构。每个请求自包含全部必要信息，任意实例均可独立处理。

旧规范设计与生产痛点

旧规范完整请求流程

类似传统 Web 的 Cookie/Session 模式：

# 客户端 → 服务端握手 → 获得 Session ID → 后续所有请求携带该 ID
POST /mcp { method:"initialize",params:{...} }
→ OK { Mcp‑Session‑Id:"UUID",... }
POST /mcp { Mcp‑Session‑Id:"UUID"。method:"tools/list",params:{} }
→ OK { tools: }
POST /mcp { Mcp‑Session‑Id:"UUID",method:"tools/call",params:{name:"search",arguments:{q:"otters"}} }
→ OK { content: }

三大主要痛点

• 负载均衡被会话绑定: 必须使用粘性会话，否则请求会被路由到不同实例导致失效；实例宕机会导致所有会话失效，需要重新握手。
• 水平 依赖共享存储: 必须引入 Redis 等统一保存 Session；每个请求需额外查询开销，还要处理过期、续期、降级等运维问题。
• 网关路由必须解析请求体: 为按方法路由，网关必须解析 JSON-RPC 请求体。Nginx 原生不支持，需要 Lua/NJS 增加性能开销与配置复杂度。其实，

真实 HTTP 请求：旧规范实测

步骤1：initialize 握手请求

POST /mcp
Content-Type: application/json
{
"jsonrpc":"","id":1,"method":"initialize","params":{
"protocolVersion":"--","capabilities":{},"clientInfo":{"name":"demo-client","version":""}
}
}

握手响应

HTTP/1.1 200 OK
Content-Type: application/json
Mcp‑Session‑Id: ce843e95‑50bc‑471f‑bd8b‑dcbcf75dc998
{
"jsonrpc":"","id":1,"result":{
"protocolVersion":"--","capabilities":{"tools":{"listChanged":true}},"serverInfo":{"name":"old-mcp-server","version":". "}
}
}

步骤2：携带会话调用 tools/list

POST /mcp
Mcp‑Session‑Id: ce843e95‑50bc‑471f‑bd8b‑dcbcf75dc998
Content-Type: application/json
{
"jsonrpc":""。"id":2,"method":"tools/list","params":{}
}

步骤3：不带会话直接请求

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"jsonrpc":"","id":3,"error":{
"code"这方面，-32602,"message":"Missing or invalid Mcp-Session-ID"
}
}

新规范主要的观点是，协议层无状态化

主要变更总览表格