LiteLLM 把 stdio MCP 默认关了：升级之后，你的 MCP 工具会静默消失
自建 LLM 网关这件事，过去两年一直有个隐含假设：跑在本机上的东西是自己人。LiteLLM 这个版本把这个假设拿掉了。
v1.106.0 发布于 10 月 18 日 05:53。“What’s Changed”里有一条前面带感叹号的提交，Conventional Commits 的写法里 feat(mcp)! 那个叹号就是破坏性变更的标记：
feat(mcp)!: disable stdio MCP servers by default
一句话，stdio 方式的 MCP server 默认不启用了。同一版的其它改动也是同一个方向：防止 LiteLLM 自己的 key 被转发给 MCP server、加了 pass-through 拒绝名单、静态加密的密钥存储、FIPS 模式。还没进稳定版的 v1.107.0-rc.1 里又有一条 feat(proxy): add agent_access_default_deny for least-privilege agent access，把 agent 的访问权限也改成默认拒绝。
为什么这条值得单独说
因为它是”静默”的。
MCP server 从可用变成不可用，通常不会抛一个写着”你没开开关”的错误。它更像工具列表里少了几项，或者 agent 说”我没有这个能力”。你会先怀疑自己的配置、怀疑模型、怀疑 agent 的提示词，最后才想到是网关升级改了默认值。这个过程烧掉的时间，通常比读一遍 release notes 多得多。
今天要做的事
第一，升级前先看 PR #44066。有一点我要说清楚：release 页面只自动生成了 PR 标题、作者和编号，正文里没有给出重新启用的配置项名称。我没找到官方写的开关名，所以也不在这里猜一个给你。正确做法是打开那个 PR 看正文，或者等文档更新。凭印象填一个 enable_stdio_mcp: true 之类的键，比不填更糟——YAML 里写错的配置键会被静默忽略。
第二，给你的工具列表做一条基线。在升级前跑一次，把 agent 实际能看到的工具名存成一个文件，升级后再跑一次对比。没有基线，你只能靠”感觉好像少了点什么”来发现。
第三，把”默认拒绝”当成你自己的产品默认值。LiteLLM 这次的改动方向，和 Claude Code 那边 PreToolUse 钩子、作用域令牌的做法是一致的：权限从”先给再收”变成”先不给，用到再加”。你自己的 agent 也应该这么设，尤其是它会碰文件系统和外部 API 的时候。
泼冷水
默认关掉确实更安全，但它解决的问题和你真正会遇到的问题不完全重合。这次改的是 stdio——也就是本机子进程那种 MCP。走 HTTP 的远程 MCP server 不在这次范围内，而真正危险的往往是那些你从网上抄来、npx 一下就跑起来的第三方 server。守住了 stdio 这一道，不等于守住了那道。
另外 v1.107.0-rc.1 是候选版，它同时改了 count_tokens 的行为和部分 Bedrock、计数接口的错误格式。按官方自己的说法，依赖这些接口的应用要先做兼容性测试。别把 rc 版直接上生产。
具体建议
- 今天打开你网关的部署文件，看一眼现在锁的是哪个版本。没锁版本的话，这一条比 MCP 这件事更值得先修。
- 如果你已经在用 stdio MCP，先在本地环境升一次，确认工具列表没变，再动生产。
- 顺手统计一下你的 agent 到底用了几个 MCP server。超过 5 个的话，多半有几个是当时图新鲜装上的，从来没真正用过——清掉它们比配置开关更有效。