MCP 2026-07-28 规范已正式发布。协议核心改为无状态请求，移除初始化握手和会话 ID，让远程 MCP 服务器可以部署在无服务器、边缘平台或普通负载均衡器之后；TypeScript、Python、Go 与 C# 的 Tier 1 SDK 已同步支持。
MCP 服务器不再绑定一段会话
MCP 是 Model Context Protocol 的缩写，中文通常称为模型上下文协议。它规定 AI 应用如何用统一方式连接外部工具、数据和服务，例如让聊天助手查询数据库、调用企业系统或执行代码。
旧版协议通过 Streamable HTTP 调用工具时，客户端要先完成 initialize 与 initialized 握手。服务器随后发放 Mcp-Session-Id，后续请求都要携带这个会话标识。部署多个服务器实例时，请求通常需要持续回到保存该会话的实例，或者由所有实例共用一套会话存储。
2026-07-28 版本移除了这套协议级会话。每个请求都会携带协议版本和客户端能力等信息，可以由任意兼容的服务器实例独立处理。客户端如需提前了解服务器支持的版本和能力，可以调用新的 server/discover 方法。
无状态核心降低云端扩容门槛
没有协议级会话后，同一客户端的不同请求可以被普通轮询负载均衡器分配到不同实例。服务器不再为了维持 MCP 连接而依赖粘性路由或共享会话存储，也能在请求到来时启动实例、空闲时缩减资源。因此，MCP 服务器可以作为普通 HTTP 工作负载部署到无服务器平台、边缘计算平台或容器集群。
这项变化解决的是协议层的部署限制，不是一个新的云托管产品。开发者仍需选择实际运行代码的平台，并自行配置域名、鉴权、日志、数据访问权限和资源限额。业务确实需要跨请求保存状态时，也可以由工具返回明确的标识，例如购物篮 ID 或浏览器任务 ID，再由后续调用把它作为普通参数传回服务器。
网关可以直接读取工具与方法名称
新版 Streamable HTTP 请求必须带上 Mcp-Method 和 Mcp-Name 请求头。前者表示调用的方法，后者可标识具体工具。负载均衡器、API 网关、限流器和 Web 应用防火墙可以直接根据请求头做路由、授权或计量，不必先解析 JSON 请求体。
工具、提示词和资源列表的响应也增加了 ttlMs 与 cacheScope。客户端由此知道结果可以缓存多久，以及缓存能否在不同用户间共享。服务器还应以稳定顺序返回工具列表，减少重复拉取，并让上游提示词缓存更容易命中。
多轮交互不再依赖持续打开的双向连接
工具执行到一半时，有时需要用户补充参数或确认操作。新版引入 Multi Round-Trip Requests，简称 MRTR。服务器可以返回 input_required，列出需要客户端补充的内容；客户端取得回答后，再带着 inputResponses 重试原来的请求。
这套方式替代了部分服务器主动向客户端发起请求的流程。一次交互可以拆成多个完整的请求与响应，不必为了等待用户确认而一直占用双向数据流。服务器返回的 requestState 用来衔接步骤，任何可处理该状态的实例都能继续任务。
扩展与授权规则同步更新
新规范建立了正式的扩展框架。MCP Apps 可让服务器向支持它的客户端提供沙箱化交互界面；Tasks 扩展用于处理需要较长时间运行的工作，并通过任务句柄查询、更新或取消任务。扩展需要客户端和服务器共同支持，不会因为升级核心协议而自动启用。
授权部分增加了对 OAuth 2.0 与 OpenID Connect 部署的约束。客户端要校验授权响应里的发行者信息，注册凭据也必须绑定到签发它的授权服务器。动态客户端注册继续兼容旧实现，但已进入弃用流程，后续方向是 Client ID Metadata Documents。
Roots、Sampling、Logging 以及旧的 HTTP+SSE 传输方式也被标记为弃用。它们在至少 12 个月的弃用窗口内继续工作，新项目应采用规范给出的替代方案。
开发者需要升级两端实现
新版本包含破坏性变更，不能只改部署配置就让旧服务器自动变成无状态。TypeScript、Python、Go 和 C# 的 Tier 1 SDK 已支持 2026-07-28，Rust SDK提供测试版支持。开发者应先查看所用语言 SDK 的迁移说明，再分别升级客户端和服务器，并通过版本协商保留与旧实现的连接能力。
如果现有服务器依赖 Mcp-Session-Id、初始化阶段保存的客户端信息、服务器主动请求或长连接恢复机制，迁移时需要把相关状态改为显式参数、MRTR 或新的订阅机制。已经按独立 HTTP 请求设计的远程服务器，改造范围通常集中在协议头、请求元数据、发现方法和 SDK 接口。