We can independently confirm the same regression using our locally installed, unpublished MCP plugin, SkillPilot Coach v1.
Our flow performs two stateless MCP tool calls within a single assistant turn:
-
get_skillpilot_context— no UI metadata -
render_skillpilot_goal_visualization— includes_meta.ui.resourceUri
On August 3, 2026, our server recorded both calls completing successfully:
08:57:59 UTC get_skillpilot_context success
08:58:07 UTC render_skillpilot_goal_visualization success
In the native ChatGPT mobile app, the widget then remained indefinitely on ChatGPT’s loading skeleton. No subsequent resources/read request reached our MCP server.
The same local plugin and visualization render correctly in ChatGPT Web, including in a mobile browser. The ordinary textual response also remains usable in the native app.
This is therefore another independent instance of the sequence described in the original report:
non-UI tool → UI-linked render tool within the same assistant turn
One caveat: the absence of an origin-side resources/read request does not establish exactly where resolution stopped. OpenAI-side caching or a failure before MCP dispatch remain possible.
Two related questions:
-
Is there a supported client-capability signal that an MCP plugin can use to avoid this chained UI call on affected native clients?
-
Is there a documented way to ensure that the host removes an unresolved widget shell and cleanly preserves the complete textual fallback?
The robust failure mode should be either to render the widget or to fall back to text without leaving an indefinite host-owned loading skeleton.