GPT-5.6 Sol Responses Lite hides custom MCP tools; disabling Responses Lite restores them

What version of the Codex App are you using (From “About Codex” dialog)?

Powered by Codex & OWL Version 26.707.91948 Released Jul 16, 2026

What subscription do you have?

pro

What platform is your computer?

macOS 26.5.2, Apple Silicon (arm64)

What issue are you seeing?

With gpt-5.6-sol, a healthy custom stdio MCP server is discovered and its
resources and resource templates can be listed, but its callable tools are
absent or unreachable in Codex Desktop and codex exec.

The server exposes multiple tools. A standalone MCP client successfully:

1. Initializes the same server process.
2. Receives all registered tools from tools/list.
3. Calls a read-only status tool and receives the expected response.

In Codex, the model may call list_mcp_resources, but it cannot invoke the
server's registered tools. It instead reports that the requested MCP tool is
unavailable.

This appears to be specific to the Responses Lite request path. I copied the
current gpt-5.6-sol model catalog entry and changed only:

"use_responses_lite": false

With that single change, the same MCP tool call succeeds with both Codex
0.144.5 and 0.145.0-alpha.18. Removing the override makes the tool
unavailable again. GPT-5.4 can also call the same MCP tool with the same MCP
configuration.

What steps can reproduce the bug?

1. Configure a working custom stdio MCP server that exposes at least one

resource and one read-only tool:

``toml
[mcp_servers.example_server]
command = "<MCP_SERVER_EXECUTABLE>"
args = ["<OPTIONAL_ARGUMENTS>"]
``

1. Confirm independently that the server is healthy:

• initialize succeeds.
• tools/list includes the read-only tool.
• Calling that tool through a standalone MCP client succeeds.

1. Start a fresh Codex Desktop task using gpt-5.6-sol.

1. Ask Codex to call the tool directly:

``text
Call the example_server MCP tool health_check exactly once.
Do not inspect files, do not use the shell, and do not modify anything.
Return only whether the MCP call succeeded and its status.
``

1. Observe that Codex may discover the server's resources, but does not call

health_check and reports that the tool is unavailable.

1. The CLI behavior can be reproduced with an equivalent command:

``shell
codex exec --ephemeral --json \
-m gpt-5.6-sol \
-s read-only \
-C "<TRUSTED_DIRECTORY>" \
'Call the example_server MCP tool health_check exactly once. Do not inspect files, do not use the shell, and do not modify anything. Return only whether the MCP call succeeded and its status.'
``

1. Copy the current gpt-5.6-sol model entry to a local model catalog,

changing only use_responses_lite to false, and configure Codex to use
it:

``toml
model_catalog_json = "<MODEL_CATALOG_FILE>"
``

1. Repeat the same prompt. The MCP tool now succeeds.

The results observed were:

| Codex version or configuration | Result |
| --- | --- |
| 0.144.0-alpha.4, default Sol metadata | MCP tool unavailable |
| 0.144.2, default Sol metadata | Only resource listing reached; MCP tool unavailable |
| 0.144.4, default Sol metadata | MCP tool unavailable |
| 0.144.5, default Sol metadata | MCP tool unavailable |
| 0.145.0-alpha.13, default Sol metadata | MCP tool unavailable |
| 0.145.0-alpha.18, default Sol metadata | MCP tool unavailable |
| 0.144.5, identical Sol catalog except use_responses_lite=false | MCP tool succeeds |
| 0.145.0-alpha.18, identical Sol catalog except use_responses_lite=false | MCP tool succeeds |
| GPT-5.4 with the same MCP configuration | MCP tool succeeds |

All server names, tool names, paths, and arguments in this report are
anonymized placeholders.

What is the expected behavior?

Every tool returned by an enabled MCP server's tools/list response should be
callable by the selected model.

Enabling Responses Lite must not make custom MCP tools unreachable. A request
for the read-only tool should execute normally, just as it does through a
standalone MCP client, with GPT-5.4, and with the otherwise identical
gpt-5.6-sol model catalog entry using use_responses_lite=false.

Additional information

This looks consistent with the Responses Lite tool-exposure problems reported
in:

• #31894
• #32086

Those issues describe tools or the tool-search mechanism being moved into
additional_tools while the top-level tools field is absent, leaving the
tools unreachable to the model. In this reproduction, resources remain
discoverable while the custom MCP tool namespace cannot be invoked.

It may also overlap with the Codex Desktop MCP symptom reported in:

• #19425

There was a working gpt-5.6-sol Desktop task before a Desktop update.
However, isolated reruns with older Codex binaries under the current model
metadata still fail. This suggests that the regression is connected to the
current Sol metadata or request path rather than solely to one client binary.

The strongest A/B evidence is:

• Same model slug
• Same prompt
• Same MCP process and configuration
• Same authentication and sandbox
• Same working directory
• Only use_responses_lite changed from true to false
• MCP tool unavailable with Responses Lite
• MCP tool succeeds without Responses Lite

A possible fix is to preserve a callable route to custom MCP tools when
Responses Lite is enabled—for example, by retaining the required MCP tool or
tool-search schema in the top-level tools collection, or otherwise ensuring
that the model can invoke the MCP namespace advertised through
additional_tools.