2026-07-28 MCP 规范发布候选版（阅读时间9分钟）

# 2026-07-28 MCP 规范候选发布版 来源：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 Apps (https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/#mcp-apps-server-rendered-user-interfaces) 实现的服务器渲染 UI，以及通过 Tasks 扩展(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 现在在协议层是无状态的。六个规范增强提案(https://modelcontextprotocol.io/community/sep-guidelines)(SEP) 共同努力实现这一目标，完成了我们在去年 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/) 中，通过 Streamable 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`，后续每个请求都必须携带，将客户端固定到发出它的实例： ``` 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)) 改变了这些提示的传递方式。服务器不再保持 Server-Sent Events (SSE) 流打开，而是返回一个 `InputRequiredResult`： ```json { "resultType": "inputRequired", "inputRequests": { "confirm": { "type": "elicitation", "message": "删除 3 个文件？", "schema": { "type": "boolean" } } }, "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0=" } ``` 客户端收集答案，并使用 `inputResponses` 和回显的 `requestState` 重新发出原始调用。任何服务器实例都可以处理这个重试，因为所需的一切都在负载中。 ### 可路由、可缓存、可追踪 三个较小的更改使结果流量更易于操作。 Streamable 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 Apps：服务器渲染的用户界面 MCP Apps(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 发起的操作都经过与直接工具调用相同的审计和同意路径。 ### Tasks 升级为扩展 Tasks 在 `2025-11-25`(https://modelcontextprotocol.io/specification/2025-11-25/server/tasks) 中作为实验性核心功能发布。生产使用暴露了足够的重新设计需求，因此它更适合作为扩展而非规范的一部分。 Tasks 扩展(https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663) 围绕无状态模型重塑了生命周期：服务器可以用任务句柄响应 `tools/call`，客户端通过 `tasks/get`、`tasks/update` 和 `tasks/cancel` 驱动它。任务创建由服务器指导：客户端通告扩展，服务器决定何时应将调用作为任务运行。`tasks/list` 已被移除，因为它无法在没有会话的情况下安全地划定范围。 任何基于 `2025-11-25` 实验性 Tasks API 开发的用户都需要迁移到新的生命周期。 ## 授权与 OAuth/OpenID Connect 对齐 六个 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"` 并拒绝其 localhost 重定向 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))，三个核心功能被弃用： | 功能 | 替代方案 | |------|----------| | Roots | 工具参数(https://modelcontextprotocol.io/specification/draft/server/tools)、资源 URI 或服务器配置 | | Sampling | 直接与 LLM 提供者 API 集成 | | Logging | stdio 传输的 `stderr`；结构化可观测性的 OpenTelemetry(https://opentelemetry.io/) | 这些只是注解式的弃用。这些方法、类型和能力标志在此版本以及一年内发布的每个规范版本中继续有效，移除其中任何一个都需要在生命周期策略下通过单独的 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 预计在此窗口内提供支持。 完整的候选发布版位于草案规范(https://modelcontextprotocol.io/specification/draft)，变更日志(https://modelcontextprotocol.io/specification/draft/changelog) 将列出针对 `2025-11-25` 的所有更改。 如果你发现问题，请在规范仓库(https://