# Codex namespace and hosted tool types skipped by local servers > In a `codex exec` run against llama-server with one MCP server, the outbound `tools[]` held 13 native Codex function tools, `{"type":"web_search"}` and one `namespace` entry with two nested `function` tools. Parent: [Mac local LLMs: Agent clients, context and compaction](https://llms-explorer.com/tree/mac-local-llms-agent-clients-context-and-compaction/) · 2 facets · 15 facts · page: https://llms-explorer.com/tree/codex-namespace-and-hosted-tool-types-skipped-by/ ## Facts - In a `codex exec` run against llama-server with one MCP server, the outbound `tools[]` held 13 native Codex function tools, `{"type":"web_search"}` and one `namespace` entry with two nested `function` tools. — [source](https://github.com/openai/codex/issues/23186) - The same Codex session over the ChatGPT websocket transport sends an identical `namespace` shape, and the ChatGPT backend unwraps it server-side. — [source](https://github.com/openai/codex/issues/23186) - The issue lists affected backends: llama.cpp skips `namespace` silently, LM Studio rejects it with `invalid_request_error`, DeepSeek via CLIProxyAPI returns plain text with no `function_call`, and Ollama's Responses API lost MCP tool invocation from Codex v0.117.0. — [source](https://github.com/openai/codex/issues/23186) - The issue proposes that Codex flatten MCP namespaces into top-level function tools whenever the transport is not the ChatGPT websocket, keeping the namespaced name end to end. — [source](https://github.com/openai/codex/issues/23186) - The Codex issue was labelled bug, CLI, mcp, custom-model and exec, and was still open with new comments on 2026-08-18. — [source](https://github.com/openai/codex/issues/23186) - A user proxy (`codex-ollama-proxy`) flattens `namespace` tools, maps returned flat names back to `{namespace, name}`, lifts newer `additional_tools` input items into the top-level tool list, translates custom tools such as `apply_patch`, and translates ordinary `tool_search` function calls back into native `tool_search_call` items. — [source](https://github.com/openai/codex/issues/23186) - A second gateway test with Ollama showed the model receiving only `function` tools and its call returning as `{"type":"function_call","name":"search","namespace":"mcp__open_websearch__",...}`, so same-named tools on two servers stay distinct. — [source](https://github.com/openai/codex/issues/23186) - The llama.cpp PR 23041 author lists `file_search`, `web_search`, `mcp`, `image_generation` and `namespace` as Responses tool types beyond `function`, and says llama.cpp passes to the backend only the ones it can support. — [source](https://github.com/ggml-org/llama.cpp/pull/23041) - A reviewer on the PR called full parity infeasible because OpenAI keeps changing Codex, and the PR author said server-hosted tools (`web_search`, `code_interpreter`, `mcp`) belong in a separately maintained tools service, outside the PR. — [source](https://github.com/ggml-org/llama.cpp/pull/23041) - PR 23041 added a warning for each skipped Responses tool and kept a rejection for the Codex plus gpt-oss `apply_patch` freeform tool, but the author later dropped that legacy path after finding Codex 0.130.0 no longer advertised `apply_patch` for gpt-oss-20b. — [source](https://github.com/ggml-org/llama.cpp/pull/23041) - The PR was merged as commit 91e84fed64329cd96202d68220724a1d92f5ec1f. — [source](https://github.com/ggml-org/llama.cpp/pull/23041) - A downstream fork commit message states that Codex sends the `namespace` type unconditionally even with no MCP servers configured, and that it drops non-function hosted tool types with a warning and merges every system-level item into one leading system message. — [source](https://github.com/ggml-org/llama.cpp/pull/23041) - The Unsloth Codex guide runs raw llama-server on port 8001 with all agent tool calls routed through one OpenAI-compatible endpoint, and says to add `--disable-tools` so the agent's own tools pass through. — [source](https://unsloth.ai/docs/basics/codex) - Inferred: a Codex user on llama-server who depends on MCP servers should put a flattening proxy in front, because llama.cpp will not unwrap `namespace`. — source: `asserted` ## Corrections and disagreements - This CONTRADICTS the inferred claim in codex-responses-api-compatibility-on-local-serve.md that it is unknown which functions a skipped `namespace` carries: Codex wraps each configured MCP server as `{"type":"namespace","name":"mcp____","tools":[function, ...]}`, so skipping it removes every tool of that MCP server. — [source](https://github.com/openai/codex/issues/23186)