MCP Apps: Interactive UI Inside Your AI Client

MCP Apps let a tool return an interface instead of text.That's the whole idea. Before this, every MCP tool answered with plain text or structured data, and the model read it back to you. Now a tool can hand the client an actual UI — you filter the table, drag the slider, fill the form — and the client renders it inline, in the same conversation, no tab-switch.

It landed on January 26, 2026 as the first official extensionto the Model Context Protocol. That “official” word matters: it's not one vendor's UI hack. It's a spec, so a UI you ship once renders the same in every client that supports it. I've been building on MCP for a while now, and this is the first change that makes an agent feel like an app instead of a chat log.

There are three moving parts, and once you see them the whole thing clicks:

• The ui:// resource: Your server bundles HTML and JavaScript and serves it as a resource under the ui:// URI scheme — say ui://reports/dashboard. It's just a tiny web app the client can fetch.
• The tool link: A tool declares which UI belongs to it through the _meta.ui.resourceUri field in its metadata. When that tool runs, the host knows to fetch the resource and render it.
• The App class: The @modelcontextprotocol/ext-apps package ships an App class that speaks JSON-RPC over postMessage. That's the two-way wire between your rendered UI and the host.

The flow at runtime: the model calls your tool, the host renders the linked ui:// resource in a sandboxed iframe, and your UI comes to life. From there the App class gives you three things that matter: it receives the tool result (app.ontoolresult), it can call other server tools on demand (app.callServerTool()), and it can push text back into the model's context (app.updateModelContext()) so the conversation stays aware of what the user just did in the UI.

That last piece is the clever bit. The UI isn't a dead end — when a user picks a region in your dashboard, you can feed that selection back to the model so its next answer already knows about it. The interface and the conversation stay in sync instead of talking past each other.

Not every tool should sprout a UI. Text is faster to build, cheaper to run, and easier for the model to reason over. Reach for an MCP App only when the user genuinely needs to see or manipulatesomething. Here's the split I use:

The official example set makes the range obvious: the launch shipped demo servers for a Three.js scene, an interactive map, a PDF viewer, a system monitor, and even sheet music. A deployment wizard where selecting “production” reveals extra security fields is a perfect fit; “what's my error rate?” is not — that's a one-line answer. If you're still deciding whether a job even needs a tool versus a skill or a CLI, I broke that down in MCP vs CLI for AI agents.

This was my first question too, because “a server can now render code in my client” sounds like a security nightmare. The spec takes it seriously with a layered model:

• The UI runs in a sandboxed iframe with limited permissions — it can't reach the rest of the host or the wider app.
• UI templates are pre-declared as resources, so the client can review what it's about to render instead of getting surprised.
• Every message between the UI and the host is auditable JSON-RPC — no opaque side channels.
• Tool calls triggered from the UI can require explicit user consent before they fire.

None of that removes the oldest rule in the book: you still vet the server you install. A malicious MCP server is dangerous with or without a UI, and the same care you already apply to tool definitions — clear scopes, least privilege, honest descriptions — carries straight over here. If you want the fundamentals on writing tools the model actually uses correctly, that's in Claude tool use best practices.

Here's a benefit that gets buried under the demos: MCP Apps can actually saveyou tokens. When a user explores a 500-row dataset by clicking around a rendered table, none of that interaction runs back through the model. Compare that to the old way, where the tool dumps all 500 rows into the context window and the model narrates them — that's thousands of tokens spent just to show data a UI could render for free.

It ties directly into the thing I harp on constantly: your context window is a budget, and MCP overhead is real. I measured how much raw tool schemas alone cost in what MCP servers actually cost you in tokens, and the same instinct applies to results: push the presentation into a UI, keep the model's context lean, and only feed back the one selection that matters via updateModelContext(). If you're weighing whether to invest in a skill, a plain server, or a full app, the decision framework in Claude Skills vs MCP still holds — MCP Apps just add a richer output option to the “connection” side of that split.

• MCP Apps (shipped Jan 26, 2026) let an MCP tool return interactive UI — dashboard, form, chart, wizard — instead of plain text.
• Three parts: a ui:// resource (bundled HTML/JS), a tool linked to it via _meta.ui.resourceUri, and an App class for two-way JSON-RPC.
• It renders in a sandboxed iframe; the App class receives the tool result, calls server tools, and pushes selections back to the model's context.
• It's an official, cross-client extension — Claude, ChatGPT, VS Code, and Goose already support it, and one UI works everywhere.
• Use an App only when the user needs to see or manipulate something; plain tools still win for short answers.
• Bonus: rendering data in a UI instead of narrating it back through the model can cut token cost, not add it.

Straight from the source: the official MCP Apps announcement and the ext-apps spec and example servers are the canonical references if you want to build one this week.