MCP 2026-07-28 版本变更详解：无状态核心、MRTR、缓存与迁移指南

MCP 2026-07-28 版本变更详解：无状态核心、MRTR、缓存与迁移指南

本文根据 MCP 2026-07-28 官方 Changelog 整理。该页面记录的是2026-07-28相对上一版2025-11-25的变化。本文不是规范原文翻译，而是面向开发者的结构化笔记与迁移说明。

MCP2026-07-28不是普通的功能更新，而是一次协议底层重构。

此前的 MCP 更像一套带初始化握手、连接级 Session 和双向请求的通信协议。新版本则把核心调整为：

• 无状态的请求/响应模型；
• 普通 HTTP 基础设施即可负载均衡；
• 通过 HTTP Header 路由、限流和鉴权；
• 通过 Multi Round-Trip Requests 支持多轮交互；
• Tools、Prompts 和 Resources 列表可以缓存；
• Tasks 等能力通过正式 Extension 扩展；
• OAuth 授权要求更加严格；
• 废弃功能至少保留 12 个月迁移窗口。

一句话概括：

MCP 正在从“需要维护协议级连接状态”转变为“无状态、可缓存、可路由、易于横向扩容的标准 HTTP 工作负载”。

一、核心变化速览

二、删除初始化握手

旧版 MCP Client 建立连接后，通常需要先完成：

initialize ↓ initialize result ↓ notifications/initialized

新版本删除：

initialize notifications/initialized

每一个请求都需要独立表达自己的协议上下文。相关信息改为通过_meta携带，包括：

io.modelcontextprotocol/protocolVersion io.modelcontextprotocol/clientCapabilities io.modelcontextprotocol/clientInfo

其中，协议版本和 Client Capabilities 随每次请求提供；Client 还应该在每次请求中标识自身。Server 应该在每个 Result 的_meta中携带：

io.modelcontextprotocol/serverInfo

如果双方协议版本不兼容，Server 返回：

UnsupportedProtocolVersionError

这意味着 Server 不能再假设“当前请求之前一定执行过初始化”。请求处理器必须能够仅根据当前请求完成版本判断、能力检查和业务执行。

三、删除协议级 Session

新版本从 Streamable HTTP Transport 中删除：

Mcp-Session-Id

Server 不应再依赖 MCP Session 保存跨请求状态，tools/list、resources/list、prompts/list等列表也不再随连接变化。

无状态化带来的直接收益包括：

• 不再需要 Sticky Session；
• 不再强制使用共享 Session Store；
• 任意请求都可以落到任意 Server 实例；
• 普通 Round-robin Load Balancer 即可工作；
• 更容易横向扩容、故障转移和滚动发布。

无状态不等于业务不能保存状态

如果 Tool 需要跨调用保存状态，推荐由 Server 生成显式 Handle，再让 Client 或模型将它作为普通参数传回来：

{"name":"continue_job","arguments":{"jobHandle":"job_8f21a"}}

与隐藏在连接中的 Session 相比，显式 Handle 更容易被模型、日志、权限系统和网关追踪。

四、新增server/discover

Server 必须实现：

server/discover

该 RPC 用于声明：

• Server 支持的协议版本；
• Server Capabilities；
• Server Identity。

Client 可以在发送其他请求前调用它，但不要求一定先调用。因此需要区分：

• Server：必须实现server/discover；
• Client：可以选择是否提前调用；
• STDIO Client：可以使用它探测对端是否支持新版协议。

五、引入 Multi Round-Trip Requests

Multi Round-Trip Requests，简称 MRTR，用来取代旧的 Server-Initiated Requests，例如：

roots/list sampling/createMessage elicitation/create

旧模型需要 Server 保持双向连接，并在 Tool 执行过程中主动请求 Client。

新模型改为：Server 返回一个尚未完成的中间结果，Client 收集额外信息后重新发送原请求。

Client ── tools/call ──────────────> Server Client <─ resultType=input_required ─ Server Client ── 询问用户或调用模型 Client ── 原请求 + inputResponses ─> Server Client <─ resultType=complete ─────── Server

例如，一个删除 Tool 需要用户确认。Server 第一次可以返回：

{"resultType":"input_required","inputRequests":[{"type":"elicitation","message":"该操作会删除数据，是否继续？"}]}

Client 获得用户输入后，重试原请求并附带：

{"inputResponses":[{"accepted":true}]}

MRTR 让确认、补充参数、模型采样等多轮操作不再依赖长期保持的双向流。

六、所有 Result 必须包含resultType

新版本要求所有 Result 都包含resultType。

普通完成结果使用：

{"resultType":"complete"}

需要 Client 补充输入时使用：

{"resultType":"input_required"}

为了兼容旧 Server，Client 收到没有resultType的旧协议结果时，必须将其视为：

complete

七、统一使用subscriptions/listen接收变更通知

新版本删除旧 HTTP GET 通知端点，以及：

