My custom MCP connector is connected and oauthed in, in developer mode. The tool definitions are all visible and everything looks good.
When I attach the connector/App in a chat, and try to invoke it, this is what I get
“I can do that, but I need to invoke the ******* connector’s ****_**** tool. That tool isn’t available to me as a callable function in this chat despite its definition being shown in the prompt, so I can’t actually execute it from here.”
This is literally breaking my MCP entirely.
What I’ve done
- Lower the tool definitions to be more concise and consume lesser tokens. They’re well below the maximum recommended limit of 5k tokens.
- Disconnected and reconnected the MCP.
- Tried using another official app like Notion/Canva (they work fine)\
- Try the prompt with and without the connector/MCP in the chat.
Please help me out here.
UPDATE 1
It works for every new chat where the connector IS NOT attached. And then fails after the tool is invoked 2-3 times. Quite literally looses the ability to invoke the connector.
“Earlier in this conversation I was able to call ****_****, but now only the tool descriptions are available—the runtime isn’t exposing an executable ***** tool”
UPDATE 2
There is no consistency or determinism here. Some of the tools are visible, some aren’t. They work on and off! The ones that work also, have their response truncated for some reason.
The detail that points away from auth/connection is your Update 1: fresh chats work, then it dies after 2-3 invocations, and Update 2 says responses are getting truncated. If OAuth or the connector registration were actually broken it would fail from the very first call, not degrade. That degradation curve plus truncation is what context pressure looks like: the runtime keeps the cheap tool descriptions in the prompt (so the model still “sees” them) but stops registering the callable functions once the conversation is near the budget. From the model’s side that reads exactly as “the definition is shown but it isn’t a callable tool.”
The usual driver is large MCP tool results. A couple of fat tool responses fill the window, and after that the runtime drops executable tools to make room. So before touching the connector again, I’d cap and paginate the server’s outputs: return a short structured summary plus an id/cursor to fetch detail on request, instead of the full payload.
Quick way to confirm it’s context and not a per-connector bug: new chat, make the very first tool call return a deliberately huge result. If invocation breaks immediately instead of after 2-3 calls, it’s window pressure, not your OAuth or tool schema.
Suffering from this as well - Some ChatGPT App Store users lose access to exposed MCP tools after one tool call
I cut down our tool manifest and stripped down the first tool call response significantly (~300 output tokens) with no improvement in behavior.
@iamkishank Welcome to the forum!
First, I do not use MCP myself, so please treat this as a helpful pointer rather than a confirmed diagnosis.
I suspect that some of the MCP and authorization code may be shared across OpenAI tooling, including Codex. I mention Codex because it has a public GitHub repository with an active issues list.
After having ChatGPT search the Codex issues, it identified this possibly related issue:
opened 06:41PM - 05 Jun 26 UTC
bug windows-os mcp app
### What version of the Codex App are you using (From “About Codex” dialog)? Ve…
That issue, along with related issues linked from it, may offer additional insight, workarounds, or possible resolutions.
If that issue matches your problem, consider adding a 
reaction on the GitHub issue page itself, not just on the forum topic. GitHub reactions can help developers gauge impact and prioritize work.
If it is not the same issue, try searching the existing GitHub issues for a closer match.