MCP Apps: UI enters the protocol, officially
The pitch
MCP was built to give an agent access to tools and data. It was never built to let a tool talk back with anything richer than text. If an MCP server wanted to show a chart, a form with dependent fields, or a live dashboard, the agent had to describe it in prose and hope the model reproduced something usable. MCP Apps closes that gap: it lets a server ship an actual interactive HTML interface, and the host renders it inline, in a sandboxed iframe, next to the conversation.
It's not a new idea — MCP-UI had been prototyping this pattern in the community for months, and OpenAI's Apps SDK shipped something similar for ChatGPT. What changed on July 28, 2026 is that MCP Apps stopped being a community extension and became one of the protocol's own first two official extensions, built by contributors from MCP-UI alongside engineers from both OpenAI and Anthropic. That's a different kind of commitment than a side repo: it means the UI story for MCP tools now has a stable, versioned home instead of three incompatible dialects.
How it actually works
The mechanics are deliberately boring, which is the point for something meant to run inside an agent's context.
A server predeclares its interface as a resource under a ui:// URI, tagged with the MIME type text/html;profile=mcp-app. A tool then points at that resource through a _meta.ui.resourceUri field, and a visibility array on the tool controls who can call it — "model" for tools the agent can invoke itself, "app" for tools reachable only from inside the rendered UI (a "load more" button, say, that shouldn't show up as something the model can call on its own). Because the UI template is declared ahead of the tool ever running, a host can prefetch it, cache it, and — this is the part every write-up on this leans on — review it for safety before any user has clicked a thing.
Rendering itself goes through a sandboxed iframe, and on web hosts specifically, through a double-iframe setup: an outer sandbox proxy that just forwards messages, and an inner iframe that actually runs the HTML under a content security policy scoped to whatever external domains the server declared upfront. Undeclared connections get blocked by default. Once the UI is live, it talks back to the host over the same JSON-RPC 2.0 wire format MCP already uses for everything else — the rendered view acts as an MCP client, the host acts as its server, and a ui/initialize handshake sets up the session. Every action the user takes inside that iframe — a form submit, a filter change — goes through the identical audit and consent path as a tool call the model made directly. There's no separate, quieter channel for UI-triggered actions to slip through on.
Eight months, three milestones
The extension moved fast by protocol standards. MCP-UI's original proposal landed in November 2025 as a way to standardize what several vendors were already building ad hoc. By January 26, 2026 it had a working spec and a real launch, with Claude supporting it on web and desktop, ChatGPT rolling it out the same week, and Goose — Block's open-source MCP client — already shipping it. VS Code had it in Insiders builds, and Microsoft, JetBrains, AWS, and Google DeepMind were all named as committed adopters. Then on July 28, 2026, it graduated again: MCP Apps became one of the two inaugural extensions under the protocol's new formal Extensions framework, the same release that made the MCP core itself stateless.
That's a fast climb from "community prototype" to "part of the spec," and it says something about where the pressure was coming from. Text-only tool output was the most-requested gap in MCP for most of 2025 — every serious client had already built its own bespoke UI workaround, which is exactly the situation a standard exists to end.
What it's actually squeezing
The tracker has flagged this dynamic before: if MCP Apps lands broadly, the boundary between the tool layer and the frontend layer gets blurry, and that's bad news specifically for protocols that only do the frontend seam. AG-UI exists to standardize agent-to-frontend communication as its whole job. If an MCP server can now ship its own UI directly, wired through the same JSON-RPC channel it already uses for tool calls, a chunk of what AG-UI is for starts looking like something MCP does natively, for free, to anyone already running an MCP client. AG-UI's counter is real integrations with frameworks that don't route through MCP at all — but the overlap is now concrete instead of theoretical, and MCP Apps didn't exist as a shipped extension the last time that comparison got made here.
The other framing worth having: MCP Apps and OpenAI's Apps SDK aren't really competitors anymore. MCP Apps was built with input from OpenAI engineers and explicitly designed to interoperate with the pattern Apps SDK already uses for ChatGPT. The interesting fork isn't MCP versus OpenAI on tool UI — that's converged. It's whether the open extension or the walled-garden app directory ends up being where most users actually encounter it.
The question nobody's fully answered yet
The spec's security model is real: sandboxed iframes, declared CSP domains, prefetch-and-review before execution, a shared audit path for UI-triggered actions. But a server's HTML is running inside the same client that holds your source code, terminal access, and every other connected MCP server — a materially different threat model than a browser tab, where you decide per-site what to trust. One security write-up on the new spec called this a trust inversion: on the open web you choose what to trust site by site, but with an MCP server, that decision already got made the day you ran mcp install. Sandboxing constrains what a malicious UI can reach; it doesn't change the fact that installing a server is now also installing whatever interface that server decides to render, and most people install MCP servers a lot more casually than they install browser extensions.
Nothing in the spec is careless about this — the fallback path (plain text for hosts that don't support the extension), the prefetch-and-review model, and the shared consent path are all real mitigations, not afterthoughts. But "sandboxed" has never meant "solved," and this is the first time MCP has asked hosts to run arbitrary third-party HTML rather than just arbitrary third-party function calls. Worth watching who audits their installed servers' UI resources and who just clicks through.
For the protocol's fuller July 28 changes — the move to a stateless core — see our earlier piece on that spec revision.