MCP Apps Spec 2026: Server-Rendered UI

TL;DR + 60-second decision tree

• Render UI when the user is the audience. Charts, dashboards, multi-field forms, approval surfaces, visual diffs, media, maps. The model has no business rephrasing a chart.
• Return text/JSON when the model is the audience. Single facts, code blocks the agent splices, lookup results that feed the next reasoning step. UI here is dead weight in the iframe.
• Return both when the result is structured but consequential. A deploy plan, a refactor diff, a shopping cart. Text for the model to reason over plus an iframe for the human to confirm.
• Don’t render UI when the agent is autonomous. A scheduled cron run with no human in the conversation has nothing to do with an iframe — and many hosts will simply drop it.

If you read nothing else, read this: UI is a downstream-of-product question, not a downstream-of-protocol question. The spec gives you a sandboxed iframe and a JSON-RPC bridge. What you do with it is a UX decision, and the cost of getting it wrong is paid in tokens, latency, accessibility, and broken agent loops.

What MCP Apps actually is

MCP Apps is officially “SEP-1865 — Interactive User Interfaces for MCP,” merged into the spec on November 21, 2025 and ratified as the dated specification 2026-01-26. The MCP team’s launch post describes it like this — verbatim:

“MCP Apps let tools return rich, interactive interfaces instead of plain text. The model stays in the loop, seeing what users do and responding accordingly, but the UI handles what text can’t.”

— Den Delimarsky, on the Model Context Protocol blog (2026-01-26)

The mechanism is small. A tool announces it has a UI by including a _meta.ui.resourceUri in its tool definition, pointing at a resource served under the new ui:// URI scheme. That resource has mimeType: text/html;profile=mcp-app and ships bundled HTML/JS. When the tool fires, the host fetches the UI resource, mounts it in a sandboxed iframe, and exchanges lifecycle events with it via JSON-RPC 2.0 over postMessage. That’s the whole architecture.

The Register, covering the launch, framed it bluntly: “Anthropic’s Claude can now present the interfaces of other applications within its chat window.” AWS engineer Clare Liguori told The Register that “MCP Apps address a real gap between what agentic tools can provide and how users naturally want to interact with them.” That “real gap” is the prompt for this entire post.

Two pieces of context every server author should pre-load before reading further. First, this is not the same problem as the underlying protocol — if you need that primer, our What is MCP post covers the JSON-RPC wire format these servers run on. Second, the MCP Apps decision is downstream of two other decisions you may have already made: which extension shape fits your tool (see our Claude Skills vs MCP vs Subagents vs CLI matrix) and how you’re managing tool-loading cost (see the MCP context bloat post). UI changes both of those calculations, and we’ll come back to it under failure modes.

The spec — fields and methods, verbatim

Everything in this section is from ext-apps/specification/2026-01-26/apps.mdx. Fields are quoted by name; behaviour is paraphrased only where the spec uses MUST/SHOULD language we’re preserving.

The new URI scheme and resource shape

• uri — must start with ui://
• mimeType — must be text/html;profile=mcp-app
• name — human-readable display name
• description — optional purpose description
• _meta.ui — container for UI-specific metadata

UI resource metadata (_meta.ui)

• csp: Content Security Policy with connectDomains, resourceDomains, frameDomains, baseUriDomains
• permissions: requested browser capabilities — camera, microphone, geolocation, clipboardWrite
• domain: optional dedicated sandbox origin
• prefersBorder: boolean visual-boundary preference

Tool-level metadata (also _meta.ui)

• resourceUri — references a UI resource by ui:// URI
• visibility — array controlling access scope: [“model”, “app”] or subsets

JSON-RPC methods, view → host

• ui/open-link — open external URL
• ui/message — send a message to the chat interface
• ui/request-display-mode — request a layout change
• ui/update-model-context — write to the model’s context for future turns

JSON-RPC notifications, host → view

• ui/notifications/tool-input — full tool arguments
• ui/notifications/tool-input-partial — streaming partial arguments
• ui/notifications/tool-result — tool result
• ui/notifications/tool-cancelled — execution cancelled with reason
• ui/notifications/size-changed — view dimension changed
• ui/notifications/host-context-changed — host context update (theme, mode, locale, etc.)
• ui/resource-teardown — pre-cleanup

Sandbox requirements (the host MUST do these)

• Render UI content in sandboxed iframes with restricted permissions.
• Enforce CSP based on the resource’s declared domains in _meta.ui.csp.
• Block undeclared external connections.
• Apply restrictive defaults — default-src ‘none’ if metadata is omitted.
• Validate and log all iframe-to-host messages.
• On the web, use an intermediate sandbox-proxy iframe on a different origin; the inner iframe receives HTML via a sandbox-resource-ready notification.

