MCP App context updates not received in ChatGPT

ChatGPT Apps SDK
1

I have an MCP server + MCP App tool where the UI renders correctly in ChatGPT web and sizing works, but context information sent from the UI to the model is not applied.
The same implementation works as expected in Claude web, following the MCP Apps spec.

Is this a known limitation or compatibility gap in ChatGPT’s MCP Apps support, or could I be missing a required extension (e.g. widget state / model-context updates)?

4

I had similar issues and it could be, in your case, that your tool call result hits the “per tool call token limit” in ChatGPT and is silently drop. Yes. :-1:
In my case ChatGPT wasn’t even silent, it blamed our server that it would not be reachable, which wasn’t true.

Claude has a much much larger per tool call token limit, that’s why it probably works in Claude.
In the end I had to refactor the tools to be more atomic, which on the flip side comes with idempotency problems and still does not work that well with ChatGPT tbh.

I would like to see two things from OpenAI:

  1. Do not cancel tool calls without meaningful error.
  2. Increase the per tool call token limit.
5

I am seeing the same class of behavior in a current MCP app, and in my case it does not look like a per-tool-call token limit issue.

The app is a reader widget where the user selects a phrase/ayah and then asks a natural follow-up like “what does this mean?” or “is this thunder or lightning?” The iframe sends a tiny model context update with the active selection. DevTools shows the outbound `ui/update-model-context` message and the host ACKs it with `{}`. The payload is very small: one instruction sentence plus the selected phrase/reference. It is not a large tool result.

Observed pattern:

  • full page reload or a fresh conversation often makes the first context ask work;
  • sometimes the second context ask works;
  • later updates become flaky: the model says it cannot see the current selection, answers from stale context, or uses an older page/selection;
  • Android ChatGPT is much more reliable in my testing;
  • ChatGPT web, macOS desktop, and Windows desktop are the problematic surfaces.

We also tightened the app-side ownership model to rule out common bugs: passive viewport updates no longer overwrite explicit selections, adjacent rendered pages publish their own page data, and the model-facing context has been reduced to selection-first plain text. The app-side trace still shows the correct latest context being published when the model fails to use it.

So I think there are at least two separate failure modes being discussed in these threads:

  1. tool result / token-limit truncation, which should produce a clear host error instead of a misleading model response;
  2. `ui/update-model-context` / widget state being ACKed by the host but not reliably attached to the next model turn, especially after live iframe initialization or across repeated context updates.

The second one is the blocker for us. The app can prove the outbound update and ACK, but there does not appear to be any supported way to inspect what model context ChatGPT actually stored or attached after the ACK.

6

Thanks for sharing the detailed report. We’re investigating this reports where a context update is acknowledged, but the next model turn can still receive older or missing context. In the meantime, the most reliable workaround is to include the current selection directly in the follow-up message, or have the next tool call retrieve the latest selection from your backend rather than relying on ui/update-model-context alone.

We don’t have a timeline to share yet, but this is on the team’s radar. Thanks again for taking the time to document it.