Codex MCP Tool Search routing: discovery становится governance surface

OpenAI Codex 0.142.2 по умолчанию использует tool search для MCP tools, когда это поддерживается. Для operator teams tool discovery становится решением по routing, audit и provider compatibility, а не удобством локального клиента.

TheRouter Newsroomисточник OpenAI Codex
Coding agent discovers governed tool lanes between two workstations through a central routing layer

OpenAI Codex 0.142.2 тихо меняет слой coding-agent infrastructure, который команды часто недоуправляют: как agent discovers tools. В релизе от 25 июня сказано, что MCP tools теперь используют tool search by default, когда это поддерживается, улучшая tool discovery и сохраняя compatibility со старыми models и providers. В том же релизе есть смежные operator signals: remote plugin catalogs возвращают curated featured rankings, remote stdio MCP servers принимают absolute working directories в формате remote platform, а PowerShell commands с executable AST regions, которые safety classifier не может inspect, теперь требуют approval.

Главная новость не в более удобном tool picker. Операционный сдвиг в том, что MCP discovery становится dynamic, model-aware и частично remote. Когда tool discovery зависит от model capability, provider support, plugin catalogs, remote host path semantics и safety metadata, это уже часть routing policy.

Что изменилось

В Codex 0.142.2 release notes MCP tool search указан как new feature. Когда supported model и provider могут использовать tool search, Codex теперь выбирает этот путь by default для MCP tools. Заявленная цель — улучшить discovery и сохранить compatibility with older models and providers.

Несколько соседних изменений подтверждают тот же вектор. Remote plugin catalogs теперь возвращают curated featured-plugin rankings, поэтому tool availability больше не является только local manifest problem. Remote stdio MCP servers могут принимать absolute working directories в формате remote platform, что важно, когда session проходит через macOS, Windows, Linux или remote executor. Remote HTTP(S) image inputs теперь возвращают model-visible validation errors, а inline data URLs и local images остаются supported. Codex также требует approval для PowerShell commands, executable AST regions которых safety classifier не может проверить.

Вместе эти изменения делают tool layer более adaptive и observable. Но они также создают больше мест, где gateway или operator policy потеряет важный context, если будет считать все Codex turns обычными model completions.

Почему это важно для AI-инженерных команд

MCP быстро распространился, потому что дает coding agents доступ к project-specific tools, internal services, browser sessions, databases, build systems и hosted developer workflows. Но risk profile у MCP tools разный. Read-only docs search tool, repository grep tool, staging deployment tool и cloud credential helper не должны discovered, ranked или invoked по одной policy.

Tool search by default поднимает три operator questions:

  • Какие model/provider combinations могут вообще выполнять MCP tool search?
  • Какие tools можно показывать dynamically, а какие требуют explicit allowlist или human approval?
  • Как audit why a tool was discovered, selected, or hidden во время remote coding-agent session?

Compatibility clause важен. Если older provider path не поддерживает tool search, Codex нужен fallback discovery mode. Этот fallback может изменить tool ranking, latency и plan агента. Поэтому teams должны сравнивать полный tool-discovery path, а не только token price или benchmark score.

Взгляд со стороны роутинга и эксплуатации

Правильный routing pattern — считать MCP discovery first-class stage до tool execution. Надежная policy разделяет минимум пять решений:

  • Discovery eligibility: может ли выбранный model и provider использовать tool search для этого workspace, user и sensitivity level.
  • Catalog trust: откуда приходят tools — local manifests, organization catalogs, remote plugin catalogs или mixed source.
  • Tool risk tier: discovered tool является read-only, writes to code, touches infrastructure или handles secrets.
  • Host context: tool runs on local workstation, remote stdio server, cloud workspace или cross-platform path boundary.
  • Approval and audit: discovery, selection, invocation и command expansion логируются с достаточным context.

TheRouter users стоит особенно следить за provider normalization. OpenAI-compatible routing упрощает model substitution, но MCP tool search — не просто text-generation behavior. Если gateway скрывает различия provider capabilities, приложение может думать, что все routes имеют одинаковые tool-search semantics, хотя это верно только для части маршрутов. Так появляются subtle failures: missing tools, wrong path handling, different approval prompts или fallback to less governed discovery mode.

Более безопасный дизайн — capability-aware route. Model metadata должен включать: поддерживается ли MCP tool search, разрешены ли remote plugin catalogs, нормализуются ли remote stdio paths и какие approval classes обязательны. Тогда можно выбирать дешевый model для low-risk code navigation и оставлять stronger or better-supported model для tool-heavy patch generation и deployment tasks.

Что стоит проверить или попробовать пользователям TheRouter

Начните с inventory MCP tools по risk, а не по name. Разделите read-only project context tools, code-writing tools, infrastructure tools, identity tools и customer-data tools. Затем проведите controlled Codex 0.142.2 comparison на двух routes: одна поддерживает tool search, другая использует older discovery behavior.

Логируйте минимум пять fields: selected model, provider route, requested tool-discovery mode, tools surfaced to the model и final tool invoked. Для remote sessions добавьте host OS, workspace path style, plugin catalog source и approval outcome. Эти fields нужны для post-incident review, если agent использовал не тот tool или не нашел правильный.

Операционные проверки:

  • Держите high-risk MCP tools за explicit allowlists, даже если tool search улучшает discovery.
  • Считайте remote plugin catalog rankings рекомендациями, а не policy authority.
  • Требуйте stronger approval для shell commands, структуру которых нельзя inspect, особенно на Windows и remote hosts.
  • Добавьте provider capability checks перед routing tool-heavy Codex sessions на cheaper или older model paths.
  • Связывайте MCP tool use с billing и project ledgers, чтобы tool-heavy sessions не выглядели как ordinary chat traffic.

Главный вывод переносим: agent routing теперь становится tool routing. Когда MCP catalogs, plugin stores, remote executors и model-native tool search сходятся, production teams должны govern discovery before execution. Иначе самое важное routing decision произойдет еще до того, как model напишет первую строку кода.

Абстрактная схема: org-level MCP server governance — поток конфигурации от администратора к параллельным Claude Code сессиям

Claude Code 2.1.259: Org-Level MCP Server Push и исправление потери состояния при параллельных сессиях

Claude Code 2.1.259 добавляет managedMcpServers для централизованного развёртывания HTTP/SSE MCP серверов, меняет семантику allowedMcpServers и закрывает баг, из-за которого параллельные сессии тихо перезаписывали состояние ~/.claude.json в CI-окружениях.

источник Claude Code CHANGELOG
Абстрактная схема маршрутизации с изображением контролей сессии и лимитов делегирования агентов

Claude Code 2.1.212: лимиты субагентов, автофон MCP и исправление кэширования на кастомных шлюзах

Версия 2.1.212 вводит настраиваемые лимиты субагентов и вызовов WebSearch на сессию, автоматически переносит долгие MCP-вызовы в фон и восстанавливает prompt caching за кастомными API gateway, Bedrock и Vertex.

источник Anthropic Claude Code
Помощь и контакты