MCP
apps.

An MCP server gives a model tools and data. An MCP App adds the missing layer: a rendered, interactive UI the human sees and clicks, displayed by the host assistant. Proposed on November 21, 2025 as SEP-1865, written by MCP core maintainers at Anthropic and OpenAI together with the creators of the community MCP-UI project, and launched as an official MCP extension on January 26, 2026, it lets a tool return a control panel instead of a paragraph.

That's a genuine capability jump, and a genuine trust problem. The UI is third-party code you didn't write, running inside an app that holds the user's conversation, credentials, and context. You can't just drop it into the page. Everything about how MCP Apps are built is shaped by that one fact — the UI is untrusted, and the host is not.

MCP App UIs render in a sandboxed iframe. By construction, a sandboxed iframe cannot reach into the host page's DOM, read its storage, or make network calls on the host's behalf. It's isolated — a locked room. The only way anything gets in or out is a message channel the host explicitly wires up.

This is sandboxing applied to UI: assume the code inside is hostile, give it no ambient authority, and force every request through a single, inspectable channel. The isolation isn't a nice-to-have — it's the entire reason it's safe to render someone else's UI inside your assistant.

The door between iframe and host is postMessage, and the language spoken across it is JSON-RPC — the same structured request/response protocol MCP itself uses. The iframe posts a message naming a method and params with an id; the host posts back a response carrying the same id and either a result or an error.

Structured, typed, correlated by id. Nothing free-form crosses the boundary — just named method calls the host knows how to reason about.

Using a real RPC protocol rather than ad-hoc messages is what makes the boundary auditable. The host isn't parsing arbitrary strings from untrusted code; it's receiving discrete, named requests it can accept or reject one at a time.

Here's where the security actually lives. The host doesn't execute whatever the iframe asks — it checks each method against an allowlist of capabilities it has chosen to expose. Method on the list? Execute and return a result. Method not on the list? Return an error and do nothing. The iframe cannot reach a capability the host didn't deliberately hand it, because the sandbox gives it no other path.

Least privilege at the UI boundary: the app gets exactly the capabilities the host exposes, and a request for anything else — including host internals — is refused by default.

The runnable host below is that mediator: it round-trips an allowlisted call, refuses everything else with a structured error, and shows that even a host-internal method name can't be reached through the bridge.

An MCP App is two registrations on an ordinary MCP server, tied together by one URI. The tool does the work and points at its UI through _meta.ui.resourceUri. The resource serves the UI itself: one HTML document at a ui:// URI, with the MIME type text/html;profile=mcp-app. Here is the shape of the official quickstart, using the @modelcontextprotocol/ext-apps SDK:

Server side, condensed from the ext-apps quickstart. html is the View, bundled into a single file (the quickstart uses Vite with a single-file plugin).

The View is a plain web page. It creates an App, registers its handlers and connects. app.connect() runs the handshake described in the next section, and callServerTool sends a tools/call through the host.

If the View needs the network, the resource says so in its own metadata, _meta.ui.csp: connectDomains for fetch and WebSocket origins, resourceDomains for scripts, styles, images and fonts, and frameDomains for nested iframes. The host builds the iframe's Content-Security-Policy from those lists and, in the spec's words, "MUST NOT allow undeclared domains." Declare nothing and you get the restrictive default, which includes connect-src 'none': the View can't call out at all. Declaring domains up front also lets the host warn the user, and log, where a UI can reach before it renders.

The bridge example above and the runnable below use a stand-in method, getWeather. On the wire, the View (the spec's name for the app's iframe) speaks a small, fixed vocabulary: a set of ui/ methods plus a few standard MCP messages. Here is one render, in order, per the 2026-01-26 specification:

Two details carry the security model. First, on a web host the View never shares an origin with the host. The host renders a sandbox proxy on a different origin, which signals ui/notifications/sandbox-proxy-ready, receives the HTML in ui/notifications/sandbox-resource-ready, and loads it in an inner iframe under the declared CSP. Second, this page's "allowlist" has a concrete form: a tool's visibility, which defaults to ["model", "app"], decides who may call it. A tool marked ["app"] never appears in the model's tool list, and one marked ["model"] can't be called from the View. On top of that, the spec lets hosts require explicit user approval for UI-initiated tool calls.

MCP Apps went live as an official extension on January 26, 2026, with support in Claude (web and desktop), Goose and VS Code Insiders, and ChatGPT starting that week. It unified two earlier approaches: the community MCP-UI project, whose adopters included Postman, Hugging Face, Shopify, Goose and ElevenLabs, and OpenAI's Apps SDK, which already used MCP as its backbone. One server can now ship one UI to every host that negotiates the extension (io.modelcontextprotocol/ui), and a host that doesn't support it still gets a working, text-only tool.

It also sharpens the map of the MCP world. The MCP server is the capability backend; the MCP App is the interactive frontend; and the untrusted-component discipline from agent supply-chain security applies to both — an app you install is another dependency whose blast radius the host's allowlist is there to bound.