Everything above is from one source file. If you’re building a server, read the spec end to end — it’s short and concrete, and the field names are stable as of the dated spec.

MCP Will Never Be The Same — Render UI With MCP Apps

Den Delimarsky · click to play

When UI inside chat is right

Five concrete patterns, each grounded in the official examples or partner launch demos. If your tool doesn’t map to one of these, your default should be text.

1. Visual results the model can’t paraphrase

Charts, maps, network graphs, design canvases. The MCP team described this exact case in the November proposal: “a data visualization server returning chart data as JSON forces hosts to interpret and render it themselves — a task that becomes increasingly unwieldy as UI demands grow.” A bar chart with seven series and a region filter is not a paragraph. Render it. The directory’s UI-shaped servers — MCP Server Chart, ECharts, VChart — all sit in this bucket.

2. Multi-field structured input with dependent fields

The MCP team’s own launch example: “a deployment tool presents a form with dependent fields — selecting ‘production’ reveals additional security options; selecting ‘staging’ shows different defaults.” Doing that as a back-and-forth chat exchange is brutal — six turns, three corrections, and the model still gets the conditional wrong. A form is the right tool for the job; MCP Apps simply lets the server ship it.

3. Drill-down exploration of large datasets

The launch post’s sales-analytics example: “a sales analytics tool returns an interactive dashboard where users filter by region, drill down into specific accounts, and export reports without leaving the conversation.” The agent doesn’t need to interpret 14,000 rows; it needs to hand the user a viewport. The launch partners list — Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com, Slack, Salesforce — is a who’s-who of tools where this matters.

4. Approval surfaces for consequential actions

Diffs, carts, deploy plans, payment confirmations. The host spec adds ui-initiated tool calls with host-managed approvals — the user clicks a button in the iframe, the host validates and asks for consent, then the tool fires. That’s a proper trust boundary. Letting an agent “summarise the diff and ask for approval” in a chat bubble is a security mistake — a pattern we covered at length in our MCP security post.

5. Media, canvas, real-time visuals

Images and videos with controls, design canvases, live streams, game boards. The community has already shipped MCP App demos for backgammon, an image carousel, a 3D solar system, and a playable DOOM port (HN: A playable DOOM MCP app). The pattern: the server is the source of truth for the pixels; the model is the orchestrator who knew when to open the canvas.

Steve Kinney captured the underlying logic well in his “Missing Middle of AI Tooling” essay: text-based responses fall apart “the moment users need to explore data interactively, configure complex options, approve multi-step workflows, or view rich media.” If your tool fits any of those four verbs, ship UI.

When UI inside chat is wrong

Five anti-patterns. Each one is a real failure mode we’ve seen since launch.

1. The answer is one fact

A weather tool returning “72°F, sunny” in an iframe is theatre. The iframe boots, paints, and tears down so the user can read fourteen characters. Plain text. Always.

2. The model needs to chain on the result

If the next agent step is “take this result, parse it, and do X with it,” UI is dead weight. The model wants tokens, not pixels. Tools that return code, schemas, or structured data the agent will splice into a follow-up prompt should return JSON or text-formatted blocks. UI here breaks the agent loop, because the model has to reason about a screenshot of a result instead of the result.

3. The session is autonomous

Long-running background agents, scheduled cron runs, agent- to-agent pipelines. There’s no human in the conversation to interact with the iframe. The spec acknowledges this — hosts MAY not support UI at all, and servers are explicitly told to “return text-only results when UI support is unavailable.” If your tool is going to live in a CI pipeline as often as a chat, make text the canonical path.

4. Accessibility matters and you don’t test it

Iframes routinely break keyboard-only flows, screen readers, and WCAG contrast. They’re sandboxed from the host’s a11y conventions. If you ship a form and don’t test it with VoiceOver and a keyboard, the experience is worse than the chat-bubble form-filling it replaced. Public-sector and healthcare-adjacent tools should treat this as table stakes, not aspiration.

5. The UI is a wrapper around three radio buttons

If your form is “pick prod / staging / dev” and a checkbox, you’re paying for an iframe to ask a question the model can ask in three tokens. UI has a fixed cost — bundle size, render time, postMessage round-trips. If your interaction has fewer than two coupled fields or drives no exploration, return a question and let the model ask it.

HN user mindwok raised the deeper concern on the proposal thread back in November: “One of the cool things about MCP (or even just tool calling) is that the LLM on top of a tool provides a highly flexible and dynamic interface to traditionally static tools. This on the other hand seems the other way round — it’s like bolting a static interface onto the LLM, which could defeat the purpose.” That tension is real. The good MCP App is the one where the static UI buys you something the dynamic agent can’t — visualisation, approval, exploration. The bad MCP App is the one where you fossilised an interaction that should have stayed in chat.

