That’s a weird one. I’ve seen similar session issues with other platforms but not quite like this.
The regional pricing thing is an interesting clue. If ChatGPT is changing pricing based on IP, they’re definitely doing some region-specific routing. That could easily affect how MCP tools are injected or cached.
I’ve noticed the same behavior with multiple MCPs loaded - seems to increase the chance of tools randomly vanishing. Almost like there’s a limit or a race condition in the session handling.
Also, the fact that creating a new MCP with a different name temporarily fixes it suggests the issue is with the session state or cache tied to the tool ID, not the server itself. The server logs being clean confirms that.
Have you tried clearing browser cache and cookies completely? Not just session data but everything. I’ve seen that fix weird issues with other OpenAI tools.
Also, the Caddy proxy might be doing something funky with headers that OpenAI doesn’t like. Try bypassing it temporarily to see if the tools stay visible.
If this keeps happening, OpenAI might have rate limits or session limits on MCP tools. Does it happen when you have only one tool loaded? Might be worth testing that first.
Hi, thanks for sharing your experience. Your observations are very close to what I am seeing with ChatGPT custom MCP tools.
I want to share some additional findings from my side.
The symptom is:
The MCP loads successfully at first.
The tools are visible and callable.
After some time or after additional conversation turns, the MCP tools disappear from the session.
When this happens, the MCP server does not receive any request at all.
This last point is important because it suggests the failure happens before the request reaches the MCP backend.
Some things I have already tested:
The MCP server itself appears healthy.
The HTTPS endpoint and reverse proxy are working.
Server-side logs do not show failed tool calls when the tools disappear.
Creating a new MCP app with a different name can temporarily restore the tools.
The old MCP app may later lose tool visibility again.
This makes me suspect the issue may be related to ChatGPT MCP app state, tool registry cache, session attachment, or tool injection rather than the MCP implementation itself.
I also noticed that the problem seems more likely when multiple MCPs are attached in the same environment.
Regarding the complexity possibility:
My main MCP currently exposes around 31 tools. The tools are statically defined through the MCP tools/list response, not dynamically generated.
The tool surface includes multiple categories:
runtime state reading
recovery snapshots
verification/evaluation
repository analysis
construction-related operations
The MCP manifest is therefore much larger than a simple MCP with only a few tools.
I am currently testing whether a minimal MCP with only a few read-only tools remains stable. This should help determine whether the issue is caused by:
session/tool attachment instability;
tool manifest size or schema complexity;
multiple MCP loading interactions.
I am curious whether there are any known limits or edge cases around:
maximum MCP tool count;
tool manifest/schema size;
tool attachment refresh;
session cache invalidation;
multiple MCP apps loaded in one conversation.
Also, I agree the point about creating a new MCP name temporarily fixing the issue is interesting. In my case it looks less like a backend failure and more like some state associated with the MCP app/tool identity.
Thanks again for sharing your experience. Your comments helped narrow down the possible causes.
One thing worth checking is the total size of your MCP tool manifest, rather than just the number of tools.
With our MCP server, we’ve encountered what appears to be a practical manifest size limit of approximately 100 KB in ChatGPT Desktop. This includes the tool definitions returned by tools/list, such as descriptions and parameter schemas. A server exposing 31 tools could still have a large manifest if those definitions are detailed.
We maintain a separate Compact manifest specifically for ChatGPT because of this constraint. We haven’t encountered the same limitation using our larger manifest with Codex or Claude Code.
The approximately 100 KB figure is based on our observed behavior; I haven’t found an officially documented OpenAI limit. Also, this may not fully explain your tools loading successfully and then disappearing later—there could be a separate session or tool-registration issue.
It would be helpful if OpenAI could clarify:
Is there a maximum size for the complete tools/list manifest accepted by ChatGPT?
Is there a separate per-conversation budget that can cause already-loaded tools to disappear?
Are these limits different between ChatGPT Desktop and Codex?
Your planned test with a smaller manifest seems worthwhile. Measuring the serialized JSON size alongside the tool count would help make the comparison more useful.