Resolution failure for flattened MCP tool names from OpenAI-compatible proxies
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?
- Configure Codex to use a local Ollama or Bifrost instance as a model provider.
- Enable an MCP server (e.g.,
tilth). - Attempt to use an MCP tool (e.g.,
mcp__tilth__search). - Observe that the model generates a flat tool call
{"name": "mcp__tilth__search", "arguments": ...}. - 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