resources/subscribe resources/unsubscribe

它们被统一替换为：

subscriptions/listen

这是一个长时间保持的 POST Response Stream。Client 可以选择订阅：

toolsListChanged promptsListChanged resourcesListChanged resourceSubscriptions

Server 确认订阅后，会使用下面的元数据标记通知：

io.modelcontextprotocol/subscriptionId

需要特别区分两类通知：

• 全局能力或资源变化：进入subscriptions/listen；
• 与某个请求直接相关的进度或日志：仍然跟随原请求的 Response Stream。

第二类包括：

notifications/progress notifications/message

八、删除 SSE 恢复与消息重放

Streamable HTTP 不再支持：

Last-Event-ID

SSE Event ID 和消息重放能力也被删除。

如果请求的 Response Stream 中途断开：

1. 当前 In-flight Request 视为丢失；
2. Client 需要重新发送请求；
3. 新请求必须使用新的 JSON-RPC Request ID。

因此，Tool 设计最好考虑幂等性。对于转账、删除、创建资源等非幂等操作，可以增加业务级 Idempotency Key：

{"name":"create_order","arguments":{"idempotencyKey":"order-request-20260810-001"}}

JSON-RPC Request ID 只负责关联请求和响应，不能替代业务幂等键。

九、HTTP Header 路由

Streamable HTTP POST 请求现在需要提供标准 MCP Header，例如：

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

这样，API Gateway、WAF、Rate Limiter 和 Observability 系统不需要解析 JSON Body，也能根据 Method 和 Name 完成：

• 路由；
• 鉴权；
• 限流；
• 审计；
• 指标统计。

新版本还支持在 Tool Parameter Schema 中使用：

x-mcp-header

将指定 Tool 参数映射为自定义 HTTP Header。

十、Tools、Prompts 和 Resources 支持缓存

以下方法返回的 Result 必须包含缓存信息：

tools/list prompts/list resources/list resources/read resources/templates/list

新增字段：

{"ttlMs":60000,"cacheScope":"private"}

字段含义：

• ttlMs：新鲜度提示，单位为毫秒；
• cacheScope: "public"：允许共享中间缓存；
• cacheScope: "private"：不允许跨用户共享缓存。

Server 还应该以确定性顺序返回tools/list。如果内容相同但顺序经常变化，Client Cache 和上游 LLM Prompt Cache 都可能失效。

缓存提示和listChangedNotification 是互补关系：

• ttlMs解决“多久可以复用”；
• listChanged解决“内容已经变化”。

十一、Tasks 移出核心协议

实验性 Tasks 不再属于 MCP Core，而是迁移到官方 Extension：

io.modelcontextprotocol/tasks

主要变化包括：

• 删除阻塞式tasks/result；
• 使用tasks/get轮询任务状态；
• 新增tasks/update，让 Client 向运行中的 Task 补充输入；
• 删除tasks/list；
• Server 可以直接返回 Task Handle，不再要求逐请求 Opt-in。

新的 Tasks 更适合：

• 长时间运行的 Agent；
• 异步数据处理；
• 文件或报告生成；
• 审批工作流；
• 运行期间仍需输入的后台任务。

十二、Authorization 安全升级

1. 校验授权服务器的iss

Authorization Server 应按照 RFC 9207，在授权响应中返回：

iss

Client 在使用 Authorization Code 换取 Token 前，必须验证收到的iss是否与此前记录的 Issuer 一致。

这可以降低 Authorization Server Mix-Up Attack，即 Client 将某个授权服务器签发的 Code 错误发送给另一个授权服务器。

2. DCR 增加application_type

使用 Dynamic Client Registration 时，Client 需要提供适当的：

{"application_type":"native"}

这对 Desktop Application 和 CLI Client 尤其重要，可以减少使用localhostRedirect URI 时出现的校验冲突。

3. Client Credentials 必须绑定 Issuer

Client 持久化凭证时，必须以 Authorization Server Issuer 为边界：

issuer A → credentials A issuer B → credentials B

同一份 Client Credentials 不能用于不同 Authorization Server。Issuer 发生变化时，Client 必须重新注册。

4. DCR 被废弃

OAuth 2.0 Dynamic Client Registration 已被标记为 Deprecated，推荐迁移到：

Client ID Metadata Documents（CIMD）

DCR 暂时仍用于兼容尚未支持 CIMD 的 Authorization Server，但会在未来版本中删除。

十三、Tool Schema 更灵活

inputSchema和outputSchema现在允许使用完整的 JSON Schema 2020-12 Keyword。

同时，structuredContent不再局限于 JSON Object，可以是任意 JSON Value，例如 Array、Number、String、Boolean 或null。

实现方需要注意：

• 不要自动获取不可信的外部$ref；
• 限制 Schema 最大深度；
• 限制组合关键字的复杂度；
• 限制 Schema 解析和验证时间；
• 防止恶意 Schema 导致 CPU、内存或网络资源耗尽。

