MCP Apps Explained (2026): The Interactive UI Standard for MCP

MCP Apps is an official extension to the Model Context Protocol that lets an MCP server hand a host a real, interactive interface instead of just text, a chart, a form, a map, a design canvas, rendered inline inside the conversation. The spec reached stable status on January 26, 2026, and it already runs in Claude, ChatGPT, VS Code, Goose, and Postman. If you already know what MCP is, this is the extension that answers the question MCP never tried to: what happens when a tool result needs to be seen, not just read.

Why base MCP wasn't enough

MCP's three primitives, tools, resources, and prompts, all assume the model is the audience. A tool returns JSON. A resource returns text or a file. That's fine for "look up this record" or "run this query." It falls apart the moment a human needs to look at a chart, drag a slider, pick a date on a calendar, or watch a 3D scene update in real time. Before MCP Apps, every host that wanted rich UI inside a tool call had to invent its own approach. OpenAI shipped one path with its Apps SDK in November 2025. The open source MCP-UI project, built by Ido Salomon and Liad Yosef, shipped a different one starting even earlier, with contributions and adoption from Postman, HuggingFace, Shopify, Goose, and ElevenLabs. Two incompatible patterns for the same problem meant a developer building a UI-backed tool had to pick a side, or maintain both.

MCP Apps is the merge. It formalizes the SEP process, SEP-1865, and folds the ideas from both MCP-UI and OpenAI's Apps SDK into one extension that any compliant host can implement.

Who actually built this

The spec's author list is the tell that this isn't a single-vendor initiative: Ido Salomon, Liad Yosef, Olivier Chafik, Jerome Swannack, Jonathan Hefner, Anton Pidkuiko, Nick Cooper, Bryan Ashley, and Alexi Christakis, nine co-authors spanning the MCP-UI project and engineers working across the host ecosystem. The proposal text is explicit that it draws on two real, separately-built systems: MCP-UI's bidirectional communication model and its HTML, external-URL, and remote-DOM content types, and OpenAI's Apps SDK, which had already proven the demand for rich UI inside ChatGPT. Rather than one company dictating the design, the SEP unifies what two different camps had already shipped. It lives under the modelcontextprotocol GitHub org, the same steering process that governs base MCP, not as a side project.

The mechanism: ui:// resources, not a new wire format

MCP Apps doesn't invent a new protocol. It's an optional, negotiated extension (io.modelcontextprotocol/ui) layered on MCP's existing resource and tool primitives. The pieces:

UI resources use a dedicated URI scheme. A server declares a resource like ui://weather-server/dashboard-template with a MIME type of text/html;profile=mcp-app. That resource is the HTML your interface actually runs.

Tools link to their UI through metadata. A tool's definition carries a _meta.ui.resourceUri field pointing at the UI resource it wants rendered. When the model calls that tool, the host knows exactly which interface to load alongside the result.

The host renders the UI in a sandboxed iframe. This is the part that made the spec take longer than a weekend hack: every UI resource ships with declared Content Security Policy scope (which external domains it can fetch from, load images or scripts from, or embed as nested iframes) and requested sandbox permissions (camera, microphone, and similar). The host enforces those declarations. A tool author can't silently reach out to arbitrary domains from inside the rendered UI.

Communication runs both ways over MCP's own JSON-RPC. The host pushes tool data into the UI, and the UI can call other tools through the host, all over the same protocol base MCP already defined. There's no separate transport to stand up.

If you've built or reviewed an MCP server before, none of this requires learning a new protocol. It requires learning one more resource type and one more metadata field.

Spec maturity: stable, with an active draft ahead of it

The 2026-01-26 version of the spec is marked Stable in the official repository. There's also a draft version actively under development for the next iteration, so treat the current spec as a solid foundation, not a finished, closed document. The initial release deliberately scopes itself to one content type, HTML resources, with the SEP text explicitly noting a path for future content types later. If you're building against this today, build against the Stable 2026-01-26 spec and watch the draft branch for what's coming, don't build against draft.

Host support: what's real right now

This is the part worth checking carefully, because "supported" gets thrown around loosely in this space. As of this writing, the official spec repository links to live, working documentation for MCP Apps support in:

• Claude, via Anthropic's connector docs
• ChatGPT, via OpenAI's Apps SDK documentation
• VS Code, announced and shipped in a January 26, 2026 engineering blog post
• Goose, Block's open source agent, with a full tutorial
• Postman, in its MCP request tooling
• MCPJam and mcp-use's inspector, both developer-tooling clients built around testing MCP servers
• Alpic's playground

None of those are placeholder pages. Every one of those links resolves to real documentation with working setup steps, not a roadmap slide. That's a meaningfully wider real footprint than most week-old specs get, largely because the spec formalizes work hosts like Postman and Goose were already shipping through MCP-UI before the SEP existed.

What the spec repo does not ship is a production host implementation of its own. The examples/basic-host folder in the official repo is explicitly a reference example for local testing, not something meant to run in production. If you need a drop-in client SDK today, the MCP-UI project's packages implement the full standard and are already used by several of the hosts above; you can use those or write your own host-side rendering logic against the spec directly.

How you'd actually build an MCP App

