What Does MCP Apps Actually Add to the Protocol?

MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces directly into Claude, ChatGPT, and VS Code. Here's what it really changes-and the catch nobody mentions.

Cover art for What Does MCP Apps Actually Add to the Protocol?

MCP Apps (SEP-1865) was proposed on November 21, 2025 and shipped as the first official MCP extension on January 26, 2026. Three days ago, it landed formally in the 2026-07-28 MCP specification release candidate-the largest revision of the protocol since launch. If you build on MCP or are evaluating it for a team, this is the part of the spec update worth understanding in depth.

The core idea is simple but the implications are not: your MCP server can now ship its own interface, not just its data.

What MCP Apps actually does

Before SEP-1865, an MCP server returned raw data-JSON or plain text-and left it to the LLM to summarize and present. Regular MCP servers return raw data for the LLM to parse and summarize; MCP Apps return structured UI definitions alongside the data, allowing the AI client to render interactive dashboards, forms, and graphs natively in the chat.

The mechanism is deliberately minimal. A tool declares a UI resource via _meta.ui.resourceUri pointing at a ui:// resource; the host fetches it, renders it in a sandboxed iframe, and brokers bidirectional communication over JSON-RPC via postMessage. The MVP content type is text/html;profile=mcp-app.

The security design is worth pausing on. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call. That last part matters: a user clicking a button in an MCP App is not bypassing the tool-call review loop. The host still brokers every action.

Where it comes from and who's already using it

The community mcp-ui project (created by Ido Salomon and Liad Yosef) was the proving ground; as of January 26, 2026 its patterns became the first official MCP extension, MCP Apps (SEP-1865), co-authored by Anthropic and OpenAI.

MCP-UI's adopters, including hosts and providers such as Postman, HuggingFace, Shopify, Goose, and ElevenLabs, provided critical insights and contributions to the community. OpenAI's Apps SDK, launched in November 2025, further validated the demand for rich UI experiences within conversational AI interfaces.

ChatGPT (OpenAI Apps SDK), Claude, VS Code Copilot, and Block's Goose all render MCP Apps; in the open ecosystem LibreChat already renders legacy mcp-ui resources.

Jan 26, 2026first official MCP extension shippedMCP Apps (SEP-1865)
~2,000servers in the MCP Registryas of November 2025 anniversary post
9launch partnersrendering MCP Apps in Claude at launch
800Mweekly active userson ChatGPT, which now distributes MCP Apps

The hosted vs. self-hosted split-the part most coverage skips

Here is the non-obvious tension in how MCP Apps actually rolls out. On hosted platforms and self-hosted deployments, the spec is identical. The economics and control are not.

The hosted ecosystem is a gatekept distribution channel. ChatGPT Apps reach 800 million weekly active users but require app review, have geographic restrictions, and limited monetization. Claude renders MCP Apps with nine launch partners.

In hosted clients the platform controls rendering, review, and distribution; self-hosted, you own the renderer, the sandbox policy, and the distribution.

This is essentially a two-tier reality. If your team runs a self-hosted MCP client-VS Code with a private server, or something like Goose pointed at your internal tooling-you get the full spec with no gatekeeping. If you want to publish an MCP App to ChatGPT's user base, you are in an app-store model. The protocol is open; the distribution channels are not.

That distinction matters for teams evaluating MCP Apps for internal workplace tooling. A Beagle-style integration in Slack or Teams can wire up an MCP server to surface a dashboard inline without going through any platform review, because the host client is controlled by the team. The path to 800 million users is the slower, gated one.

Beagle in action#analytics, 11:02am
The ask
'can someone pull last week's support volume by category?'
Beagle drafts
calls the MCP server, which returns both the data and a ui:// chart resource; drafts a reply with the interactive breakdown inline
You approve
you hit approve; the chart renders in the thread with drill-down - no separate dashboard tab, no copy-paste
Do this in your workspace
Returning data from an MCP server
Without Beagle
server returns a JSON blob; LLM summarizes it into a plain-text paragraph the reader then has to interpret
With Beagle
server returns the same data plus a ui:// resource; host renders an interactive chart the user can filter directly in chat

What's genuinely new versus incremental

The honest answer is: the spec codifies what a community project already proved worked. The mcp-ui proof-of-concept had real adopters-Postman, Shopify, HuggingFace-before SEP-1865 was finalized. What the spec adds is interoperability guarantees and a security baseline that enterprise deployments can actually rely on.

The extension addresses the growing community need for rich, interactive experiences in MCP-enabled applications, maintaining security, auditability, and alignment with MCP's core architecture. The security-review-before-render requirement is new at the spec level; the community project handled it inconsistently.

Future additions on the table include external URL support, built-in state persistence, and View-to-View communication. Those are not in the RC. The 2026-07-28 specification ships the sandboxed HTML baseline and a clear extension path.

One concrete limitation worth knowing: as of mid-July 2026 the 2026-07-28 spec is a release candidate, with the current finalized version remaining 2025-11-25. The gap is a validation window for SDK maintainers and client implementers. If you are writing server code against the new spec today, plan for a lag before every client you care about ships support.

MCP Apps: common questions

What is MCP Apps (SEP-1865)?

MCP Apps is an official MCP extension, finalized January 26, 2026, that lets MCP servers deliver interactive HTML interfaces into compliant AI clients. Servers declare a ui:// resource alongside a tool; the host renders it in a sandboxed iframe. UI-triggered actions still go through MCP's standard JSON-RPC audit path, so no new unreviewed action surface is created.

Which AI clients support MCP Apps today?

As of 2026, the primary adopters include Claude Desktop, enterprise tiers of ChatGPT, and developer-focused environments like Cursor. Other platforms are rapidly building translation layers to support the SEP-1865 component schema within their own frontends. VS Code Copilot and Block's Goose also render MCP Apps.

Is MCP Apps the same as the OpenAI Apps SDK?

No, but it is related. MCP Apps (SEP-1865) is the standardized successor to mcp-ui and the OpenAI Apps SDK. Proposed November 21, 2025 and shipped as the first official MCP extension on January 26, 2026, it unifies two parallel efforts into one open spec under the identifier io.modelcontextprotocol/ui. The underlying patterns are shared; the spec is now the canonical version.

Does an MCP App bypass tool-call safety reviews?

No. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. UI-initiated actions go through the same JSON-RPC audit and consent path as a direct tool call, which keeps the security model intact.

Can any team run MCP Apps internally without platform approval?

Yes, if you control the host. Self-hosted clients-VS Code, Goose, or any client you deploy yourself-give you full control over the renderer and sandbox policy. Platform review only applies when you want distribution through hosted channels like the ChatGPT App store.

Keep reading