Codex now searches for MCP tools before calling them on supported setups. That behaviour is easy to miss if Tool Search is treated as a replacement for Tool Calling, because the call still happens. What changed is the path that makes a tool definition available to the model in the first place.
Codex CLI 0.143.0 made Tool Search the default path for MCP tools. The implementation work landed earlier in PR #29486, which also records a useful piece of history: Codex had previously deferred MCP tools only when a feature flag was enabled or when the tool count reached at least 100. The newer flow removed that count-dependent behaviour for supported model/provider combinations.
The PR’s tests show the runtime sequence:
Tool Search
↓
Matching MCP tool becomes available
↓
Tool CallingThe model receives tool_search, searches, receives the matching MCP tool, and calls it on the next request. If search is unavailable, Codex keeps the direct-exposure path for compatibility.
The runtime now contains two separate decisions. Tool Search handles discovery; Tool Calling handles invocation after the relevant definition is available.
Why put discovery in front of the call?
Function calling is straightforward when the tool surface is small. Give the model the tool definitions, let it choose one and produce arguments, execute the call in the application, then return the output to the model.
User request
↓
Model receives tool schemas
↓
Tool call: name + arguments
↓
Application executes the tool
↓
Tool output
↓
Model continuesNothing is wrong with that design. The cost appears when the catalogue grows.
A tool definition is part of the model input. Descriptions, parameter schemas, required fields, enumerations and nested objects all consume tokens before the task has used any of them. Once an agent is connected to GitHub, Drive, databases, internal APIs and several MCP servers, a typical request may need only a small fraction of the available tools while still paying to carry every definition upfront.
Tool Search moves the full definitions out of the initial request. GPT-5.4 can start with lightweight information about the available tools plus a search capability, then bring the matching full definition into the conversation when the task actually needs it.
User request
↓
Lightweight tool information + Tool Search
↓
Search for relevant tools
↓
Load matching tool definition
↓
Tool call: name + arguments
↓
Tool execution
↓
Tool result
↓
Model continuesTool count on its own is a poor design threshold. A better check is whether unused schema text has become a meaningful fixed cost for the workload in front of you.
The 47% result shows the cost can become material
OpenAI evaluated 250 Scale MCP Atlas tasks with all 36 MCP servers enabled. One configuration exposed every MCP function directly in model context; the other placed the servers behind Tool Search.
The Tool Search configuration used 47% fewer total tokens at the same accuracy.
The number belongs to that benchmark and configuration, not to Tool Search in general. For that tool-heavy workload, though, the schema overhead was large enough to show up clearly in total token use. OpenAI also cites prompt-cache preservation as a benefit of avoiding a large, changing block of complete tool schemas on every request.
Discovery adds its own failure mode
Deferring definitions removes upfront context, but the search step can fail before argument generation begins. A model can miss the relevant tool even when that tool exists and would have been callable if its definition were already present.
Codex’s searched-tool flow places tool names, descriptions and input fields in the search result. PR #29486 does not publish a ranking formula, so those fields should not be treated as undocumented search-tuning controls. Operationally, discovery can now fail independently of invocation.
During debugging, the failures separate cleanly:
| Layer | Question to ask |
|---|---|
| Availability | Is the tool connected or registered in the system’s tool surface? |
| Discovery | Did this task surface the relevant definition? |
| Invocation | Did the model choose the right tool and produce valid arguments? |
| Execution | Did the tool actually run and return a result? |
This four-state view is an explanatory model for this article, not an official OpenAI taxonomy. Connection only tells you that the tool exists in the system’s tool surface. Configuration or filtering may still keep it out of the next stage.
Execution also has a separate security boundary. OpenAI describes the Codex sandbox as the technical execution boundary, while approval policy governs when an action needs additional authorisation. Tool discovery changes visibility; it does not grant broader sandbox access, authentication or permissions.
Direct exposure still has a clean use case
A search layer is useful only when the context it avoids is worth the extra discovery step. A small, stable set of short schemas may be simpler to expose directly, especially when latency is sensitive and the catalogue changes rarely.
The case for deferred discovery becomes stronger when the opposite is true: many MCP servers are enabled, schemas are verbose, most tasks touch only a small slice of the catalogue, and that catalogue keeps growing. In that environment, carrying every full definition on every request becomes increasingly wasteful.
For a custom agent, start with the workload instead of inventing a magic tool-count threshold. Measure how much of the prompt is schema text and how much of the catalogue a normal task actually touches. If the catalogue changes often, repeated upfront exposure keeps getting more expensive. Then decide whether the saved context is worth the extra discovery round and its latency.
Codex users on supported MCP setups do not need to recreate that switch manually. When a tool appears not to work, locate the failing layer first: connection, discovery, invocation or execution. They can produce the same surface symptom and require completely different fixes.
References
- OpenAI, Function calling, documentation. https://developers.openai.com/api/docs/guides/function-calling
- OpenAI, Function calling and other API updates, 13 June 2023. https://openai.com/index/function-calling-and-other-api-updates/
- OpenAI, Introducing GPT-5.4, 5 March 2026. https://openai.com/index/introducing-gpt-5-4/
- openai/codex GitHub PR #29486, [codex] Use tool search for MCP tools by default, merged 22 June 2026. https://github.com/openai/codex/pull/29486
- openai/codex GitHub release, Codex 0.143.0, 8 July 2026. https://github.com/openai/codex/releases/tag/rust-v0.143.0
- OpenAI, Running Codex safely at OpenAI, 8 May 2026. https://openai.com/index/running-codex-safely/