You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Environment: Claude iOS app (2026-07-30, Opus 5), remote MCP server via custom OAuth connector. Server: @modelcontextprotocol/ext-apps@1.7.5, @modelcontextprotocol/sdk@1.30.0, Streamable HTTP (stateless per-request). Tool registered with registerAppTool + _meta.ui.resourceUri; single-file HTML template with a version stamp in the footer so screenshots identify exactly which template version a host rendered.
Observed (4 instrumented live test rounds, template versions v1.2.0 → v1.4.0):
The ui:// template loads and renders — chrome, inputs, buttons, and our version stamp are all visible, so resource fetch + iframe mount work on iOS.
ui/notifications/tool-input is never delivered either — instrumented separately from v1.3.0 onward.
ui/notifications/size-changed from the app is ignored — the iframe stays at a short initial height, clipping content (and McpUiResourceMeta offers no initial-size hint, so servers have no workaround).
iframe-initiated tools/call via callServerTool also appears non-functional in our v1.4.0 polling fallback, though we have less instrumentation certainty here than for 2–4.
Impact: any tool-result-driven interactive UI is non-functional on Claude iOS — the card renders as permanent chrome with no data and no working actions. We shipped a full accept/regenerate image-review card and had to park it. The workaround that works everywhere is putting next-step instructions in the tool result text and letting the model execute follow-ups conversationally.
Expected: per SEP-1865, the host delivers tool lifecycle notifications to the view after ui/initialize completes.
Repro: any registerAppTool sample whose ontoolresult handler displays received data — on iOS the handler never fires, while the same server renders end-to-end in the basic-host harness and MCPJam. Happy to share our server URL, template source, and timestamped screenshots on request.
Environment: Claude iOS app (2026-07-30, Opus 5), remote MCP server via custom OAuth connector. Server:
@modelcontextprotocol/ext-apps@1.7.5,@modelcontextprotocol/sdk@1.30.0, Streamable HTTP (stateless per-request). Tool registered withregisterAppTool+_meta.ui.resourceUri; single-file HTML template with a version stamp in the footer so screenshots identify exactly which template version a host rendered.Observed (4 instrumented live test rounds, template versions v1.2.0 → v1.4.0):
ui://template loads and renders — chrome, inputs, buttons, and our version stamp are all visible, so resource fetch + iframe mount work on iOS.ui/notifications/tool-resultis never delivered. The app registersontoolresultbeforeconnect()per SDK guidance; the handler never fires. The same template receives it on Claude Desktop (when Desktop renders at all — see Bug Report: MCP Apps UI Resource Not Rendering in Claude Desktop / claude.ai #671).ui/notifications/tool-inputis never delivered either — instrumented separately from v1.3.0 onward.ui/notifications/size-changedfrom the app is ignored — the iframe stays at a short initial height, clipping content (andMcpUiResourceMetaoffers no initial-size hint, so servers have no workaround).tools/callviacallServerToolalso appears non-functional in our v1.4.0 polling fallback, though we have less instrumentation certainty here than for 2–4.Impact: any tool-result-driven interactive UI is non-functional on Claude iOS — the card renders as permanent chrome with no data and no working actions. We shipped a full accept/regenerate image-review card and had to park it. The workaround that works everywhere is putting next-step instructions in the tool result text and letting the model execute follow-ups conversationally.
Expected: per SEP-1865, the host delivers tool lifecycle notifications to the view after
ui/initializecompletes.Repro: any
registerAppToolsample whoseontoolresulthandler displays received data — on iOS the handler never fires, while the same server renders end-to-end in the basic-host harness and MCPJam. Happy to share our server URL, template source, and timestamped screenshots on request.