Codex MCP Tool Search 路由：工具发现正在变成治理界面

OpenAI Codex 0.142.2 悄悄改变了 coding-agent 基础设施里常被低估的一层：agent 如何发现工具。6 月 25 日发布说明称，在支持的情况下，MCP tools 现在默认使用 tool search，从而改善工具发现，同时保持与旧模型和 provider 的兼容。相邻更新也很有 operator 信号：remote plugin catalog 会返回 curated featured-plugin ranking，remote stdio MCP server 接受远端平台格式的绝对工作目录，PowerShell 命令中安全分类器无法检查的 executable AST 区域现在需要审批。

这不是“工具选择器更好用了”这么简单。真正的运营变化是：MCP discovery 正变得动态、模型感知，并且部分远程化。一旦工具发现依赖模型能力、provider 支持、plugin catalog、远程 host 路径语义和安全 metadata，它就应该进入路由策略。

发生了什么

Codex 0.142.2 release notes 把 MCP tool search 列为新功能。当模型和 provider 支持 tool search 时，Codex 现在会默认用这条路径处理 MCP tools。OpenAI 给出的目标是改善发现效果，同时保持对旧模型和 provider 的兼容。

几个相邻变化强化了同一方向。Remote plugin catalog 现在返回 curated featured-plugin ranking，所以工具可用性不再只是本地 manifest 问题。Remote stdio MCP server 可以接受远程平台格式的绝对 working directory，这在 session 跨 macOS、Windows、Linux 或 remote executor 时很关键。Remote HTTP(S) image input 现在会返回 model-visible validation error，inline data URL 和本地图片继续支持。Codex 还要求对 PowerShell 中安全分类器无法检查的 executable AST 区域进行审批。

这些变化合在一起，让工具层更自适应，也更可观察。但如果 gateway 或 operator policy 仍把所有 Codex turn 当作普通模型 completion，就会丢失很多关键上下文。

为什么对 AI 工程团队重要

MCP 之所以扩张很快，是因为它让 coding agent 可以调用项目专属工具、内部服务、浏览器 session、数据库、构建系统和托管开发工作流。但 MCP tool 的风险并不相同。只读文档搜索、仓库 grep、staging deployment 和云凭据 helper，不应该在同一套发现、排序和调用策略下运行。

默认 tool search 带来三个 operator 问题：

• 哪些 model/provider 组合可以对这个 workspace 使用 MCP tool search？
• 哪些工具可以动态暴露，哪些必须显式 allowlist 或人工审批？
• 当远程 coding-agent session 中某个工具被发现、选择或隐藏时，团队如何审计原因？

兼容性说明也很重要。如果较旧的 provider 路径不支持 tool search，Codex 需要回退到旧的发现模式。这个 fallback 可能改变工具排序、延迟和 agent plan。团队比较模型层级时，应该比较完整的工具发现路径，而不只是 token 价格或 benchmark 分数。

路由与运维视角

更好的路由模式，是把 MCP discovery 当作 tool execution 之前的一等阶段。稳健策略至少要拆分五个决策：

• Discovery eligibility: 当前模型和 provider 是否可以在这个 workspace、用户和敏感级别下使用 tool search。
• Catalog trust: 工具来自本地 manifest、组织 catalog、remote plugin catalog，还是混合来源。
• Tool risk tier: 被发现的工具是只读、写代码、触碰基础设施，还是处理 secret。
• Host context: 工具运行在本地工作站、remote stdio server、云工作区，还是跨平台路径边界。
• Approval and audit: discovery、selection、invocation 和 command expansion 是否有足够上下文可审计。

TheRouter 用户尤其要注意 provider normalization。OpenAI-compatible routing 让模型替换更容易，但 MCP tool search 不是普通文本生成行为。如果 gateway 掩盖 provider 能力差异，应用可能误以为所有 route 都有同样的 tool-search 语义，而实际上只有部分 route 支持。这会造成隐蔽失败：工具缺失、路径处理错误、审批提示不同，或者 fallback 到治理更弱的 discovery 模式。

更安全的设计是 capability-aware route。模型 metadata 应该标明是否支持 MCP tool search、是否允许 remote plugin catalog、是否规范化 remote stdio path，以及哪些 approval class 是强制的。然后，低风险代码导航可以走更便宜的模型；tool-heavy 的补丁生成和部署任务则保留给更强或支持更完整的模型。

TheRouter 用户应关注或尝试什么

先按风险而不是名称盘点 MCP tools。把只读项目上下文工具、写代码工具、基础设施工具、身份工具和客户数据工具分开。然后做一个受控 Codex 0.142.2 对比：一条 route 支持 tool search，另一条 route 回退到旧发现行为。可以用 routing and governance overview 作为策略基线，再对照 model catalog 梳理模型能力差异，然后再把 tool-heavy session 开放给更多团队。

至少记录五个字段：selected model、provider route、requested tool-discovery mode、暴露给模型的 tools，以及最终调用的 tool。远程 session 还要加上 host OS、workspace path style、plugin catalog source 和 approval outcome。这些字段能让团队在 agent 用错工具或找不到正确工具时进行事后复盘。

可执行检查：

• 即使 tool search 改善了发现效果，高风险 MCP tools 仍要放在显式 allowlist 后面。
• 把 remote plugin catalog ranking 当作推荐，而不是 policy authority。
• 对无法被检查结构的 shell 命令要求更强审批，尤其是在 Windows 和 remote host 上。
• 在把 tool-heavy Codex session 路由到更便宜或更旧模型前，先做 provider capability check。
• 把 MCP tool 使用和 billing、project ledger 对齐，避免 tool-heavy session 看起来像普通 chat traffic。

更大的经验是：agent routing 正在变成 tool routing。当 MCP catalog、plugin store、remote executor 和 model-native tool search 汇合时，生产团队需要先治理 discovery，再治理 execution。否则最关键的路由决策，可能在模型写出第一行代码之前就已经发生了。