ext-apps

We build an OCD treatment program (Conicia) and ship an MCP app: swipeable lesson cards patients work through inside the chat, with a conversational layer around them (the assistant discusses the material, and a guardrail routes compulsive reassurance-seeking to in-the-moment tools). Inline rendering breaks the core loop. The patient reads a card, asks the assistant a question, and after two exchanges the deck has scrolled off-screen. Re-invoking the tool stacks duplicate decks. Clinically, the conversation around the material is the entire reason to host lessons in chat, so "either chat or view the app, not both" defeats the point. What we have tried: Stable view identity: returning a constant in on repeat tool calls, hoping hosts route the result to the existing view rather than instantiating a new one. Host behavior appears to be per-call instantiation regardless. `requestDisplayMode("fullscreen")": works where supported, but fullscreen suspends the conversation, which is the opposite of the goal. The ask: host support for the persistent/pinned direction the spec already gestures at (pip), or letting app views open in the persistent side panel some hosts already have for their own artifacts. A view that stays put while the transcript scrolls would fix this class of problem completely, for us and for any app whose view is a workspace rather than a one-shot result (maps, dashboards, documents). Happy to be a design partner or demo the clinical use case. Conicia (https://conicia.com)

Summary Every example app that calls hardcodes a literal tool-name string (e.g. ) instead of resolving it from . This works fine when a client connects directly to a single MCP server, but breaks under any MCP host/proxy that aggregates multiple servers behind one session and qualifies tool names to avoid collisions (e.g. instead of ). In that situation the tool that rendered the widget is reachable under its qualified name, but the widget's own calls go out under the original bare name and fail to resolve — "tool not found" — even though the widget itself loaded and displayed correctly. This is easy to miss because it never surfaces when testing a server standalone (1:1 with a client), which is presumably how these examples are normally exercised. It only shows up once a server is aggregated behind a multi-server hub/router. Reproduction Run any affected example (e.g. ) behind an MCP aggregator that qualifies tool names for multi-server sessions (we hit this with mcphub, which qualifies names as whenever a named route has 2+ connected servers). The entry tool ( → ) is called correctly by the host and the widget renders. But any follow-up interaction that goes through the widget's own — paging, saving, polling — fails, because the widget calls the literal string //etc., which doesn't exist under that name in the aggregated session; only etc. do. Fix already exposes the actual, host-rewritten name of the tool that invoked the widget. A widget can recover whatever prefix the host applied and reapply it to any tool it calls back with, e.g.: falling back to the bare name on hosts that don't rewrite names at all. This is a small, self-contained change per example and doesn't require any protocol/SDK change — is already available. Affected examples Checked every example under for usage. 15 hardcode bare names: — — — — — — — — — — — , , — — — , — , , , , , Not affected: plumbs through as an unused prop (no live call site in the example). , , , , , , , are render-once and never call back to the server, so the pattern doesn't apply. Why this matters beyond the 15 The examples are the templates most third-party MCP App authors will fork from first. Fixing the pattern there — even as a small shared helper documented once — sets the right precedent going forward, on top of fixing the specific interactive examples (, , , , etc.) directly.

Summary document the MCP 2026-07-28 request-scoped UI capability under on every request preserve the MCP 2025-11-25 compatibility example for earlier protocol versions distinguish client-to-server capability advertisement from the View-to-Host handshake and its layer update server guidance to evaluate capabilities per request and degrade gracefully when UI support is absent Validation (373 passed, 2 skipped) (pre-commit hook) parsed the added JSON examples successfully verified the linked MCP 2026-07-28 metadata page returns HTTP 200 Fixes #742