MCP tools silently unavailable with DeepSeek official setup (custom models.json: supports_search_tool=true + tool_mode=null)

Start in codex-rs/core/src/tools/spec_plan.rs and codex-rs/core/src/mcp_tool_exposure.rs, then trace build_model_visible_specs* and effective_tool_mode. Reproduce with the DeepSeek models.json configuration and an enabled stdio MCP server. Done means custom models expose MCP tools directly or through tool_search without breaking native catalog behavior.

Summary

Following DeepSeek's official one-command setup (irm https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.ps1 | iex), the generated ~/.codex/models.json registers deepseek-v4-flash / deepseek-v4-pro with "supports_search_tool": true and "tool_mode": null. On Codex 0.145.0 this combination makes all configured MCP tools silently unavailable: the session exposes web search and MCP resources, but no mcp__* callable tools and no tool_search.

Native OpenAI catalog models (e.g. gpt-5.6-sol, tool_mode: code_mode) can call the same MCP servers fine, so this only shows up with custom models registered through model_catalog_json.

Environment

• Codex CLI 0.145.0 on Windows
• Custom provider in config.toml: [model_providers.deepseek] with base_url = "https://api.deepseek.com/" and wire_api = "responses"
• model = "deepseek-v4-flash", model_catalog_json = "C:/Users/<user>/.codex/models.json" (written by the DeepSeek setup script)
• MCP servers: codegraph (stdio), idalib-mcp (stdio), universal-memory (stdio) — all enabled; codex mcp list shows Auth: Unsupported (expected for stdio)
• The MCP server handshake succeeds: idalib-mcp --stdio initialize + tools/list works, and in-session list_mcp_resources returns the server's resources

Reproduction

1. Run the DeepSeek setup script and choose model 1.
2. Add any stdio server under [mcp_servers.*] in config.toml.
3. Start a new session with deepseek-v4-flash.
4. Ask the model to call any MCP tool (e.g. mcp__idalib__server_health).

Actual: the model reports the tool is not in its available tool set. The session's tool surface contains web search and the MCP resource tools but neither mcp__* tools nor tool_search.

Expected: MCP tools registered in [mcp_servers.*] should be directly callable (or at least discoverable via tool_search) for custom models, matching catalog models.

Root cause (client-side)

• codex-rs/core/src/tools/spec_plan.rs: search_tool_enabled = model_info.supports_search_tool && provider.capabilities().namespace_tools
• codex-rs/core/src/mcp_tool_exposure.rs: when search_tool_enabled is true, every MCP tool is registered with ToolExposure::Deferred
• build_model_visible_specs* only emits tools whose exposure is_direct(); Deferred tools are excluded from the model-visible list
• effective_tool_mode: tool_mode: null plus no code-mode feature flags resolves to ToolMode::Direct, so there is no code-mode exec tool into which the deferred tools could be nested
• The DeepSeek setup script hardcodes "supports_search_tool": true (and "tool_mode": null) in the models.json it writes

Net effect: official DeepSeek setup + any MCP server = MCP tools silently invisible, with the tool_search escape hatch also absent from the session.

Workaround

Set "supports_search_tool": false in both entries of ~/.codex/models.json. MCP tools are then registered with ToolExposure::Direct and appear in a new session. Hosted web search is unaffected (it is driven by provider capabilities + web_search_tool_type, not supports_search_tool).

Related

• #33609 (closed): gpt-5.6-sol hides MCP tools without exposing tool_search
• #31750: custom model_provider, no tool_search / dynamic tool discovery
• #32101: Code Mode omits tool_search from exec, degrading deferred MCP discovery
• #34018: Windows Desktop custom stdio MCP tools pass discovery but are not exposed