Decision matrix by tool type

The spec lets you return text and UI together, so most rows below are about the default shape of the response, not an either-or. “Both” means ship a model-readable summary plus a UI for the human.

Two operating principles for using this matrix. One, always ship text alongside UI. Hosts may not support UI; agents may consume your tool in non-chat surfaces; tests are easier when text exists. The spec encourages this — “return text-only results when UI support is unavailable.” Treat UI as additive. Two, the model still needs to know what happened. Use ui/update-model-context when the iframe changes state in a way the model needs in subsequent turns (the user picked region X, the user approved Y) — otherwise the agent loops forward blind.

Implementation patterns that work

Three patterns the early adopters and the official examples converge on. None are required by the spec; all are pragmatic.

1. Predeclared, reusable templates

The spec explicitly recommends “predeclared UI resources when tools have accompanying interactive presentations; hosts can prefetch templates before execution; content is reusable across multiple tool calls.” In practice: ship a small set of widget templates (a chart, a form, a confirm dialog) and have tools fill them with data, rather than emitting bespoke HTML per call. This is what the launch examples in MCP-UI Widgets do — timer, stopwatch, fact-display, unit-converter templates parameterised at call time.

2. Iframe-as-MCP-client

The architectural neat trick: the iframe is itself an MCP client. It speaks JSON-RPC to the host over postMessage; the host can route those calls to the same MCP server (or others). UI events become tool calls become server responses, with the host arbitrating consent. This is what makes “the user filtered the dashboard” into a first-class server-observable event rather than a black box. The cost is a non-trivial bridge per host — the vendors did the heavy lifting; you only have to think about the resource side.

3. Streaming partial inputs into the iframe

ui/notifications/tool-input-partial exists for a reason. As the model streams arguments to your tool, the host can pipe them into the iframe before the call completes — populating the form, drawing the partial chart, showing the diff in progress. For long-running tools, that’s the difference between a 12-second blank screen and a progressive reveal that feels like the agent is collaborating with the user. The spec gives you the primitive; using it well is a UX problem.

Anthropic engineer Felix Rieseberg framed the goal this way on the HN proposal thread: “Ideally, most users of MCP wouldn’t even know that MCP is a thing — the same way your average user of the web has no idea about DNS/HTTP/WebSockets.” A well-built MCP App disappears into the chat. A badly built one feels like a browser extension that opened in the wrong tab.

Cross-vendor compatibility — the honest answer

The single most-asked question after launch was: does my MCP App work everywhere? The short answer is yes, if you stay on the standard fields, no if you lean on vendor extensions.

Claude (web and desktop). Native support shipped on launch day, January 26 2026. Anthropic also shipped “interactive work tools in Claude” the same week — Slack drafting, Figma diagrams, Asana timelines — using the new spec internally. Launch partners are listed in The Register’s coverage: Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com, Slack, Salesforce.

