MCP Python SDK 合并了一项被标记为非破坏性的破坏性变更

针对官方 Model Context Protocol Python SDK 的一个 pull request 于 8 月 28 日 UTC 14:54 被合并，改动了两项默认设置，这两项设置决定了 MCP 服务器保持连接的时长以及可接受的连接数量。

这两个默认值

会话空闲超时 从未设置变为 1,800 秒，因此在 30 分钟内没有活动的会话会被回收。最大并发会话数 从不设上限变为 10,000；超过这一上限后，服务器会返回 HTTP 503 和 JSON-RPC 错误码 -32603。这两个默认值都不难为其辩护——无限增长的会话表是拒绝服务攻击面，而不设上限的空闲超时则会造成资源泄漏。

常见表述哪里说错了

元数据称这项改动可以安全采用，而正文则说并非如此。该 pull request 自带一个 “Breaking Changes” 部分，但提交清单里 破坏性变更复选框未勾选，却勾选了两个表明相反结论的选项。传播出去的正是这种不一致：发布工具、变更日志生成器和语义版本决策读取的是清单，而不是正文。只看元数据的维护者会认为适合做小版本升级，下游运维人员也会在没有阅读提示其长连接会话如今会过期的部分的情况下完成升级。

这究竟会影响谁

任何会在较长的人类介入间隙中保持 MCP 会话开放的部署——比如等待审查的 agent，或者在上午和下午之间处于空闲状态的 assistant——都会开始在半小时节点看到会话消失。从客户端视角看，故障会是静默的，直到下一次调用才显现。并发会话超过一万个的部署会开始拒绝连接，而许多 MCP 客户端并不会把这个错误与服务器故障区分开来。

目前进展

这项改动已合并到 main 分支，但尚未发布，因此今天通过包管理器升级的任何人都还不会真正收到它。也正因如此，现在仍然有机会修正清单，并有意选择版本号升级。