一句话总结
MCP 2026-07-28 版最大的变化，是把协议核心从“依赖会话和长连接的有状态协议”，推进成“每个请求自描述、可路由、可缓存、可横向扩展的无状态请求/响应协议”。
阅读指引
如果你只想快速抓重点，可以按这个顺序读：
- 先看“最大变化”表，理解它和
2025-11-25的差别。 - 再看“主要更新”的前四节：无状态核心、
server/discover、MRTR、Header 路由。 - 最后看“对开发者意味着什么”，判断你自己的 MCP Client / Server 需要改哪里。
版本背景
MCP，全称 Model Context Protocol，是面向 AI 应用、Agent、工具、资源、提示词和外部系统集成的一套开放协议。它解决的问题可以简单理解为：让大模型应用用统一方式发现工具、调用工具、读取资源、处理用户交互和授权。
这次官方发布的是 2026-07-28 规范，上一篇可对比的正式规范是 2025-11-25。2025-11-25 更像是“能力扩展版”：增强授权发现、工具和资源图标、Elicitation、Sampling 工具调用、Client ID Metadata Documents、实验性 Tasks，以及 SDK 分级治理。2026-07-28 则明显变成“生产基础设施版”：重点不再只是给协议加功能，而是重塑 MCP 在大规模部署下的运行方式。
官方博客也提到，这次同步更新了 Tier 1 SDK，包括 TypeScript、Python、Go、C#；Rust SDK 已支持新规范的 beta。对于已经依赖 Mcp-Session-Id 或初始化会话的实现，这次会有迁移成本。
最大变化
| 维度 | 2025-11-25 之前的思路 | 2026-07-28 新思路 | 影响 |
|---|---|---|---|
| 协议核心 | 依赖 initialize/initialized 握手和协议级 session |
移除握手和 Mcp-Session-Id，每个请求自己携带版本、能力和客户端信息 |
MCP Server 更容易做无状态扩容，请求可以落到任意实例 |
| 服务端反向请求 | 依赖长期保持的双向流来做 Sampling、Roots、Elicitation 等 | 引入 Multi Round-Trip Requests，服务端返回 input_required，客户端带答案重试原请求 |
不需要为了中途补信息一直挂住双向连接 |
| 网关和负载均衡 | 网关通常要理解请求体，或者依赖连接级状态 | Streamable HTTP 请求要求带 Mcp-Method、Mcp-Name Header |
API Gateway、WAF、Rate Limiter 可以直接基于 Header 路由和限流 |
| 列表和资源读取 | tools/list、resources/list 等结果更偏即时获取 |
列表和资源读取结果加入 ttlMs、cacheScope，并要求稳定顺序 |
客户端能缓存工具目录，减少重复拉取，也更利于 LLM prompt cache |
| 长任务 | tasks 是实验性核心能力 |
tasks 移到 io.modelcontextprotocol/tasks 官方扩展，并改为 tasks/get 轮询和 tasks/update 输入 |
核心协议更瘦，长任务进入正式扩展体系 |
| 授权 | 已经开始支持 CIMD 等机制 | 进一步强化 OAuth：iss 校验、凭证按 issuer 绑定、DCR 正式弃用 |
降低授权服务器混淆、凭证复用等安全风险 |
| 生命周期治理 | 有功能演进，但弃用节奏不够制度化 | 引入正式弃用策略，最少 12 个月窗口 | 企业和 SDK 维护者可以按节奏升级，而不是被动追改 |
一句话概括：2025-11-25 是 MCP 在“补能力”，2026-07-28 是 MCP 在“去连接状态、上生产规模”。
主要更新
1. 无状态协议核心：不再依赖隐藏 session
新规范移除了协议级 session 和 Mcp-Session-Id Header，也移除了 initialize / notifications/initialized 握手。每个请求现在要在 _meta 里携带协议版本和客户端能力，例如：
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "MCP 2026-07-28"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "my-agent",
"version": "1.0.0"
}
}
}
}
这不是说业务不能有状态，而是协议不再替你藏状态。如果某个工具调用确实需要跨请求上下文，服务端应该显式生成一个 handle，让模型把这个 handle 当作普通参数继续传递。这个变化很关键：状态从“传输层隐含”变成“模型和应用可见”。
2. server/discover：把能力发现从握手里拆出来
既然初始化握手被移除，服务端能力发现就需要一个新入口。2026-07-28 增加了 server/discover RPC，服务端必须实现它，用来声明自己支持的协议版本、能力和身份信息。
客户端可以先调它来选择版本，也可以直接发起请求。这个设计让发现变成可选前置步骤，而不是每条连接都必须经历的会话初始化流程。
3. MRTR：无状态协议下继续支持“中途问用户”
旧模型里，如果服务端在工具执行过程中需要向客户端要信息，比如确认操作、补参数、让模型采样，就倾向于依赖服务端发起请求和长期保持的双向流。新规范引入 Multi Round-Trip Requests，简称 MRTR。
MRTR 的核心模式是：
- 客户端发起原始请求。
- 服务端发现缺少信息，返回
resultType: "input_required"。 - 返回体里的
inputRequests描述需要客户端补什么。 - 客户端收集答案后，用
inputResponses重试原请求。
这样一来，Elicitation、Sampling、Roots 这类原本容易绑在双向连接上的交互，都可以被改造成请求/响应模式。它牺牲了一点流程上的“直接”，换来的是更适合 HTTP 基础设施的可靠性。
4. Header 路由：MCP 请求终于更像普通 Web 流量
新规范要求 Streamable HTTP POST 请求带上 Mcp-Method 和 Mcp-Name Header。比如工具调用可以在 Header 里暴露 tools/call 和具体工具名。
这对企业部署非常现实：网关、限流器、WAF、审计系统可以直接看 Header 做路由、鉴权、限流和观测，而不用解析 JSON-RPC Body。对于部署在 API Gateway、Cloudflare Workers、AWS、Kubernetes Ingress 这类基础设施上的 MCP Server，这个变化很实用。
5. 列表结果可缓存：减少工具目录反复拉取
tools/list、prompts/list、resources/list、resources/read、resources/templates/list 的结果现在需要带 ttlMs 和 cacheScope。
ttlMs 表示新鲜度提示，客户端可以据此减少重复请求；cacheScope 表示缓存范围，区分 public 和 private。与此同时，服务端还应该稳定返回 tools/list 的顺序。这一点不只是省网络请求，也会影响 LLM prompt cache：工具列表顺序稳定，提示词缓存命中率才更可控。
6. 授权安全继续加固
授权是 MCP 落地里最复杂的部分之一。2026-07-28 做了几件安全加固：
- 授权服务器应该返回符合 RFC 9207 的
iss参数，客户端在兑换 code 前必须校验已记录的 issuer。 - 客户端凭证必须绑定到签发它的 authorization server，不能跨授权服务器复用。
- Dynamic Client Registration，也就是 DCR，被正式标记为弃用；推荐方向是 Client ID Metadata Documents，也就是 CIMD。
- 客户端在 DCR 时需要设置合适的
application_type，减少桌面和 CLI 应用在 localhost redirect 上遇到的 OpenID Connect 冲突。
这里的主线不是“换一个 OAuth 写法”这么简单，而是让 MCP 的授权模型更接近生产环境里的多授权服务器、多客户端、多租户现实。
7. Extensions 框架：核心协议瘦身，创新放到扩展
新规范给 ClientCapabilities 和 ServerCapabilities 增加了 extensions 字段，用来支持核心协议之外的可选扩展。tasks 就是一个代表：它从实验性核心能力移到了 io.modelcontextprotocol/tasks 官方扩展。
新版 Tasks 改成通过 tasks/get 轮询获取进度和结果，并增加 tasks/update 让客户端向服务端补输入。这个方向很像很多成熟协议的演进路径：核心保持稳定，变化更快的能力进入扩展体系。
被弃用的内容
这次有几项比较重要的弃用：
- Roots、Sampling、Logging 被标记为 Deprecated。它们仍然能用，并且会有至少 12 个月弃用窗口，但新实现不建议继续采用。
- HTTP+SSE Transport 被正式归入 Deprecated，迁移方向是 Streamable HTTP。
- Sampling 里的
includeContext: "thisServer"和"allServers"被标记为 Deprecated。 - OAuth 2.0 Dynamic Client Registration 被标记为 Deprecated，推荐转向 CIMD。
我的理解是，这些弃用不是简单砍功能，而是配合“无状态、可路由、可扩展”的新协议心智模型做收敛。Roots、Sampling、Logging 这类功能如果继续停留在核心协议里，会让核心越来越重；HTTP+SSE 和 DCR 则会拖住大规模部署和企业授权模型。
对开发者意味着什么
如果你只是 MCP Client 的使用者，最直接的变化是：升级 SDK 后，客户端请求需要适配新的 _meta、resultType、MRTR 等协议结构。旧服务端返回结果时没有 resultType，新客户端必须把它当作 "complete" 处理，这是官方给出的兼容要求。
如果你在写 MCP Server，重点检查这些地方：
- 是否依赖
Mcp-Session-Id或初始化握手保存状态。 - 是否把用户确认、Sampling、Roots 等逻辑建立在服务端主动请求客户端的长连接上。
tools/list、resources/list等列表结果是否能返回稳定顺序、ttlMs和cacheScope。- Streamable HTTP POST 是否带上
Mcp-Method和Mcp-Name。 - 授权流程是否校验
iss，凭证是否按 issuer 隔离保存。 - 是否还在新实现里引入 Roots、Sampling、Logging、HTTP+SSE 或 DCR。
更具体一点，我会按这个顺序迁移：
| 优先级 | 要做什么 | 验证方式 |
|---|---|---|
| P0 | 先确认 Client / Server 是否真的要协商到 2026-07-28，还是继续兼容旧版本 |
用 server/discover 或 SDK 的版本协商日志确认最终协议版本 |
| P0 | 去掉对 Mcp-Session-Id、initialize、连接粘性的强依赖 |
用多实例、非 sticky 的负载均衡压测工具调用 |
| P1 | 把服务端向客户端要输入的流程改成 MRTR | 人工触发确认、补参数、采样等场景，确认 input_required 可以被客户端继续推进 |
| P1 | 给列表和资源读取补 ttlMs、cacheScope，并稳定排序 |
连续请求 tools/list，检查顺序、缓存策略和 prompt cache 命中 |
| P2 | 清理 DCR、HTTP+SSE、Roots、Sampling、Logging 的新依赖 | 把新实现默认走 Streamable HTTP、CIMD、OpenTelemetry 或业务参数 |
如果你做的是企业级 Agent 平台，这个版本的意义更大。它让 MCP Server 可以像普通 HTTP 服务一样被负载均衡、横向扩容、接入网关、做审计和限流，而不是总要围绕“某条连接上的某个 session”设计基础设施。
这版到底是干嘛的
我会把 MCP 2026-07-28 理解成一次“协议基础设施化”的发布。
之前的 MCP 已经证明了工具调用、资源访问、提示词管理、授权和交互这些能力有价值；但要跑进企业生产环境，真正麻烦的是扩容、路由、缓存、授权边界、长任务、弃用策略和 SDK 一致性。
所以这版的核心目标不是让 Agent 多一个炫酷能力，而是让 MCP 更适合被当作生产级 Agent 基础设施来部署：
- 无状态，让服务端更容易扩容。
- Header 路由，让网关和安全设备更容易接入。
- MRTR，让交互流程摆脱长期双向连接依赖。
- CacheableResult，让客户端和基础设施可以缓存稳定列表。
- Extensions，让核心协议保持稳定，创新能力进入扩展层。
- 授权加固和弃用策略，让企业集成更可控。
如果一句话给升级优先级：新项目可以直接按 2026-07-28 设计；老项目如果依赖 session、HTTP+SSE、DCR、Roots、Sampling、Logging，要尽早规划迁移；如果只是通过官方 SDK 做普通工具调用，可以优先升级 SDK，再按迁移指南补协议字段和测试。