MCP 2026-07-28 的发布候选版已正式推出。该协议现已无状态：无需握手，无会话 ID，任何请求均可由任意服务器实例处理。此外，扩展功能已成为一等公民（MCP 应用、任务），认证机制得到强化，并确立了正式的弃用策略，避免未来再次经历类似调整。

MCP 2026-07-28 规范发布候选版

来源：https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ MCP 2026-07-28 的发布候选版现已可用。这是自协议发布以来最大规模的修订，兑现了 2026 年路线图（https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/）中的承诺：

• 无状态核心，可在普通 HTTP 基础设施上扩展
• 扩展功能，包括通过 MCP 应用（https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#mcp-apps-server-rendered-user-interfaces）提供服务器渲染 UI，以及通过任务扩展（https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#tasks-graduates-to-an-extension）处理长时间运行的工作
• 授权机制，更贴近 OAuth 和 OpenID Connect 的实际部署
• 正式弃用策略，让协议能够在不破坏已有成果的前提下演进，

以及其他诸多变更。

该版本对生产部署的直接影响立竿见影。以前需要粘性会话、共享会话存储和网关深度包检测的远程 MCP 服务器，现在可以在普通的轮询负载均衡器后运行，通过 Mcp-Method 标头路由流量，并允许客户端在服务器 ttlMs 允许的时长内缓存 tools/list 响应。

发布候选版今日可用，最终规范将于 2026 年 7 月 28 日 发布。此版本包含破坏性变更；请参阅发布时间线与验证（https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#release-timeline-and-validation）了解详情。

无状态协议

首要变化是 MCP 现在在协议层是无状态的。六项规范增强提案（SEP）（https://modelcontextprotocol.io/community/sep-guidelines）共同实现了这一目标，完成了我们在 12 月公布的《MCP 传输层的未来》（https://blog.modelcontextprotocol.io/posts/2025-12-19-mcp-transport-future/）中概述的计划。

之前：客户端通过负载均衡器路由到一台 MCP 服务器实例（粘性路由），所有实例共享会话存储。之后：同一客户端路由到三个 MCP 服务器实例中的任意一个，无需会话存储。

前后对比

在 2025-11-25（https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/）版本中，通过流式 HTTP 调用工具需要先建立会话：

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

服务器会返回一个 Mcp-Session-Id，后续每个请求都必须携带它，并将客户端绑定到颁发该 ID 的实例：

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

在 2026-07-28 版本中，同样的调用是一个自包含的请求，任何服务器实例都可处理：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

握手与会话已移除

initialize/initialized 握手已被移除（SEP-2575（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575））。之前连接时一次性交换的协议版本、客户端信息和客户端能力，现在随每次请求放在 _meta 中传输；新增的 server/discover 方法允许客户端在需要时预先获取服务器能力。

Mcp-Session-Id 标头及其附带的协议级会话也被移除（SEP-2567（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567））。两者移除后，任何 MCP 请求均可到达任意服务器实例，水平部署之前需要的粘性路由和共享会话存储不再需要（在协议层）。

无状态协议，有状态应用

移除协议级会话并不意味着你的应用必须是无状态的。需要在多次调用间携带状态的服务器，可以像 HTTP API 一贯的做法那样：从工具中生成一个显式的句柄（如 basket_id、browser_id），让模型在后续调用中将其作为普通参数传回。

序列图：模型调用 create_basket，MCP 服务器返回 basket_id，模型再将同一 basket_id 作为参数传递给 add_item。

实践中我们发现，这种模式（模型在工具调用间传递标识符）不只是会话状态的一种可行替代方案。它往往更强大。模型可以跨工具组合句柄、推理它们，并在步骤间传递它们——这是外部管理的、隐藏在传输元数据中的会话状态从未真正允许的。

协议不再为你管理状态，但也不阻止你自行管理。显式句柄模式只是让状态对模型可见，而非隐藏起来。

服务器到客户端请求，重新组织

无状态协议仍需一种方式让服务器在调用过程中向客户端请求某些东西，比如提示。两个 SEP 重建了这一流程，使其无需持久连接即可工作。

服务器发起的请求现在仅允许在服务器正在处理客户端请求时发出（SEP-2260（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2260））。早期规范版本建议这样做，现在成为强制要求。用户永远不会被无故提示，每个提示都可追溯到用户（或其代理）发起的操作。

多往返请求（SEP-2322（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322））改变了这些提示的传递方式。服务器不再保持 SSE 流打开，而是返回一个 InputRequiredResult：

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "删除 3 个文件？",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

客户端收集答案后，使用 inputResponses 和回显的 requestState 重新发起原始调用。任何服务器实例都可以处理这个重试，因为所需的一切都在负载中。

可路由、可缓存、可追踪

三项较小的变化使产生的流量更易于运维。

流式 HTTP 传输现在要求 Mcp-Method 和 Mcp-Name 标头（SEP-2243（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243）），以便负载均衡器、网关和限流器无需检查请求体即可根据操作进行路由。服务器会拒绝标头与请求体不一致的请求。

列表和资源读取结果现在携带 ttlMs 和 cacheScope（SEP-2549（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2549）），模仿 HTTP 的 Cache-Control。客户端能精确知道 tools/list 响应的有效期，以及是否可以跨用户共享；长期保持的 SSE 流不再是了解列表变化的唯一方式。

_meta 中的 W3C Trace Context 传播现在已被记录（SEP-414（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/414）），固定了 traceparent、tracestate 和 baggage 的键名，使分布式追踪能够跨 SDK 和网关进行关联。多个 SDK 和工具已经在这样做；随着键名在规范中固定，从宿主应用开始的追踪可以跟随工具调用穿过客户端 SDK、MCP 服务器以及服务器调用的下游服务，最终作为一个单一跨度树显示在兼容 OpenTelemetry（https://opentelemetry.io/）的后端中。