十四、错误码调整

Resource Not Found 错误码由：

-32002

改为 JSON-RPC 标准错误：

-32602 Invalid Params

如果旧 Client 直接判断字面值-32002，升级时必须修改。

新版还重新划分了 JSON-RPC Server Error 范围：

部分错误码同步调整：

十五、Logging 与可观测性变化

规范增加了 OpenTelemetry Trace Context 在_meta中的传播约定：

traceparent tracestate baggage

这让一次 Agent 调用可以跨越下面的链路，并保持统一 Trace：

LLM → MCP Client → Gateway → MCP Server → Tool → Downstream Service

旧的logging/setLevel被删除。日志级别改为每个请求通过_meta指定：

io.modelcontextprotocol/logLevel

如果请求没有携带该字段，Server 不得为该请求发送：

notifications/message

十六、正式废弃的功能

下面的功能仍处于规范中，但新实现不应继续采用。

1. Roots

推荐替代方案：

• 将目录或文件作为 Tool Parameter；
• 使用 Resource URI；
• 使用 Server Configuration。

2. Sampling

推荐 Server 或应用层直接集成 LLM Provider API，而不是继续依赖 MCP Client 代表 Server 执行 Sampling。

3. Logging

推荐替代方案：

• STDIO Server 将普通日志写入stderr；
• Remote Server 使用 OpenTelemetry；
• STDIO Server 不要向stdout输出非 MCP Message。

4. HTTP+SSE Transport

旧 HTTP+SSE Transport 已被正式标记为 Deprecated，应迁移至：

Streamable HTTP

5.includeContext

以下值被废弃：

thisServer allServers

建议省略该字段或使用：

none

6. Dynamic Client Registration

DCR 仍然保留兼容性，但新的 Client Registration 方案应优先采用 CIMD。

十七、协议生命周期制度

MCP 新增正式的 Feature Lifecycle：

Active → Deprecated → Removed

规范规定：

• 功能从 Deprecated 到 Removed 至少间隔 12 个月；
• 废弃功能进入统一 Registry；
• 新实现不应继续采用 Deprecated Feature；
• 现有实现拥有明确的迁移窗口。

这项变化不会直接改变 Wire Format，但会提升后续 MCP 升级的可预测性。

十八、迁移检查清单

MCP Server

• 删除对Mcp-Session-Id的依赖；
• 不再要求请求前完成initialize；
• 实现server/discover；
• 从请求_meta读取协议版本和 Client Capabilities；
• 在 Result_meta中返回 Server Info；
• 为所有 Result 添加resultType；
• 将 Server-Initiated Requests 迁移为 MRTR；
• 实现subscriptions/listen；
• 为 Cacheable Result 添加ttlMs和cacheScope；
• 保证tools/list顺序稳定；
• 更新 Resource Not Found 错误码；
• 将 Tasks 迁移到官方 Extension；
• 将 HTTP+SSE 迁移至 Streamable HTTP；
• 为非幂等 Tool 增加业务幂等机制。

MCP Client

• 不再发送initialize和notifications/initialized；
• 每个请求携带 Protocol Version 和 Client Capabilities；
• 支持调用server/discover；
• 处理input_required和 MRTR 重试；
• 将缺少resultType的旧响应视为complete；
• Response Stream 断开后使用新 Request ID 重试；
• 支持ttlMs和cacheScope；
• 改用subscriptions/listen；
• 校验 OAuth Response 中的iss；
• 按 Issuer 隔离 Client Credentials；
• 逐步从 DCR 迁移到 CIMD；
• 更新 MCP Reserved Error Code。

Gateway 与运维系统

• 支持Mcp-Method和Mcp-Name；
• 基于 Header 配置路由、限流、鉴权和 WAF；
• 移除 Sticky Session 要求；
• 检查 Cache 是否正确区分public和private；
• 接入 OpenTelemetry Trace Context；
• 确保 STDIO Server 的普通日志只写入stderr。

十九、总结

MCP2026-07-28的重点并不是新增几个方法，而是重新设计协议的运行方式。

其核心方向可以归纳为四点：

1. 无状态化：删除初始化和协议级 Session，降低扩容与故障转移复杂度；
2. HTTP 原生化：支持基于 Header 的路由、鉴权、限流、缓存和观测；
3. 交互结构化：通过 MRTR 支持确认、补参和多轮处理；
4. 生态模块化：通过 Extensions 承载 Tasks、MCP Apps 等可选能力。

新项目可以直接以2026-07-28为协议基线。已有项目迁移时，应优先检查 Session、初始化握手、Server-Initiated Requests、SSE 恢复和 OAuth 凭证管理，因为这些部分受到的影响最大。

参考资料

• MCP 2026-07-28 Key Changes
• The 2026-07-28 MCP Specification
• JSON-RPC 2.0 Specification
• RFC 9207：OAuth 2.0 Authorization Server Issuer Identification
• MCP 官方文档