ChatGPT. OpenAI’s docs are explicit: “ChatGPT supports the MCP Apps open standard for embedded app UIs. MCP Apps UIs run inside an iframe and communicate with the host over a standard bridge (ui/* JSON-RPC over postMessage).” ChatGPT also exposes its older Apps SDK extensions through window.openai for instant checkout, file uploads, and host modals; those are ChatGPT-only and won’t render in Claude. Build to the spec; gate the window.openai features behind feature detection if you need them.

Goose (Block). Block’s open-source agent shipped MCP Apps support on launch week per The Register and the official MCP blog. Goose’s history of being an early MCP adopter means parity is high; the gap tends to be in the UI primitives (display modes, theming) rather than the protocol.

VS Code (Insiders). The Insiders build shipped MCP Apps support on launch week, with stable behind it. The IDE context shifts the UX — many MCP Apps that make sense in a chat client feel awkward in a panel — so VS Code is the right place to test how your UI degrades outside Claude/ChatGPT’s opinionated chat layout.

Antigravity, Cursor, Codex, Windsurf, others. As of the cutoff for this post, support varies. Some IDE-shaped clients render UI inline; others fall back to text. The spec’s “return text-only results when UI support is unavailable” guidance exists exactly for this — your server cannot assume an iframe.

The portability lesson: the spec is the contract, not any vendor’s implementation. Build to _meta.ui.resourceUri, the ui:// scheme, and the ui/* JSON-RPC bridge. Ship vendor-specific affordances behind feature flags. And always ship a text fallback — that one rule covers 90% of portability bugs.

Real MCP servers using it (today)

The launch partner list is the cleanest signal of production usage — Amplitude, Asana, Box, Canva, Clay, Figma, Hex, monday.com, Slack, Salesforce all shipped MCP App surfaces inside Claude on launch day. Below are six servers from this directory that fit the UI-shaped profile, with the install card for each.

MCP-UI Widgets

The reference implementation for the “templated widgets” pattern — timers, stopwatches, fact displays, unit converters, all rendered as MCP-UI components with parameters supplied at call time.

One-line install · MCP-UI Widgets

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

MCP Server Chart (AntV)

Generates 25+ diverse chart types via AntV. The canonical example of “tool returns a chart” — exactly the use case the spec authors describe in the November proposal post.

One-line install · MCP Server Chart

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

ECharts

Apache ECharts as an MCP server, generating ECharts visualisations from JS configuration objects. Pairs well with hosts that render the rich UI; falls back to PNG for hosts that don’t.

One-line install · ECharts

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

VChart

Bytedance’s VChart library exposed as MCP — supports 15+ interactive chart types. Same shape as ECharts and AntV but with a different aesthetic and dataset assumptions.

One-line install · VChart

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

Mermaid Chart

Validates and renders Mermaid diagrams through hosted endpoints. Mermaid is the lowest-friction diagram surface in MCP today, and the rendered SVG drops cleanly into a UI resource.

One-line install · Mermaid Chart

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

Excalidraw MCP Server

A whiteboard-shaped MCP server — useful when the model is drafting flow diagrams, architecture sketches, or UI wires that the user will then edit.

One-line install · Excalidraw MCP Server

Open server page

Install

Cursor

One-click install

1-Click

VS Code

One-click install

1-Click

Claude Desktop

Copy configuration

Claude Code

Copy CLI command

CLI

Gemini

Copy CLI command

CLI

Codex

Copy CLI command

CLI

Windsurf

Copy configuration

ChatGPT

Add via Settings → Connectors

M

Manual

Copy configuration

Beyond the directory, the early MCP App ecosystem has been proliferating fast: a backgammon MCP App (github.com/sam-mfb/backgammon-mcp), a playable DOOM port that runs in ChatGPT and Claude, a 3D solar-system visualisation, and a long tail of domain-specific dashboards. It’s a useful sniff test — if your UI is fundamentally less interactive than backgammon, ask whether it should be UI at all.

MCP Apps are here

Vivek Haldar · click to play

Failure modes

Community signal

Four voices that capture the spectrum from cheerleader to sceptic. Verbatim, with sources.

Frequently asked questions

Sources + further reading

Primary spec

• blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps — official launch post (Den Delimarsky)
• ext-apps/specification/2026-01-26/apps.mdx — the full spec, including all field names, JSON-RPC methods, and sandbox MUSTs quoted in this post
• SEP-1865: MCP Apps PR (modelcontextprotocol#1865) — proposal history, merged 2025-11-21
• blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps — November 2025 proposal post (motivation, use cases)
• modelcontextprotocol.io/extensions/apps/overview — overview docs

Press + analysis

• The Register — Claude supports MCP Apps, presents UI within chat window (Thomas Claburn, 26 Jan 2026)
• Latent Space — AINews: Anthropic launches the MCP Apps open spec, in Claude.ai
• Steve Kinney — MCP Apps and the Missing Middle of AI Tooling
• WorkOS — MCP Apps are here: Rendering interactive UIs in AI clients

Vendor docs

• OpenAI — MCP Apps compatibility in ChatGPT
• OpenAI — Apps SDK
• OpenAI — Introducing apps in ChatGPT and the new Apps SDK (Oct 6, 2025)

HN threads

• HN 46020502 — MCP Apps proposal (192 points, 121 comments)
• HN 46776523 — Anthropic launches the MCP Apps open spec
• HN 47939079 — A playable DOOM MCP app

Internal — read next

• /blog/what-is-mcp — protocol primer
• /blog/claude-skills-vs-mcp-vs-subagents-vs-cli-2026-decision-matrix — when MCP itself is the wrong shape
• /blog/mcp-context-bloat-fix-2026-tool-search-code-mode-progressive-disclosure — keeping tool descriptions tight
• /blog/mcp-security-200000-exposed-servers-owasp-mcp-top-10-cves — the trust boundary problem
• /blog/context7-vs-deepwiki-vs-ref-vs-docfork-2026 — docs-RAG comparison
• /servers/mcp-ui-widgets
• /servers/mcp-server-chart
• /servers/echarts
• /servers/vchart
• /servers/mermaid-chart
• /servers/excalidraw-mcp-server
• /servers — browse the directory
• /best-mcp-servers — curated roundup