Resolution failure for flattened MCP tool names from OpenAI-compatible proxies

Open 💬 3 comments Opened May 1, 2026 by rnett

What issue are you seeing?

When using Codex with non-GPT models via OpenAI-compatible proxies (e.g., Ollama, Bifrost, LiteLLM), MCP tools belonging to a namespace (e.g., mcp__tilth__) cannot be called. The proxy layer flattens the namespaced tool call into a single string (e.g., mcp__tilth__search) and provides it in the name field of the tool call.

Codex's McpConnectionManager and resolve_mcp_tool_info perform strict equality checks on ToolName structs. A call with the plain string mcp__tilth__search fails resolution even if the tool is registered under the mcp__tilth__ namespace. This leads to an "unsupported call" error or an "unsupported payload" error (if routed to the MCP handler without proper metadata).

What steps can reproduce the bug?

  1. Configure Codex to use a local Ollama or Bifrost instance as a model provider.
  2. Enable an MCP server (e.g., tilth).
  3. Attempt to use an MCP tool (e.g., mcp__tilth__search).
  4. Observe that the model generates a flat tool call {"name": "mcp__tilth__search", "arguments": ...}.
  5. Codex fails to resolve this call to the namespaced MCP tool.

What is the expected behavior?

Codex should attempt to "un-flatten" tool names that follow the standard mcp__<server>__<tool> pattern if a direct match fails.

Additional information

A suggested fix is to update McpConnectionManager::resolve_tool_info in codex-mcp/src/connection_manager.rs to attempt a fuzzy match. If a tool name starts with mcp__, the resolver should attempt to split it by __ and match it against registered namespaces.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