MCP 史上最大更新转「无状态」：你的旧 API，正好赶上新货架

7 月 28 日，Anthropic 发布了 Model Context Protocol（MCP）2026-07-28 规范。这是自 2024 年 11 月 MCP 开源以来改动最大的一次，官方自己也说这是「自远程 MCP 发布以来最重要的一次」。

过去的 MCP 是双向有状态协议。客户端连上服务端先来一轮握手（initialize / initialized），服务端回一个 Mcp-Session-Id，之后每次请求都必须带着这个会话 ID，打到「认识它」的那台机器上。这在单机调试时没问题，但在生产环境里意味着粘性会话、共享会话存储、深度包检测，每一层都是运维不想碰的活。更致命的是它和 Serverless、边缘计算八字不合。

2026-07-28 这一版，官方直接把握手和 Mcp-Session-Id 一刀切了（对应 SEP-2575、SEP-2567）。每个请求自己携带上下文——协议版本、客户端身份、能力列表，全装在请求的 _meta 字段里。效果很直接：任意一个请求，落到负载均衡后面任意一台实例都能处理，不需要共享存储，不需要粘性路由。

顺带几个配套改动：Header-based routing（请求头带 Mcp-Method / Mcp-Name，网关可基于请求头路由鉴权）；MRTR（替代长连接才能做的 elicitation / sampling / roots）；可缓存的 tools/list（带 ttlMs / cacheScope）；认证加固并留 12 个月弃用窗口。

一句话总结：MCP 不再要求你为「连接」专门搭一套基础设施，它终于长得像普通 HTTP 服务了。

落到最实际的动作。你公司里那堆跑了多年的内部接口、对外的开放 API，怎么低成本变成 AI 能直接调用的 MCP Server？答案是——不要重写，包一层。

第一步：把接口梳理成三类能力。 MCP 暴露给 Agent 的能力本质是三种原语：tools（可被调用的动作）、resources（可被读取的数据）、prompts（可被复用的提示词模板）。拿出现有 REST API 文档逐项归类即可，纯梳理不碰代码。

第二步：写一层轻量适配层。 适配层把 MCP 的 tools/call 请求翻译成对你原 REST 接口的 HTTP 调用，再把结果包回 MCP 格式。有了 Mcp-Method / Mcp-Name 请求头，甚至不用解析整个请求体就知道调哪个工具。原 API 的鉴权、限流，适配层原样透传。

第三步：注册出去，对外暴露。 把适配层部署到一个普通 HTTP 服务后面，把端点注册到支持 MCP 的客户端或托管平台，Agent 就能看到。最关键的一点：原 API 的业务逻辑一行都不用改，你只是加了个「转接头」。

很多团队卡在第二步之后不敢动，理由是「原来的鉴权、计费、日志体系怎么办，是不是要跟着重写」。答案是——不用，沿用就行。

鉴权：现有 API Key / Token 体系完全复用，适配层转发前做一次统一校验；新版 header-based routing 让网关可基于 Mcp-Method / Mcp-Name 直接路由鉴权，OAuth 2.1 / OIDC 原生支持，能直接对接 Entra、Okta。

计费：原 API 若本就按调用次数、流量或资源消耗计费，底座一分钱不用动。MCP 只是多了个「调用入口」，每次 MCP 侧 tools/call 最终都落到你原来的计量点上，AI Agent 调一次和你自己 App 调一次走同一本账。

日志：在适配层补一段日志，把「这次调用来自 MCP、对应哪个工具、调了哪个原接口」记下来回写现有日志系统。再叠加 tools/list 缓存，还能减少大量重复目录拉取。

把前面合起来看，这次 MCP 更新真正的红利不是「又出了新协议让你学」，而是把你手里已有的东西，重新标价上架。

以前你的 REST API 主要卖给两类人：前端工程师、合作方技术对接。现在多了一类消费者——AI Agent 和自动化工作流。一个能查订单的接口，过去只有程序员会调；现在一个客服 Agent、一个排程 Agent，都能直接拿来用。把它们包成 MCP Server 之后，同一个能力能同时被多个 Agent 编排进不同流程，等于把一份资产卖了第二次。

协议不会替你写接口，但它会替你打开一扇原来关着的门。门后面有没有货，看你手里本来有什么。