The fastest path, per the official repo, is to skip writing boilerplate by hand and use the Agent Skills the project ships: create-mcp-app scaffolds a new server with a UI from nothing, add-app-to-server bolts a UI onto tools you already have, convert-web-app turns an existing web app into a hybrid, and migrate-oai-app moves an OpenAI Apps SDK integration onto the open standard. In Claude Code, installing them is two commands:

/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps

Doing it by hand instead, the shape of the work is:

1. Install the SDK: npm install -S @modelcontextprotocol/ext-apps. There are separate entry points for building the interactive view itself, for React projects specifically, for the host side (app-bridge), and for server-side tool registration.
2. Write the interface as an HTML resource. The official examples cover a real spread: a 3D globe viewer, a Three.js scene renderer, an interactive PDF viewer, a QR code generator, a budget allocator, a customer segmentation scatter plot. Starter templates exist for React, Vue, Svelte, Preact, Solid, and vanilla JS, so the framework choice is yours, not the spec's.
3. Register the resource under a ui:// URI on your MCP server, and point the relevant tool's _meta.ui.resourceUri at it.
4. Declare your CSP scope and any sandbox permissions the UI genuinely needs. Leaving these empty is the secure default and the spec treats it that way; only widen them if the UI actually calls out to an external API or needs camera or microphone access.
5. Test locally against the repo's basic-host example, or against a real client like Claude Desktop or VS Code, using the standard stdio server pattern any MCP client already supports.

For a Postgres dashboard, a scenario modeler, or an internal ops tool where a chart or a form genuinely beats a wall of text, this is a real, buildable feature today, not a future roadmap item.

Trade-offs to know before you commit

Extension negotiation is required, not automatic. A client and server both have to explicitly support and negotiate the io.modelcontextprotocol/ui extension. A tool that returns a UI resource to a host that doesn't understand MCP Apps just won't render it; the fallback behavior is on the host to define.

The content type is narrow by design. Version 2026-01-26 covers HTML resources only. If your use case needs something the DOM can't easily express, you're either shipping it as HTML with a canvas or WebGL context, or waiting for a future content type.

There's no first-party production host SDK from the core spec repo. You're either adopting MCP-UI's client implementation or building your own host-side rendering and security enforcement, which is real work if you're building a host rather than a server.

If you were on OpenAI's Apps SDK before this standardized, migrating means adapting to the ui:// resource pattern and the _meta.ui metadata field rather than whatever proprietary hooks the Apps SDK used. The migrate-oai-app skill exists specifically because that migration wasn't assumed to be trivial.

Why this matters if you're building agent products

MCP already killed the case for bespoke tool integrations. MCP Apps closes the next gap: the case for bespoke UI-per-host. Before this, a server that wanted a chart in Claude and the same chart in ChatGPT needed two different UI integrations. Now, one HTML resource, declared once with the right CSP and permissions, can render in either host, and in VS Code, Goose, and Postman besides. For anyone scoping an agent build where users need to look at something, that portability is the whole argument for building on the standard instead of a host-specific SDK.

AY Automate builds MCP servers and Claude Code integrations for teams that need agents to do real work, past the point of answering questions. If you're scoping a tool that needs a chart, a form, or a dashboard rendered inside an agent conversation, book a consultation and we'll walk through whether MCP Apps fits your build, and how it slots into the rest of your MCP server architecture.

FAQ

What is MCP Apps in one sentence? MCP Apps is an official, stable extension to the Model Context Protocol that lets MCP servers attach interactive HTML interfaces to tool calls, so a host can render a chart, form, or dashboard inline instead of returning plain text.

Is MCP Apps backed by both Anthropic and OpenAI? Not as a formal two-company partnership. It's a community-driven SEP (SEP-1865) with nine listed authors spanning the MCP-UI project and engineers across the host ecosystem, and it's governed under the same modelcontextprotocol organization that runs base MCP. The design explicitly merges two things that already existed separately: the MCP-UI project's bidirectional communication model, and OpenAI's Apps SDK, launched in November 2025, which validated the same demand from ChatGPT's side. Both are credited as direct influences in the spec text, but neither company issued a joint standard on its own.

Is MCP Apps a different protocol from MCP? No. It's an optional extension identified as io.modelcontextprotocol/ui, negotiated between client and server, built entirely on MCP's existing resource and tool primitives and its JSON-RPC message base. You don't need a new transport or a new client to support it.

Which hosts actually support MCP Apps today? Claude, ChatGPT, VS Code, Goose, and Postman all have live, working documentation for it as of this writing, along with developer tools like MCPJam and mcp-use's inspector. Support varies by host, so check the specific host's documentation before assuming a given feature works everywhere.

Is the spec finished, or still changing? The 2026-01-26 version is marked Stable, and it's what you should build against. A separate draft version is under active development for the next release, which is normal for a spec less than a year old. The initial version deliberately covers HTML resources only, with room for other content types later.

Do I need MCP-UI's SDK to build an MCP App? No, but it's the most complete option right now. The official spec repo ships the core SDK for building views and registering server-side resources, but no full production host implementation. MCP-UI's client packages implement the full standard and are already used by several real hosts, so most teams building a host, rather than just a server, start there instead of writing rendering and security enforcement from scratch.

How is this different from just returning a link to a web app? A link opens a new tab and breaks the conversation. An MCP App renders inside the same conversation, in a sandboxed iframe with a CSP the server itself declares, and it can exchange data with the host and call other tools live, all without the user leaving the chat.