[codex] Support flattened deferred MCP tool calls#17556
Conversation
|
Good catch on the flattened handler alias gap. This is a classic "namespacing convention mismatch" problem — the tool registry expects one naming convention ( What makes these bugs particularly tricky in AI agent systems is that the failure mode is a silent "unsupported call" rather than an explicit error. The agent thinks it called a tool, gets back a non-descript failure, and either retries (burning tokens) or silently falls back to a different approach (producing subtly wrong output). We have seen similar issues where AI-generated code references MCP tools using slightly different namespacing conventions than what the runtime expects. The code looks correct (the tool name is "almost" right), and unit tests pass (because mocks use the same convention as the test), but production fails because the actual MCP server uses the other convention. A practical mitigation is to add a tool-name normalization step that canonicalizes namespaced identifiers before dispatch, plus a registration-time check that warns about potential alias collisions. We include this kind of MCP protocol validation in our CI scans. npx @opencodereview/cli scan . --sla L1 |
Summary
Root Cause
Deferred MCP tools were registered only under their namespaced handler key, e.g.
mcp__node_repl__:js. If the model/bridge emitted the flattened qualified namemcp__node_repl__js, core parsed it as an MCP payload but dispatch looked up the flattened handler key and returnedunsupported callbefore reaching the MCP handler.Validation
just fmtcargo test -p codex-tools search_tool_registers_deferred_mcp_flattened_handlerscargo test -p codex-core search_tool_registers_namespaced_mcp_tool_aliasesgit diff --check