# Codex tool_search deferred MCP tools and the supports_search_tool catalog flag > This ANSWERS the open question in codex-model-catalog-json-model-catalog-json-for.md: setting `supports_search_tool` to false in a catalog entry made Codex 0.145.0 to 0.147.0 register MCP tools as direct tools and show them in a new session, on three independent Windows and Linux reports. Parent: [Mac local LLMs: Agent clients, context and compaction](https://llms-explorer.com/tree/mac-local-llms-agent-clients-context-and-compaction/) · 1 facets · 16 facts · page: https://llms-explorer.com/tree/codex-tool-search-deferred-mcp-tools-and-the-sup/ ## Facts - This ANSWERS the open question in codex-model-catalog-json-model-catalog-json-for.md: setting `supports_search_tool` to false in a catalog entry made Codex 0.145.0 to 0.147.0 register MCP tools as direct tools and show them in a new session, on three independent Windows and Linux reports. — [source](https://github.com/openai/codex/issues/36382) - Codex computes `search_tool_enabled` as `model_info.supports_search_tool && provider.capabilities().namespace_tools` in `codex-rs/core/src/tools/spec_plan.rs`. — [source](https://github.com/openai/codex/issues/36382) - When `search_tool_enabled` is true, `codex-rs/core/src/mcp_tool_exposure.rs` registers every MCP tool as `ToolExposure::Deferred`, and `build_model_visible_specs*` emits only tools whose exposure is direct. — [source](https://github.com/openai/codex/issues/36382) - `tool_mode: null` with no code-mode feature flag resolves to `ToolMode::Direct`, so no code-mode exec tool exists to hold deferred tools. — [source](https://github.com/openai/codex/issues/36382) - DeepSeek's official Codex setup script hardcodes `"supports_search_tool": true` and `"tool_mode": null` in the `~/.codex/models.json` it writes, for `deepseek-v4-flash`, `deepseek-v4-pro` and a free variant. — [source](https://github.com/openai/codex/issues/36382) - With that catalog and an MCP server, the session showed web search and MCP resource tools but no `mcp__*` tools and no `tool_search`, even though `codex mcp list` showed the stdio server enabled and the MCP handshake succeeded. — [source](https://github.com/openai/codex/issues/36382) - Hosted web search stayed available with the flag set false, because it follows provider capabilities and `web_search_tool_type`, not `supports_search_tool`. — [source](https://github.com/openai/codex/issues/36382) - A reporter behind a LiteLLM to sglang router found that with the flag true Codex sends `type: "tool_search"` with no `function` field, LiteLLM's Responses-to-chat translation answers `400: Field required ... tools[13].function`, and a rewrite to a plain function fails in Codex with `tool_search handler received unsupported payload` (`core/src/tools/handlers/tool_search.rs`). — [source](https://github.com/openai/codex/issues/36382) - The same reporter found `supports_search_tool: false` did not expose MCP tools on that LiteLLM route, and suspected `provider.capabilities().namespace_tools` or `tool_mode` also gate exposure. — [source](https://github.com/openai/codex/issues/36382) - With `multi_agent_version: "v1"`, Codex registers the V1 multi-agent tools as deferred behind `tool_search`; `deepseek-v4-flash` does not recognise or call `tool_search`, so those tools are unreachable too. — [source](https://github.com/openai/codex/issues/36382) - `deepseek-v4-flash` answered a missing MCP tool by calling `list_mcp_resources`, seeing only `codex_apps`, and concluding no tool existed, so naming a tool in the prompt did not trigger a deferred call. — [source](https://github.com/openai/codex/issues/36382) - A fork commit dated 2026-08-03 titled "fix: keep MCP tools direct for unsupported search providers (#36382)" implements the direct-exposure fallback in a fork; no upstream merge is shown. — [source](https://github.com/openai/codex/issues/36382) - The same router reporter found its message coalescing dropped DeepSeek's `reasoning_content` on follow-up turns, producing `400: The reasoning_content in the thinking mode must be passed back to the API` from sglang whenever a tool call happened. — [source](https://github.com/openai/codex/issues/36382) - OpenAI's guide says `tool_search` is supported only on `gpt-5.4` and later in the Responses API, and that discovered tools are injected at the end of the context window to preserve the cache. — [source](https://developers.openai.com/api/docs/guides/tools-tool-search) - OpenAI recommends namespaces or MCP servers over bare deferred functions for tool search because the models were mostly trained to search those surfaces, and says a bare deferred function still shows its name and description, so only the parameter schema is deferred. — [source](https://developers.openai.com/api/docs/guides/tools-tool-search) - OpenAI advises keeping each namespace under 10 functions, and says `defer_loading` applies to the functions inside a namespace, not to the namespace object. — [source](https://developers.openai.com/api/docs/guides/tools-tool-search)