Remote MCP app tools silently dropped from a conversation's tool manifest in long/old chats (model can name them but cannot call them)

ChatGPT Apps SDK
1

Summary

A custom Remote MCP server (connected as a ChatGPT app via Developer Mode; OAuth 2.1 + DCR + PKCE) works fine in fresh conversations, but in long-lived or older conversations — including threads inside a Project — its tools stop being exposed to the model for that conversation. The model can name the tools but can’t call them, and no request reaches our server. A new chat restores everything. Is this expected, and is there a way to detect or recover from it?

Symptom (reproducible, same account, app connected)

  • Fresh conversation: the model calls the tools, our server logs the authenticated POST /mcp and returns 200. Works.
  • Long/old conversation: the model says the tools are “not exposed as tools in this specific thread” and lists names it can’t call. Our server logs show zero inbound requests — the call never leaves ChatGPT.
  • In very saturated threads the model sometimes fabricates a plausible tool result from context instead of saying it can’t reach the tool. Editing earlier messages can stop the fabrication but does not restore tool access.
  • Starting a new conversation (even inside the same Project) immediately restores the tools.

Ruled out

  • Not a server bug — verified via logs (no inbound request); the tools simply aren’t in the model’s manifest for that conversation.
  • Not Project membership — a fresh thread inside the same Project works.
  • Not OAuth/expiry — the app stays connected; fresh threads on the same account work the same minute.

The common variable looks like conversation length / age / context compression.

Questions

  1. Is this known/expected — does ChatGPT stop injecting a connected MCP app’s tool manifest once a conversation grows long, is summarized, or reaches some age?
  2. What’s the actual trigger (context-length threshold, summarization dropping connector state, thread created before the app was added, a per-conversation tool cap, anything Projects-specific)?
  3. Any supported way to re-attach/refresh the connector within an existing conversation, short of a new chat?
  4. Does a published/verified app behave differently from Developer Mode here?
  5. Is there a per-conversation tool-manifest size budget — does a smaller tools/list survive longer?
  6. Is there any signal (server- or client-side) a developer can use to detect that the tools were dropped for a conversation, so we can fail safe instead of risking a fabricated result?

Environment: ChatGPT web + macOS app

Thanks! /Andreas :victory_hand:

2

:coffin: Update after a few more days of testing: still reproducing, with one new wrinkle

Still seeing the original behavior consistently: in long/old conversations the
connected MCP app’s tools drop out of the manifest, the model says they’re “not
available in this thread,” and our server logs show zero inbound requests for
those turns. A brand-new conversation (same account, same app, even inside the same
Project) restores them instantly. The common variable still looks like conversation
length / age / context compression.

:eyes: one new observation that may help narrow it down: it doesn’t look like a clean
on/off.

  • In some long threads the model still lists the MCP tool among its available
    tools but won’t call it for the relevant command, and instead fabricates a
    plausible result from context. Explicitly asking the model to “inspect / open the
    schema” for that tool makes it start calling the real tool again in the same
    thread. So a tool descriptor can be present without being callable until it’s
    re-hydrated.
  • A standing instruction (“only state a tool result if you actually called the tool
    this turn; otherwise say it’s unavailable”) reliably converts the silent
    fabrication into an honest “tool not available in this thread,” but it does NOT
    restore tool access. Editing earlier messages behaves the same way.

new questions:

  1. Is there a documented context-length or summarization threshold at which a
    connected MCP app’s tool manifest is dropped from a conversation?
  2. Is the “listed but not callable until asked to inspect the schema” case a
    distinct state (lazy schema hydration) from the full manifest drop?
  3. Is there any client-side signal an MCP app can read to detect that its tools were
    dropped from a given conversation, so it can warn the user instead of letting the
    model silently fabricate?
  4. Does publishing the app (out of Developer Mode) change any of this?

Has anyone on the Apps SDK / MCP side seen this, or found a detection/recovery path?

Over and out :victory_hand:

3

facing this exact issue. please let me know if you found a solution. looks like OpenAI really wants Anthropic to win lol.