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 工作负载”。一、核心变化速览关注点旧版方式2026-07-28初始化initializenotifications/initialized删除初始化握手会话Mcp-Session-Id删除协议级 Session协议与能力信息初始化阶段协商每个请求通过_meta携带服务发现依赖初始化结果新增server/discover服务端向客户端请求依赖双向连接改为 MRTRHTTP 路由通常需要解析 JSON Body使用Mcp-Method、Mcp-Name列表缓存没有统一缓存提示增加ttlMs、cacheScopeTasks实验性核心能力移入官方 ExtensionSSE 重连Event ID 与消息重放删除恢复与重放功能废弃缺少统一生命周期至少 12 个月废弃窗口二、删除初始化握手旧版 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-IdServer 不应再依赖 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/discoverServer 必须实现server/discover该 RPC 用于声明Server 支持的协议版本Server CapabilitiesServer Identity。Client 可以在发送其他请求前调用它但不要求一定先调用。因此需要区分Server必须实现server/discoverClient可以选择是否提前调用STDIO Client可以使用它探测对端是否支持新版协议。五、引入 Multi Round-Trip RequestsMulti Round-Trip Requests简称 MRTR用来取代旧的 Server-Initiated Requests例如roots/list sampling/createMessage elicitation/create旧模型需要 Server 保持双向连接并在 Tool 执行过程中主动请求 Client。新模型改为Server 返回一个尚未完成的中间结果Client 收集额外信息后重新发送原请求。Client ── tools/call ────────────── Server Client ─ resultTypeinput_required ─ Server Client ── 询问用户或调用模型 Client ── 原请求 inputResponses ─ Server Client ─ resultTypecomplete ─────── 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}为了兼容旧 ServerClient 收到没有resultType的旧协议结果时必须将其视为complete七、统一使用subscriptions/listen接收变更通知新版本删除旧 HTTP GET 通知端点以及resources/subscribe resources/unsubscribe它们被统一替换为subscriptions/listen这是一个长时间保持的 POST Response Stream。Client 可以选择订阅toolsListChanged promptsListChanged resourcesListChanged resourceSubscriptionsServer 确认订阅后会使用下面的元数据标记通知io.modelcontextprotocol/subscriptionId需要特别区分两类通知全局能力或资源变化进入subscriptions/listen与某个请求直接相关的进度或日志仍然跟随原请求的 Response Stream。第二类包括notifications/progress notifications/message八、删除 SSE 恢复与消息重放Streamable HTTP 不再支持Last-Event-IDSSE Event ID 和消息重放能力也被删除。如果请求的 Response Stream 中途断开当前 In-flight Request 视为丢失Client 需要重新发送请求新请求必须使用新的 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而是迁移到官方 Extensionio.modelcontextprotocol/tasks主要变化包括删除阻塞式tasks/result使用tasks/get轮询任务状态新增tasks/update让 Client 向运行中的 Task 补充输入删除tasks/listServer 可以直接返回 Task Handle不再要求逐请求 Opt-in。新的 Tasks 更适合长时间运行的 Agent异步数据处理文件或报告生成审批工作流运行期间仍需输入的后台任务。十二、Authorization 安全升级1. 校验授权服务器的issAuthorization Server 应按照 RFC 9207在授权响应中返回issClient 在使用 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 必须绑定 IssuerClient 持久化凭证时必须以 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 DocumentsCIMDDCR 暂时仍用于兼容尚未支持 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 范围错误码范围用途-32000-32019实现方自定义现有 SDK 用法保留-32020-32099MCP Specification 保留部分错误码同步调整错误旧值新值HeaderMismatch-32001-32020MissingRequiredClientCapability-32003-32021UnsupportedProtocolVersion-32004-32022十五、Logging 与可观测性变化规范增加了 OpenTelemetry Trace Context 在_meta中的传播约定traceparent tracestate baggage这让一次 Agent 调用可以跨越下面的链路并保持统一 TraceLLM → 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 将普通日志写入stderrRemote Server 使用 OpenTelemetrySTDIO Server 不要向stdout输出非 MCP Message。4. HTTPSSE Transport旧 HTTPSSE Transport 已被正式标记为 Deprecated应迁移至Streamable HTTP5.includeContext以下值被废弃thisServer allServers建议省略该字段或使用none6. Dynamic Client RegistrationDCR 仍然保留兼容性但新的 Client Registration 方案应优先采用 CIMD。十七、协议生命周期制度MCP 新增正式的 Feature LifecycleActive → 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将 HTTPSSE 迁移至 Streamable HTTP为非幂等 Tool 增加业务幂等机制。MCP Client不再发送initialize和notifications/initialized每个请求携带 Protocol Version 和 Client Capabilities支持调用server/discover处理input_required和 MRTR 重试将缺少resultType的旧响应视为completeResponse 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的重点并不是新增几个方法而是重新设计协议的运行方式。其核心方向可以归纳为四点无状态化删除初始化和协议级 Session降低扩容与故障转移复杂度HTTP 原生化支持基于 Header 的路由、鉴权、限流、缓存和观测交互结构化通过 MRTR 支持确认、补参和多轮处理生态模块化通过 Extensions 承载 Tasks、MCP Apps 等可选能力。新项目可以直接以2026-07-28为协议基线。已有项目迁移时应优先检查 Session、初始化握手、Server-Initiated Requests、SSE 恢复和 OAuth 凭证管理因为这些部分受到的影响最大。参考资料MCP 2026-07-28 Key ChangesThe 2026-07-28 MCP SpecificationJSON-RPC 2.0 SpecificationRFC 9207OAuth 2.0 Authorization Server Issuer IdentificationMCP 官方文档
