MCP 新规范之后，接入验收该看什么

MCP 的变化正在从“怎样让模型看见一个工具”，转向“怎样让工具接入成为可以长期维护的服务”。对开发者来说，最有价值的动作不是把配置里的协议日期改成最新，而是核对客户端、服务端和中间网络究竟支持哪一套行为。

本文分析 MCP 2026-07-28 规范及随后公布的路线图，资料核对截至 2026 年 9 月 5 日。它不是 EveryInfra 的升级公告，也不代表文中提到的变化已经在 EveryInfra 或你使用的客户端上线。

先分清：规范已经发布，还是路线图准备去做

MCP 维护者在 7 月 28 日的发布公告中正式发布了 2026-07-28 版本，无状态协议核心是主要变化之一。这和“某个服务已经完成迁移”是两件事：规范告诉实现者应该遵守什么，服务自己的版本说明和实际响应才告诉用户现在能用什么。

8 月 22 日的新路线图又提出了 Agent 身份、结果表达和渐进式工具发现等后续方向。把这些方向全部放进“最新 MCP 已支持”的清单，会让接入者误判。路线图有助于理解项目往哪里走，但不能替某个客户端补上它尚未实现的功能。

围绕这份路线图的 Hacker News 讨论中，也出现了“服务会实现多少新要求”和工具逐步加载的疑问。这是有价值的选题线索，不是生态采用率调查。我们更关心由此引出的实际问题：同样写着支持 MCP 的两个端点，是否真的在说同一种协议语言？

无状态，移走的是协议会话，不是业务责任

根据正式变更清单，新版本移除了旧的初始化握手和协议级会话标识。需要跨调用保存状态的应用，可以使用显式的业务句柄。也就是说，协议不再依靠连接上的隐藏会话来记住所有上下文，应用仍然可以有自己的任务、资源和状态。

这对接入设计的启发是：不要再用“连接还在”代替“任务归属明确”。一次耗时操作至少应能回答：谁发起了它、哪个用户有权查询、现在处于什么状态，以及网络断开后如何核对结果。

举一个假设场景：Agent 发起了一项报告生成任务，随后客户端断网。重新连接后，用户需要知道的是原报告有没有生成，而不只是能否再次连上服务。应用如果没有任务标识和结果查询办法，即使协议连接变简单了，用户仍然可能重复提交同一项工作。

因此，我们建议把“协议请求编号”“业务任务标识”和“防止重复执行的机制”分开设计。它们可以有关联，但不能因为其中一个存在，就推定另外两个问题已经解决。这是应用层的设计判断，不是 MCP 对所有业务提供了自动幂等保证。

HTTP 更容易管理，不代表只看请求头就够了

新版本的 Streamable HTTP 规范规定了 Mcp-Method 等请求元数据头，并在适用的方法上使用 Mcp-Name。头部和正文对应字段需要一致。规范仍允许请求范围内的 SSE 响应，不能把这次变化简化成“MCP 不再使用流式响应”。

这些设计让中间层更容易区分请求，但使用方仍需要做两种检查。第一种是协议检查：缺头、版本不支持、头与正文不一致时，能否得到明确错误。第二种是业务检查：被识别为某个工具调用之后，当前用户是否有权执行这个工具、访问这个对象。

假设一个只允许查询的账号，把请求头写成查询，却在正文请求修改。如果中间层与应用层各信一半，整个系统就可能产生不一致。实际测试应该构造这种不一致的无害请求，确认它会被拒绝；不能只测试一个正确的请求头是否通过。

同样，HTTP 200 只说明请求获得了某种正常响应，不一定意味着目标业务完成。工具可能返回业务错误、等待输入或阶段性结果。如何把这些状态交还给用户，比把所有响应统一显示为“成功”更重要。需要进一步设计错误分类时，可以参考站内的 API 错误处理与自愈方法。

目录能缓存，权限却不能靠缓存猜

新规范给目录等响应引入了 ttlMs 和 cacheScope，分别表达新鲜度提示和共享缓存范围。具体适用对象见变更清单的缓存说明。这有助于减少不必要的重复发现，但它不是“工具清单以后永远不会变化”的承诺。

接入者可以把目录视为一张带时间和适用身份的地图。地图帮助模型选择工具，最终执行仍要重新接受权限和参数检查。某个用户曾经看见一个工具，不应成为他以后一直能使用它的依据。

这里有一个值得单独验证的场景：用户权限被收回后，客户端还保存着旧目录。理想的用户体验不是工具悄悄消失或调用无声失败，而是执行端明确拒绝，客户端能够解释原因，并在合适时机更新目录。不要通过延长缓存时间掩盖权限变化。

如果你正在建立自己的能力目录，可以继续阅读实时能力目录为什么需要可核对。这篇站内文章讨论目录与实际行为的关系，不代表它已经实现本次新规范的全部缓存机制。

身份问题不能被“接上了”掩盖

授权服务器身份校验是本轮规范变化的一部分。RFC 9207定义的 iss 参数，帮助客户端确认授权响应来自预期的签发者，防范授权服务器混淆。这个标准解决的是明确的一类身份问题，不是所有 Agent 安全问题的总开关。

从产品角度看，身份至少包含三个不同的问题：现在是哪位用户、用户允许这次任务做什么、任务执行时服务真正开放了哪些权限。用户完成一次登录，不等于同意之后的所有外发、删除或资源购买。

我们建议让高影响动作在执行前重新显示关键对象与后果。例如，“修改配置”应该说明改哪个环境、哪些字段；“发送”应该说明收件对象与内容。模型可以帮助准备操作，但授权不能只藏在一段模糊的工具描述里。

这也解释了为什么“服务有 OAuth”“客户端支持 MCP”“工具能够列出来”都不能单独成为生产接入的验收结果。协议发现、身份授权和业务完成，应各有一条可核对的证据。

升级前，先做一张小而明确的验收矩阵

按照官方版本与兼容说明核对实现时，建议把每个真实使用组合单独列出来，而不是只登记一行“MCP：支持”。每行包含客户端及版本、服务端支持的协议版本、使用的传输和认证方式、已经验证的操作，以及尚未验证的能力。

第一轮不必测遍所有工具，但要覆盖会改变交付判断的场景：

• 一个只读任务能够返回可理解的结果，且结果属于当前用户和目标。
• 不支持的版本、错误参数和失效凭据会被明确拒绝，不落入看似成功的空结果。
• 用户拒绝高影响操作后，服务没有执行该动作。
• 请求中断后，能够判断原任务状态；结果未知时，不自动重复执行有副作用的操作。
• 权限变化后，旧目录或旧连接不能继续提供已经撤销的权限。

这些是我们建议的接入验收项，不是本文已经替任何产品完成的测试报告。EveryInfra 的现有接入说明见远程 MCP 接入验收；阅读时应保留其具体版本和实测边界，不把它当成 2026-07-28 的兼容性证明。

判断是否升级，最终应回到一个具体问题：新版本是否解决了当前部署或使用中的明确问题，而且关键客户端组合能够稳定工作？如果答案还不清楚，先完成兼容性验证；如果答案已经明确，再安排迁移与回退。协议日期更新是起点，用户能持续完成任务才是结果。