MCP 2026-07-28 重大更新解读：无状态核心、扩展框架与工程迁移

2026 年 7 月 28 日，Model Context Protocol（MCP，模型上下文协议）正式发布 2026-07-28 稳定规范。它不是一次常规字段增补，而是对协议生命周期、远程部署方式和扩展机制的系统重构。最核心的变化是：MCP 从依赖初始化握手和会话标识的连接式协议，转向每个请求都携带完整上下文的无状态协议。

这次更新同时引入 server/discover、Multi Round-Trip Requests（MRTR，多轮往返请求）、统一订阅流、标准请求头、缓存提示和 OpenTelemetry 追踪约定；MCP Apps 与 Tasks 进入正式扩展体系；Roots、Sampling、Logging 等能力则进入弃用周期。官方将其称为 MCP 发布以来规模最大的一次修订，稳定版已在 MCP 官方 GitHub Release 发布。

速读卡片

一张图理解新版 MCP

新版协议把稳定、通用的通信机制留在无状态核心中，把交互界面和长任务等能力放入可选扩展。客户端和服务器需要显式声明双方都支持的扩展，未协商成功时不能直接使用。

这套结构的关键不是增加了多少新方法，而是把协议职责重新划分：核心负责可互操作的请求、结果、能力声明和安全边界；扩展可以独立版本化和演进，避免每次增加能力都推动整个核心协议升级。

从会话协议转向无状态协议

旧版本为什么难以横向扩展

在 2025-11-25 及更早版本中，客户端首先调用 initialize，服务器返回能力信息，并可能通过 Mcp-Session-Id 建立协议级会话。后续请求必须携带该会话标识。

这种设计在单进程或本地 stdio 场景中问题不大，但远程 MCP 服务器一旦部署多个实例，就需要粘性会话或共享会话存储。网关若要根据工具名进行路由、限流或审计，还可能需要解析 JSON-RPC 请求体。协议状态与基础设施状态由此耦合。

MCP 官方给出的拓扑对比非常直观：旧架构需要把同一客户端固定到特定实例，并在实例之间共享会话状态；新架构允许任意请求落到任意实例。

上图来源于 MCP 2026-07-28 RC 官方说明。稳定版最终变更日志确认，Mcp-Session-Id 和协议级会话已经从 Streamable HTTP 中移除。

新版请求如何工作

2026-07-28 删除了 initialize / notifications/initialized 握手。协议版本、客户端身份和客户端能力改为随每次请求传递，服务器身份也随结果返回。HTTP 请求还必须携带 MCP-Protocol-Version，让服务器在处理请求前确认双方是否使用同一版本。

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": { "query": "MCP 2026-07-28" },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-client",
        "version": "1.0.0"
      }
    }
  }
}

服务器必须实现 server/discover，用于公开支持的协议版本、能力和服务器身份。客户端可以在第一次业务调用前主动发现，也可以直接发送首个请求，在收到 UnsupportedProtocolVersionError 后根据服务器返回的版本列表重试。

无状态并不等于业务不能保存状态。购物车、浏览器会话、批处理作业等跨调用状态，应由服务器生成显式句柄，例如 browserId 或 taskId，再由模型或客户端在后续工具参数中传回。状态从隐藏的传输层会话转为显式业务对象，部署更容易扩展，也更便于审计。

MRTR 重构服务器向客户端索取输入的方式

旧版 MCP 允许服务器在处理工具调用期间向客户端发起 Sampling、Roots 或 Elicitation 请求。无状态协议不再依赖持续连接，因此 2026-07-28 引入 MRTR。

当工具执行需要用户确认、模型补充推理或其他输入时，服务器先返回 resultType: "input_required"，并附带 inputRequests 与不透明的 requestState。客户端收集输入后，重新发起原始请求，同时提交 inputResponses 和原样返回的 requestState。

这种设计带来三个工程结果：

1. 用户输入一定能追溯到某次主动发起的请求，服务器不能脱离请求上下文突然弹出交互。

2. 重试请求包含继续执行所需的信息，任意服务器实例都可以接手。

3. 所有结果都具有明确的 resultType。普通结果为 complete，需要输入时为 input_required；旧版本结果缺失该字段时，客户端按 complete 处理。

代价也很明确：响应流中断后，不再使用 Last-Event-ID 恢复并重放消息。客户端必须以新的请求 ID 重新发起请求，因此具有副作用的工具仍需自己设计幂等键或去重机制。

