MCP 是什么：2026 无状态改版，Server 要改三处

MCP 让模型能调用外部工具和数据，但 2026-07-28 版规范把它从「有状态连接」改成了「无状态核心」。这不是小修：初始化握手取消、会话 ID 移除，按老规范写的 Server 直接升级会连不上。下面把协议本身、两种传输和迁移清单一次讲清。

一句话：MCP 规范的是「接口形状」

各家模型的 function calling 各写一套 JSON，工具提供方就得为每个客户端做适配。N 个模型乘 M 个工具，是 N×M 份工作量。

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 在 2024 年 11 月底提出并开源，作用是把这一层标准化：服务端用统一格式声明自己有什么能力，客户端用同一套 JSON-RPC 调用。N×M 塌缩成 N+M。

常见类比是 USB-C。这个类比只说对了一半。USB-C 规范的是物理接口，MCP 规范的是发现与调用两步：先问「你有什么」，再按声明的 schema 调用。发现这一步，才是它和普通插件系统的区别。

服务端只暴露三类原语

这三类是服务端 → 客户端方向，也是最常被用到的一组。

反方向还有三个原语，容易被混淆：sampling 让服务端反过来请求客户端跑一次模型采样；roots 让客户端限定服务端可访问的目录范围；elicitation 让服务端在执行中途向用户追问缺失信息。它们解决的是「工具执行到一半需要人或其他能力介入」的问题，不是工具本身的描述。

分清方向很重要：把 sampling 当成工具去调，是最常见的一类实现错误。

两种传输，一条老路已废弃

stdio：客户端把服务端拉起为子进程，走标准输入输出。没有端口、没有网络暴露，天然隔离在单机。本地文件操作、本地数据库查询这类场景，stdio 是默认选择。

Streamable HTTP：单个 endpoint，客户端 POST 请求，服务端可返回普通 JSON，也可升级为 SSE 流做增量推送。多租户、云端部署、需要跨网络访问时用这一种。

还有一条已废弃的路径：2025-03-26 版规范之前的「HTTP + SSE 双端点」方案，服务端一个端点建 SSE 连接、另一个端点发消息。它依赖长连接维持双向通道，在网关和负载均衡后面经常断。新实现不要再走这条路。

2026-07-28 改版：把状态拿掉

这是 MCP 推出以来的第五版主要规范，改动幅度为历次最大。

同版还正式引入了版本化扩展框架，把 MCP Apps 与 Tasks 两个扩展纳入体系。前者面向可交互的界面化能力，后者面向长任务的进度与状态管理——这两件事在纯请求-响应模型里都表达不了，所以必须靠扩展承载，而不是塞进核心协议。

去掉状态的三个理由

1. 负载均衡不再需要粘性会话。 有状态时，同一个客户端的请求必须打到同一台实例，扩容要迁移连接，缩容要等连接自然结束。无状态后，任意实例都能处理任意请求。
2. 无服务架构才可能部署。 Serverless 的冷启动维持不了长连接和内存里的会话表。这是很多团队想把 MCP Server 放到边缘或按量环境的硬门槛。
3. 故障恢复变简单。 实例挂掉不需要重放握手，客户端重发请求即可。

代价也要说清

无状态不是免费的。原本放在连接里的东西，现在要另找地方：

• 能力声明要随每次请求携带，或由客户端缓存后按版本号校验；
• 授权凭据每次都要带，token 校验从「连接时一次」变成「每请求一次」，鉴权层压力上升；
• 原本的内存会话态要外置到 Redis 或数据库，否则多实例之间读不到彼此写的东西；
• 工具列表不能再假设客户端只拉一次，需要 ETag 之类的缓存协商避免全量重传。

Server 要改的三处

第一处：移除对 initialize 的依赖

把「连接建立时协商一次能力」改成「每个请求自带能力声明」。如果你的 Server 在初始化时做了鉴权、限流初始化或工具注册，这些逻辑要挪到请求处理入口，并且必须可重入——同一个实例会连续处理不同客户端、不同凭据的请求。

第二处：移除 session ID

这是改动量最大的一处。原先存在会话对象里的东西，逐个判断：

• 属于用户身份的，交给 OAuth token 携带；
• 属于任务进度的，走 Tasks 扩展；
• 属于临时缓存的，放到外部 KV，key 用请求中的业务标识拼；
• 什么都对不上的，大概率本来就不该存。

判断标准很实用：如果这个状态在实例重启后消失会导致错误，它就不该放在进程内存里。

第三处：工具列表改为按需返回

无状态意味着每次 tools/list 都是全量。工具多的 Server（几十个以上）会出现明显的传输浪费。可行做法是给列表加版本号或 ETag，客户端带 If-None-Match，未变更返回 304 语义；或者按工具分组，让客户端按需拉取子集。

什么情况下不该用 MCP

协议不是越多越好。三类场景直接写 function calling 更划算：

• 单一应用内的固定工具。只有三五个工具、只服务一个产品，中间加一层发现协议只是多一跳。
• 高频低延迟路径。每次调用多一次列表查询或多一段能力声明，在 P99 延迟敏感的链路上会被放大。
• 强事务场景。无状态化之后，事务边界、幂等键都要自己管，MCP 不提供这层保证。

反过来，工具要被多个客户端复用、或者工具方与模型方不属于同一个团队时，MCP 的收益才明显——它省掉的正是跨团队对齐 schema 的成本。

路线图上的四件事

官方维护者在 2026 年 8 月给出的下一阶段优先级有四项：传输层的演进与可扩展性、Agent 之间的通信、治理成熟化、企业级就绪。

这个排序透露了定位变化：MCP 正在从「开发者接工具」的协议，往「多 Agent 协作 + 企业生产环境」的底座走。对实现方来说，短期要关注的是传输层的向后兼容，长期要关注的是治理——权限边界、审计日志、调用配额，这些目前都还没有统一答案。

落地顺序建议

如果现在要把一个已有 Server 迁到 2026-07-28 版，按这个顺序风险最低：

1. 先做无状态化改造，把会话态全部外置，用单实例跑通；
2. 再改鉴权，从连接级校验换成请求级校验，压测鉴权层；
3. 最后加缓存协商，工具列表和资源列表先上 ETag。

第 1 步不做完就上多实例，会出现「请求打到另一台就报会话不存在」的间歇性故障，而且很难复现。

已经用 MCP 接工具链的团队，可参考站内对 Dify 应用编排平台 与 n8n 的 Agent 节点 的拆解——两者都属于「把工具接进流程」的形态，但一个走平台内置、一个走节点编排，跟 MCP 的边界正好互补。IDE 侧的接入差异见 字节 TRAE。

一句话总结：2026-07-28 版把 MCP 从「一条常驻连接」改成了「一组独立请求」，扩容和部署因此变简单，代价是状态管理从协议层移到了你的应用层。改版本身不难，难的是找出那些默认「一直在同一个进程里」的隐式假设。