Codex MCP Tool Search routing: discovery is now a governance surface

OpenAI Codex 0.142.2 quietly changes a part of coding-agent infrastructure that teams often under-govern: how an agent discovers tools. The June 25 release says MCP tools now use tool search by default when supported, improving tool discovery while preserving compatibility with older models and providers. The same release includes related operator signals: remote plugin catalogs get curated featured rankings, remote stdio MCP servers accept absolute working directories in the remote platform's path format, and PowerShell commands containing executable AST regions the safety classifier cannot inspect now require approval.

The headline is not that Codex found a nicer tool picker. The operational shift is that MCP discovery is becoming dynamic, model-aware, and partly remote. Once tool discovery depends on model capability, provider support, plugin catalogs, remote host path semantics, and safety metadata, it belongs in routing policy.

What happened

The Codex 0.142.2 release notes list MCP tool search as a new feature. When a supported model and provider can use tool search, Codex now uses that path by default for MCP tools. The stated goal is better discovery while keeping compatibility with older models and providers.

Several adjacent changes reinforce the same direction. Remote plugin catalogs now return curated featured-plugin rankings, so tool availability is not only a local manifest problem. Remote stdio MCP servers can accept absolute working directories written in the remote platform's path format, which matters when a session spans macOS, Windows, Linux, or a remote executor. Remote HTTP(S) image inputs now return model-visible validation errors, while inline data URLs and local images remain supported. Codex also requires approval for PowerShell commands where executable AST regions cannot be inspected by the safety classifier.

Together, these changes make the tool layer more adaptive and more observable. They also create more places where a gateway or operator policy can lose important context if it treats all Codex turns as generic model completions.

Why it matters for AI engineering teams

MCP adoption has moved quickly because it lets coding agents use project-specific tools, internal services, browser sessions, databases, build systems, and hosted developer workflows. But the risk profile of an MCP tool is not uniform. A read-only docs search tool, a repository grep tool, a staging deployment tool, and a cloud credential helper should not be discovered, ranked, or invoked under the same policy.

Tool search by default raises three operator questions:

• Which model/provider combinations are allowed to perform MCP tool search at all?
• Which tools may be surfaced dynamically, and which require explicit allowlisting or human approval?
• How do teams audit why a tool was discovered, selected, or hidden during a remote coding-agent session?

The compatibility clause is important. If an older provider path does not support tool search, Codex needs a fallback discovery mode. That fallback can change tool ranking, latency, and the agent's plan. Teams comparing model tiers should therefore compare the full tool-discovery path, not just token price or benchmark score.

The router/operator angle

The right routing pattern is to treat MCP discovery as a first-class stage before tool execution. A robust policy separates at least five decisions:

• Discovery eligibility: whether the selected model and provider may use tool search for this workspace, user, and sensitivity level.
• Catalog trust: whether tools come from local manifests, organization catalogs, remote plugin catalogs, or a mixed source.
• Tool risk tier: whether the discovered tool is read-only, writes to code, touches infrastructure, or handles secrets.
• Host context: whether the tool runs on a local workstation, remote stdio server, cloud workspace, or cross-platform path boundary.
• Approval and audit: whether discovery, selection, invocation, and command expansion are logged with enough context to explain the agent's action.

TheRouter users should pay special attention to provider normalization. OpenAI-compatible routing makes model substitution easier, but MCP tool search is not just a text-generation behavior. If a gateway masks provider capability differences, the application may believe every route has the same tool-search semantics when only some do. That can produce subtle failures: missing tools, wrong path handling, different approval prompts, or a fallback to a less governed discovery mode.

The safer design is a capability-aware route. Model metadata should include whether MCP tool search is supported, whether remote plugin catalogs are allowed, whether remote stdio paths are normalized, and which approval classes are mandatory. That route can then choose a cheaper model for low-risk code navigation while reserving a stronger or better-supported model for tool-heavy patch generation and deployment tasks.

What TheRouter users should watch or try

Start by inventorying MCP tools by risk, not by name. Separate read-only project context tools from code-writing tools, infrastructure tools, identity tools, and customer-data tools. Then run a controlled Codex 0.142.2 comparison across two routes: one where tool search is supported and one where Codex falls back to older discovery behavior. Use the routing and governance overview as the policy baseline, then map model capability differences against the model catalog before opening tool-heavy sessions to more teams.

Log at least five fields: selected model, provider route, requested tool-discovery mode, tools surfaced to the model, and the final tool invoked. For remote sessions, add host OS, workspace path style, plugin catalog source, and approval outcome. These fields make post-incident review possible when an agent uses the wrong tool or fails to find the right one.

Operational checks:

• Keep high-risk MCP tools behind explicit allowlists even if tool search improves discovery.
• Treat remote plugin catalog rankings as recommendations, not policy authority.
• Require stronger approval for shell commands whose structure cannot be inspected, especially on Windows and remote hosts.
• Add provider capability checks before routing tool-heavy Codex sessions to cheaper or older model paths.
• Reconcile MCP tool use with billing and project ledgers so tool-heavy sessions do not appear as ordinary chat traffic.

The broader lesson is portable: agent routing is now tool routing. As MCP catalogs, plugin stores, remote executors, and model-native tool search converge, production teams need to govern discovery before execution. Otherwise the most important routing decision may happen before the model writes a single line of code.