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. Reported as the first official UI extension to the Model Context Protocol — with cross-vendor backing and day-one partners — 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.

MCP Apps turn assistants from text terminals into UI platforms — a big deal for what tools can do, and a reminder that every new capability surface is a new trust boundary. The pattern here is the reassuring part: it's the same sandbox-and-mediate model browsers have used for embedded content for years, ported to the AI-assistant context. Nothing exotic, which is exactly why it's trustworthy.

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.