订阅、路由、缓存和追踪进入基础设施层

无状态化不是简单删除会话，新版还补齐了远程服务需要的基础设施语义。

统一订阅流

原有 HTTP GET 事件流以及 resources/subscribe、resources/unsubscribe 被 subscriptions/listen 替代。客户端通过一个长生命周期的 POST 响应流订阅工具列表、提示词列表、资源列表或资源订阅变化。与某个请求直接相关的进度和日志通知，仍然沿该请求自己的响应流返回。

标准请求头

Streamable HTTP POST 现在要求 Mcp-Method，涉及具体名称时还包括 Mcp-Name。网关可以在不解析 JSON 请求体的情况下完成路由、限流、指标聚合和访问控制。服务器必须校验请求头与正文是否一致，避免网关看到的操作与服务器实际执行的操作不同。

明确的缓存提示

tools/list、prompts/list、resources/list、resources/read 等结果加入 ttlMs 和 cacheScope：

• ttlMs 表示结果保持新鲜的建议时长

• cacheScope: "public" 允许共享中间层缓存

• cacheScope: "private" 表示结果只能在用户或客户端边界内缓存

工具列表还应保持确定性排序。这不仅减少重复拉取，也有利于提高 LLM 提示缓存命中率。

OpenTelemetry 追踪

规范统一了 _meta 中 traceparent、tracestate 和 baggage 的传递约定。一个请求可以从 AI 主机经过 MCP 客户端、MCP 服务器和下游服务，最终在 OpenTelemetry 后端中形成连续的调用链。对于远程 MCP，调试重点因此从追踪会话转向追踪单个自包含请求。

扩展成为正式演进机制

2026-07-28 在客户端和服务器能力中增加 extensions 映射。扩展使用带命名空间的标识符，独立版本化，并由双方显式协商。核心协议保持稳定，交互界面、长任务和企业授权等能力可以按各自节奏演进。

MCP Apps：在对话中运行交互界面

MCP Apps 官方文档 定义了服务器如何随工具提供 HTML 界面。工具描述通过 _meta.ui.resourceUri 指向 ui:// 资源，宿主预取资源后，将其渲染在受限的 iframe 中。

它适合图表、表单、仪表盘、文件预览和多步骤审批等纯文本难以表达的交互。界面不能直接访问宿主 DOM、Cookie 或本地存储，应用与宿主通过 postMessage 和 JSON-RPC 通信；界面触发的工具调用仍经过宿主的权限与用户确认流程。

Tasks：长任务使用持久句柄

Tasks 官方文档 把长时间操作从核心协议移入扩展。服务器可以返回包含 taskId、状态、存活时间和建议轮询间隔的任务句柄，客户端通过以下方法驱动任务：

任务状态包括 working、input_required、completed、failed 和 cancelled。任务 ID 可以持久化，因此客户端重启或网络断开后仍能恢复查询。CI 流水线、批处理、模型训练、云资源创建和人工审批是典型场景。

授权体系针对真实 OAuth 与 OIDC 部署加固

MCP 常见形态是一个客户端连接多个服务器和多个授权服务器，这比普通单服务 OAuth 更容易出现授权服务器混淆、凭证绑定错误和重定向 URI 不兼容。最终规范主要补强了以下边界：

• 客户端必须校验授权响应中出现的 iss 是否与已记录的 issuer 一致

• 动态客户端注册需要声明合适的 OpenID Connect application_type

• 客户端凭证必须绑定到签发它的授权服务器，issuer 变化后必须重新注册

• 规范明确了刷新令牌请求、逐级提升权限时的 scope 累积，以及 .well-known 发现地址规则

• OAuth 2.0 Dynamic Client Registration 进入弃用周期，推荐迁移到 Client ID Metadata Documents

这些变化不会替代用户授权界面。官方安全原则仍然要求：宿主在访问数据和执行工具前取得明确同意，工具描述按不可信输入处理，用户能够理解并控制实际执行的操作。

工具 Schema 更完整，但实现必须限制复杂度

工具的 inputSchema 和 outputSchema 现在支持完整的 JSON Schema 2020-12 关键字。输入仍要求根节点为对象，但可以使用 oneOf、anyOf、allOf、条件判断、$ref 和 $defs；输出 Schema 不再限制为对象，structuredContent 也可以是任意 JSON 值。