扩展成为一等公民

扩展在 2025-11-25 版本中已经存在，但缺乏正式流程。SEP-2133（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133）填补了这一空白：扩展通过反向 DNS ID 标识，通过客户端和服务器能力上的 extensions 映射进行协商，驻留在各自的 ext-* 仓库中（由委托维护者管理），并独立于规范进行版本化。SEP 流程中新增的扩展轨道为它们提供了从实验到正式的路径。

此版本包含两项官方扩展。

MCP 应用：服务器渲染的用户界面

MCP 应用（https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/）（SEP-1865（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865））允许服务器提供交互式 HTML 界面，宿主在沙盒 iframe 中渲染。工具提前声明其 UI 模板，以便宿主可以在运行前预取、缓存和安全审查。渲染后的 UI 通过 MCP 其他地方使用的相同 JSON-RPC 基础协议与宿主通信，因此每个 UI 发起的操作都经过与直接工具调用相同的审计和同意路径。

任务升级为扩展

任务在 2025-11-25（https://modelcontextprotocol.io/specification/2025-11-25/server/tasks）版本中作为实验性核心功能发布。生产使用暴露出足够多的问题，因此其合理归宿是作为扩展而非规范的一部分。

任务扩展（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663）围绕无状态模型重塑了生命周期：服务器可以用任务句柄响应 tools/call，客户端通过 tasks/get、tasks/update 和 tasks/cancel 驱动它。任务创建由服务器主导：客户端通告扩展，服务器决定何时调用应作为任务运行。tasks/list 被移除，因为无会话情况下无法安全限定范围。

任何针对 2025-11-25 实验性任务 API 进行开发的人都需要迁移到新的生命周期。

六项 SEP 强化了授权规范（https://modelcontextprotocol.io/specification/draft/basic/authorization），使其更贴近 OAuth 2.0 和 OpenID Connect 的实际部署方式。

客户端现在必须根据 RFC 9207（https://www.rfc-editor.org/rfc/rfc9207）验证授权响应中的 iss 参数（SEP-2468（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468））。这是一种低成本缓解措施，针对 MCP 单一客户端、多服务器部署模式中更常见的一类混洗攻击。在未来的版本中，客户端将期望拒绝省略 iss 的响应，因此授权服务器应从现在开始提供该参数（如果尚未提供）。

客户端现在在动态客户端注册期间声明其 OpenID Connect application_type（SEP-837（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/837）），避免授权服务器将桌面或 CLI 客户端默认为 "web" 并拒绝其本地主机重定向 URI 的常见情况。客户端将注册凭据绑定到签发授权服务器的 issuer，并在资源在授权服务器之间迁移时重新注册（SEP-2352（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352））。该规范还记录了如何从 OpenID Connect 风格的授权服务器请求刷新令牌（SEP-2207（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2207）），并澄清了分步授权中的作用域累积（SEP-2350（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2350））和 .well-known 发现后缀（SEP-2351（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2351））。

Roots、Sampling 和 Logging 已被弃用

根据新的功能生命周期策略（https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#how-the-protocol-evolves-from-here）（SEP-2577（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577）），三项核心功能被弃用：

这些仅是标注性弃用。相关方法、类型和能力标志在此版本以及一年内发布的所有规范版本中继续有效；移除其中任何一项都需要根据生命周期政策另行提出 SEP。

工具的 inputSchema 和 outputSchema 已升级为完整的 JSON Schema 2020-12（https://json-schema.org/draft/2020-12）（SEP-2106（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2106））。输入模式保留 type: "object" 根约束，但现在允许组合（oneOf、anyOf、allOf）、条件语句和引用（$ref、$defs）。输出模式不受限制，structuredContent 现在可以是任何 JSON 值，而不仅仅是对象。实现不得自动解引用外部 $ref URI，并应限制模式深度和验证时间。

另外，资源缺失的错误码从 MCP 自定义的 -32002 更改为 JSON-RPC 标准 -32602（Invalid Params）（SEP-2164（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2164））。如果你的客户端匹配了字面值 -32002，请更新它。

协议从此如何演进

此版本包含破坏性变更。我们不希望这成为常态。

此版本中的三项治理 SEP 旨在让未来修订能够在不破坏核心能力的情况下演进协议。功能生命周期策略（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596）为每个功能提供活跃、已弃用和已移除三个阶段，从弃用到最早可移除时间至少间隔十二个月。扩展框架（https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#extensions-become-first-class）意味着新能力可以作为可选扩展发布，并在稳定后才（如果需要）移入规范。标准轨道 SEP 必须等到匹配的场景进入一致性测试套件（https://github.com/modelcontextprotocol/conformance）（SEP-2484（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2484））后才能达到最终状态——该套件也是新的 SDK 层级体系（https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1777）对官方 SDK 进行评分的依据。

本次版本中的无状态重构是需要彻底变革的基础性变化。随着它的落地，以及弃用窗口和扩展成为未来的标准工具，我们预期针对 2026-07-28 的实现者将能够采用未来修订，而无需重写其传输或生命周期代码。

发布时间线与验证

发布候选版已于 2026 年 5 月 21 日 锁定。最终规范将于 2026 年 7 月 28 日 发布。这十周窗口供 SDK 维护者和客户端实现者对照真实工作负载验证变更；根据 SDK 层级体系（https://modelcontextprotocol.io/docs/sdk），Tier 1 SDK 预计在此窗口内提供支持。

完整的发布候选版