MCP unsupported call
Open 💬 2 comments Opened Jul 2, 2026 by sunwei-yhc
What version of Codex CLI is running?
codex-cli 0.142.5
What subscription do you have?
No
Which model were you using?
MinimaxM3
What platform is your computer?
macOS-M3Max-版本：26.5.1
What terminal emulator and version are you using (if applicable)?
Ghostty
Codex doctor report
three MCP services, codegraph, context7, and chrome_devtools.
All three calls return 'unsupported call'What issue are you seeing?
After connecting to the Minimax M3 model, the model can be used normally, but the MCP tool in codexcli cannot be used properly, with an error message: parallel testing of the three MCP services, codegraph, context7, and chrome_devtools.
All three calls return 'unsupported call'
What steps can reproduce the bug?
<img width="3262" height="1854" alt="Image" src="https://github.com/user-attachments/assets/ce8723df-9c49-4955-be41-0c363fccf4b0" />
What is the expected behavior?
_No response_
Additional information
_No response_
2 Comments
The strongest signal here is that three unrelated MCP servers all fail with the same
unsupported callonly in the custom-model path. I would try to separate MCP server setup from model/tool-call compatibility before debugging codegraph/context7/chrome_devtools individually.A small repro that would help maintainers: run the same Codex config once with the default OpenAI model and once with MinimaxM3, then capture the doctor output plus the exact provider response around the first attempted tool call. If the default model can invoke one trivial MCP tool but MinimaxM3 cannot, this is probably in the custom provider's tool-call adapter/shape rather than in the MCP servers themselves.
Same root cause, with a more specific reproduction that confirms the Apps SDK angle.
Filed #31354 with full RCA: all 7
unsupported callhits in~/.codex/logs_2.sqlitecome fromMiniMax-M3(same model as you), and the failure happens atcore/src/tools/router.rs:185(dispatch_tool_call_with_terminal_outcome) before the MCP child process is even reached — verified by running the MCP probe script standalone and gettingOK: ....The interesting twist that distinguishes this from a generic MCP failure: even non-widget MCP tools on the same Apps SDK MCP server also fail (e.g.
get_cowart_canvas_state,save_cowart_canvas_state, ...), because Codex namespaces the whole server as an Apps SDK server based on_meta.ui.resourceUri/openai/outputTemplateexposed by any of its tools. So this equally affects Cowart, Canva, Computer Use, and any future Apps-style MCP server used with a custom Responses provider.A clean repro (Cowart
v0.1.11+ Codex CLI0.142.5+MiniMax-M3) and the exact dispatcher path are in #31354. Addingcowart@personalto the three MCPs in your doctor output should reproduce this 1:1.