MCP tools silently unavailable with llama-server backends — add option to flatten namespace tool specs to functions

Start in codex-rs/core/src/tools/handlers/mcp.rs at create_tool_spec, then trace ProviderCapabilities::namespace_tools through custom provider configuration. Reproduce with a custom wire_api="responses" provider and llama-server, using one stdio MCP server. Done means the provider option emits prefixed flat function tools and MCP calls still resolve correctly instead of being silently skipped.

What variant of Codex are you using?

CLI

What feature would you like to see?

A per-provider compatibility option to expose MCP tools as plain type: "function" entries
(with prefixed names) instead of a type: "namespace" entry, for Responses API backends that
do not implement the namespace tool type.

Why: since ~0.144, codex sends each configured MCP server's tools as ONE type: "namespace"
entry in the Responses tools array (create_tool_spec in codex-rs/core/src/tools/handlers/mcp.rs,
unconditional). Backends that implement /v1/responses by translating to chat completions — e.g.
llama.cpp's llama-server — skip every non-function tool type (tools/server/server-chat.cpp:
"unsupported Responses tool type ... skipped"). The result is fully silent: built-in tools work,
codex mcp list shows the server enabled, the server's stdio handshake and tools/list succeed,
yet the model never sees any MCP tool, in the TUI and in ACP clients alike. There is no config
escape today: ProviderCapabilities::namespace_tools is hard-true for custom TOML providers,
and no flatten path exists.

Ask (either would work):

• honor a namespace_tools = false key on [model_providers.<id>], falling back to the
  pre-namespace behavior (flat prefixed function specs); or
• a [features]/provider-level mcp_tool_compat = "flatten" option with the same effect.

Feasibility evidence: we run a proxy in front of llama-server that does exactly this
translation and codex works end to end with local models: expand each namespace entry to flat
functions named <namespace>__<tool> on the request, and rewrite the model's function_call
items back to the split {"namespace": ..., "name": ...} form on the response (codex's tool
router resolves calls by exact (namespace, name) lookup, so both directions are needed).
Having codex emit the flat form natively would remove the need for that middleware for every
local-model user.

Additional information

• Reproduction: any custom model_provider with wire_api = "responses" pointed at
  llama-server (current master), one stdio MCP server under [mcp_servers.*], new session →
  ask the model to list its callable tools: built-ins only, no mcp__* tools, no error anywhere
  (llama-server logs the skip at WARN).
• Verified against codex 0.146.0 (npm) and main d1fb77d (2026-08-04); llama.cpp master as of the
  same date still skips non-function Responses tool types, so the gap is real on both sides today.
• Possibly the same underlying mechanism as #36382 ("MCP tools silently unavailable with DeepSeek
  official setup" — custom provider, wire_api = "responses", resources visible but no callable
  MCP tools): if DeepSeek's Responses implementation also drops unknown tool types, that report's
  models.json theory would be a red herring and this option would fix it too.
• Happy to test a build; the middleware workaround above is in production for us, so this is a
  compatibility improvement for the local/OSS-backend ecosystem rather than an urgent blocker.