MCP正式版发布：你的MCP Server要改什么？12个月迁移窗口指南

Wed, 05 Aug 2026 08:30:00 +0800

2025年，Simon Willison在年度总结里给MCP泼了冷水——协议太复杂，被Skills取代了，“没人会大规模用"是他的基本判断。

2026年7月31日，同一个人一周内写了三个MCP项目（mcp-explorer、datasette-mcp、llm-mcp-client），然后发了篇博客：“Stateless MCP has recaptured my interest.”

态度反转的原因只有一个：MCP 2026-07-28正式版把协议从"带状态的长连接"改成了"无状态的HTTP请求”。这一刀砍掉了部署中最复杂、最容易出问题的部分。

我花了一天时间整理这份迁移指南。如果你有正在跑的MCP Server，这12个月窗口期你需要知道的事都在这里了。

核心变更1：无状态协议

这是最大的变化，也是Simon回心转意的原因。

旧版流程（3步握手）：

1
2
3
4
5
6
7
8


POST /mcp
→ {"method": "initialize", "params": {...}}
← {"result": {"sessionId": "abc123"}}

POST /mcp
Header: Mcp-Session-Id: abc123
→ {"method": "tools/list"}
← {"result": {"tools": [...]}}

新版流程（单次自包含请求）：

1
2
3
4
5
6


POST /mcp
Header: MCP-Protocol-Version: 2026-07-28
Header: Mcp-Method: tools/list
Header: Mcp-Name: my-server
→ {"method": "tools/list", "_meta": {"protocolVersion": "2026-07-28", "clientInfo": {...}}}
← {"result": {"tools": [...]}}

三个关键变化：

变化	旧版	新版
初始化	initialize/initialized 握手	每个请求自带 `_meta`
会话	Mcp-Session-Id 维持状态	无状态，请求自包含
发现	initialize 返回能力	`server/discover` 方法

这意味着：任何MCP请求可以落在任何服务器实例上，不需要粘性路由，不需要共享会话存储。水平扩展瞬间变得简单。

对于需要状态的场景（比如购物车），规范推荐用显式Handle模式——服务器返回一个 basket_id，模型在后续调用中传回。这比隐藏的会话状态更透明，模型可以跨工具组合Handle、推理Handle。

核心变更2：Extensions框架

旧版MCP的所有功能都挤在规范里，加一个新功能就要改规范。新版引入了Extensions框架：

反向DNS标识符（如 com.anthropic.mcp.apps）
通过 extensions map 协商
独立仓库 ext-*，委托维护者
独立于规范版本化

两个官方扩展值得关注：

MCP Apps（SEP-1865）：服务器可以渲染HTML UI，在沙箱iframe中运行。这意味着MCP工具不再只是返回JSON数据，可以直接给用户一个交互界面。

Tasks（SEP-2663）：从实验核心功能毕业为扩展。API有变化——tasks/list 被移除，新增 tasks/get、tasks/update、tasks/cancel。如果你在用Tasks，这是必改项。

核心变更3：三项功能废弃

12个月最低弃用窗口，2028年7月前必须迁移：

废弃功能	替代方案	迁移难度
Roots	Tool参数、resource URI或服务器配置	低
Sampling	直接集成LLM provider API	中
Logging	stderr（stdio）或OpenTelemetry	低

Roots和Logging的迁移基本是改几行配置。Sampling稍复杂——如果你的Server依赖Sampling让宿主LLM做决策，需要改成自己直接调LLM API。

迁移检查清单

以下是你的MCP Server需要改的内容，按优先级排列：

必须改（破坏性变更）：

1
2
3
4
5


□ 移除 initialize/initialized 握手逻辑
□ 移除 Mcp-Session-Id 处理
□ 添加 Mcp-Method 和 Mcp-Name 响应头
□ 更新错误码 -32002 → -32602
□ inputSchema 升级到 JSON Schema 2020-12

应该改（功能迁移）：

1
2
3
4


□ 迁移 Tasks API（移除 tasks/list，添加 get/update/cancel）
□ 替换 Roots 为 Tool 参数或服务器配置
□ 替换 Sampling 为直接 LLM API 集成
□ 替换 Logging 为 stderr 或 OpenTelemetry

可以做（新能力）：

1
2
3


□ 启用 tools/list 的 ttlMs 和 cacheScope 缓存
□ 集成 W3C Trace Context（traceparent/tracestate）
□ 探索 MCP Apps 扩展（服务器渲染UI）

生态影响

这些数字说明MCP已经不是实验品了：

SDK月下载量接近5亿次，TypeScript和Python各自突破10亿次总下载
Gartner预测：2026年底75%的API网关厂商将加入MCP特性
微软Azure正在全面适配MCP 2.0无状态架构
FastMCP v3.4.5已发布（2026-07-28），原生支持2026-07-28规范

如果你用FastMCP框架，升级到v3.4.5可以自动处理大部分迁移。但底层逻辑还是建议理解清楚——框架帮你屏蔽了复杂度，但出了问题你得知道往哪看。

结论

MCP从"太复杂没人用"到"一个人一周写三个项目"，核心原因是无状态架构砍掉了部署中最反人类的部分。

12个月窗口期听着很长，但如果你的MCP Server有用户在用，建议现在就开始改。先改破坏性变更（握手和Session），再逐步迁移废弃功能。

Simon Willison用一周写了三个项目证明新协议的简洁。你的Server迁移大概用不了三天。

varkm