An App That Runs Inside the Chat: MCP Apps
MCP Apps was proposed in November 2025 and shipped as an official MCP extension on January 26, 2026. A tool points to a UI resource via a _meta.ui.resourceUri field, served as an HTML/JavaScript bundle over the ui:// scheme, and the host renders it directly inside the conversation. Dashboards, forms, visualizations, and multi-step workflows now render as interactive screens instead of text, and the 2026-07-28 MCP spec revision promoted the extension to official status, versioned independently from the core spec. Claude web and desktop, Goose, VS Code Insiders, and ChatGPT already support it, with JetBrains, AWS Kiro, and Microsoft on the roadmap.
A Security Model Built on Consent Gates and Audit Logs
MCP Apps runs UI content inside a permission-restricted sandboxed iframe and requires pre-declared templates so hosts can review the HTML before rendering. All UI-host communication travels over postMessage but is logged as auditable JSON-RPC messages, and a host can require explicit user consent before a UI is allowed to call a tool on its own. Sandboxing, pre-review, auditable messaging, and consent gating are four separate defenses against four separate failure modes — dropping one is not covered by the other three.
From Design Review to Incident Response: An MCP Apps Rollout Roadmap
Pin the targets in numbers before shipping. A reasonable acceptance bar: 100% template pre-review pass rate, zero unapproved UI-initiated tool calls, under 1% rendering failure rate, and a p95 consent-prompt response under 2 seconds. Because rendering behaves differently across hosts, lock the actual production host list — Claude, VS Code, ChatGPT — before scoping review, or the review boundary keeps shifting.
Most failures start with skipped review. Pulling an example from the ext-apps repository without pinning a commit hash means unreviewed code slips into production the moment the upstream source changes. Skip template validation in the deploy pipeline and that kind of change ships with no release note at all.
A host that skips postMessage origin checks can mistake a message from another tab or extension for a legitimate UI response. When the origin doesn't match the registered value, the default recovery branch is to cut the connection immediately and fall back that session to a text response; when logs catch a tool auto-invoked through a bypassed consent gate, quarantine the session and pull that template's deployment right away.
Consent fatigue is a real failure mode too. Prompting approval for every single UI interaction trains users to click through on habit, which turns the gate into a formality. Require consent only for high-privilege calls — payments, deletions, sends — and let read-only interactions run automatically within a pre-approved scope; that's what keeps the gate meaningful.
Before shipping, run scenario tests for rendering and consent flow on each supported host. Keep a minimum log schema of request id, template hash, origin, consent status, and render latency, and mask user data in the logs whenever a dashboard-style UI displays it rather than storing it raw.
After launch, aggregate three metrics weekly — rendering failures, consent denials, origin mismatches — to narrow down root causes. Keep the template version's changelog separate from the server logic version's, so when rendering failures spike you can tell immediately whether the UI or the tool's response schema is at fault.
Takeaways You Can Apply Today
Because MCP Apps turns a tool's response into an interactive screen, safety depends on three layers of control — review, communication, and consent — all staying intact at once. Set 100% template pre-review pass rate and zero unapproved UI-initiated tool calls as your shipping bar, and wire an automatic recovery branch that quarantines the session the moment origin validation fails or a consent gate gets bypassed; that lets you run the same standard across every host you ship to.
References
MCP Apps: Bringing UI Capabilities To MCP Clients — Model Context Protocol Blog