这让复杂工具接口可以表达联合类型、条件字段和可复用定义，但同时扩大了验证器的攻击面。规范要求不要自动解引用外部 $ref，实现还应限制 Schema 深度、组合分支数量和验证时间，防止恶意或异常 Schema 消耗过多资源。

哪些能力进入弃用周期

弃用不等于立即删除。官方新的功能生命周期规定，能力从 Deprecated 到最早可移除至少间隔 12 个月。根据 官方弃用注册表，以下能力需要规划迁移：

现有实现仍可在弃用窗口内继续工作，但新项目不应继续围绕这些能力设计核心架构。

客户端与服务器如何迁移

先确认协议时代

官方把实现分为三类：

• Modern：使用 2026-07-28 及以后版本，每个请求携带版本、身份和能力

• Legacy：使用 2025-11-25 及以前版本，通过 initialize 建立会话

• Dual-era：同时支持现代与旧版协议

版本号相同不代表 SDK 主版本相同。应以客户端与服务器实际协商的 MCP 协议版本为准。旧客户端无法自动向前兼容只支持现代协议的服务器，因此生产环境更适合先部署双时代服务器，再逐步升级客户端。

客户端检查清单

1. 升级到明确支持 2026-07-28 的官方 SDK 版本。

2. 启用自动版本探测或显式固定协议版本，并验证旧服务器回退路径。

3. 处理 server/discover、UnsupportedProtocolVersionError 和新版错误码。

4. 对所有结果读取 resultType，实现 MRTR 的输入收集与原请求重试。

5. 支持 ttlMs、cacheScope 和 subscriptions/listen，避免继续高频轮询列表接口。

6. 对具有副作用的调用加入幂等键，不能依赖 SSE 重放避免重复执行。

7. 按 issuer 保存 OAuth 客户端信息和令牌，不跨授权服务器复用凭证。

以 TypeScript SDK v2 为例，官方迁移文档要求显式选择新协议探测模式；仅升级依赖并不一定会自动发送 2026-07-28 请求：

const client = new Client(
  { name: "my-client", version: "1.0.0" },
  { versionNegotiation: { mode: "auto" } },
);

await client.connect(transport);
console.log(client.getProtocolEra()); // modern 或 legacy

具体 API 仍应以所用 SDK 的稳定版本文档为准，可参考 TypeScript SDK 2026-07-28 迁移说明。

服务器检查清单

1. 删除对协议级 Session ID 和粘性会话的强依赖。

2. 实现 server/discover，并在每次请求上验证版本与客户端能力。

3. 将跨调用状态改为显式句柄，并确定句柄的权限、过期、撤销和清理策略。

4. 使用 Mcp-Method、Mcp-Name、缓存提示和 Trace Context 配置网关与可观测性。

5. 需要中途输入的同步工具采用 MRTR；需要跨断线恢复的长操作采用 Tasks。

6. 需要交互式可视化时再采用 MCP Apps，不把简单文本结果包装成网页。

7. 在正式切换前运行一致性测试，并保留旧版客户端兼容窗口。

对现有 Blog MCP 的实际影响

现有 Blog MCP 不会因为稳定规范发布而立即失效。只要客户端与服务器仍能协商一个共同支持的旧版本，文章、评论和友链工具可以继续工作。真正迁移到新协议后，收益主要体现在远程部署与运维：

• Cloudflare Workers 一类无状态运行环境不再需要依赖协议会话

• 工具列表和资源结果可以按明确 TTL 缓存

• 网关可以根据标准头直接路由和限流

• OAuth 凭证绑定和刷新流程更明确

• 长时间的导入、批量处理和人工审核可以用 Tasks 恢复

• 复杂后台操作可以通过 MCP Apps 在对话中提供表单或预览界面

是否已经使用新版不能只看 MCP 能否连接，应通过客户端日志、server/discover 返回值或 SDK 暴露的协议版本确认。

小结

2026-07-28 更新的价值不在于新增几个工具接口，而在于 MCP 终于形成了一套更适合远程生产环境的协议基础：请求无状态、状态显式化、扩展可独立演进、缓存和追踪可被基础设施理解，授权与弃用也有清晰规则。

对于已有实现，最稳妥的路线不是一次性重写，而是先升级 SDK 和一致性测试，部署双时代兼容，随后迁移会话状态、MRTR、订阅、缓存和授权，最后再按场景接入 Tasks 或 MCP Apps。