MCP Apps Standardizes Host-Controlled UI Across AI Assistants
Liad Yosef and Ido Salomon argue that MCP Apps gives AI assistants a way to render service-specific interactive interfaces rather than reducing every result to text. Built from the MCP-UI project and being developed as an MCP extension, the approach lets a server return an app resource that a compatible host renders in a sandbox, while clicks and other actions return through the host for further orchestration. They present it as a portability and distribution model, though state management and interoperability remain active work.
MCP Apps puts the host in charge of an interaction—and gives it a technical path to do so
Liad Yosef presents MCP Apps as a change in who coordinates a task once an application appears inside a chat. A service can contribute its own interface—a chart, form, product card, map, or workflow—but the host receives user actions from that interface and determines what happens next.
That distinction is central to the proposal. Yosef argues that chat interfaces too often reduce useful services to “textual databases”: the answer may be correct, but it loses the visual structure, brand identity, and interaction model that made the original product useful. MCP Apps is intended to let a service send an identifiable UI fragment into a conversation while leaving the assistant in charge of orchestration across services.
We don't want walls of text.
The presenters’ Spotify example makes the control boundary concrete. A playlist can render inside a chat, but clicking a favorite button should not automatically send a request from the embedded application to Spotify’s backend. Instead, the app sends the host an action representing the user’s intent—illustrated as a tool action with a song ID. The host can then decide whether to call Spotify’s relevant MCP tool, take another action, or decline to proceed.
Ido Salomon describes MCP Apps as an extension built from MCP-UI, which he created as an open protocol for interactive applications over MCP. MCP-UI covered both UI transmission and communication between an application and its host. Salomon says MCP Apps was subsequently created with Anthropic and OpenAI as an official MCP extension, drawing on MCP-UI, the Apps SDK, and related work.
The mechanics use existing MCP primitives rather than a separate transport layer. A server tool call can be linked to a registered resource. Instead of returning only text, the server returns HTML with the MIME type text/html;profile=mcp-app; a compatible host consumes that resource and renders it as an application.
The implementation shown is deliberately small. On the server, a developer registers an app resource containing HTML. On the host, a React component or web component accepts the resource and an onUIAction callback, then renders the result in a sandbox. The callback lets an interface event re-enter the assistant’s agentic flow.
| Stage | What happens |
|---|---|
| Prompt | A user asks the host for information or an action. |
| Tool call | The host calls an MCP server. |
| Resource | The server links the result to an app resource containing HTML. |
| Render | The host consumes the resource and renders it in a sandbox. |
| Interaction | A click or other UI event is sent through the host callback. |
| Triggered action | The model can make another tool call, read a resource, or respond in chat. |
Salomon says that when a user clicks inside an app, the event travels back through the callback to the model. The model can then issue another tool call, access another resource, or take another action. The embedded UI is therefore part of a larger interaction rather than a self-contained website operating independently inside the chat.
Yosef describes three action types intended to express different levels of application versus host control: notify, tool, and prompt. An app can notify the host that something occurred; it can request a tool action; or it can ask the host to run a prompt, delegating responsibility more fully to the chat.
In Yosef’s framing, that means applications do not own the full path through a task. A Shopify component may expose an “Add” button, but the resulting action passes to the host. He says a service such as Amazon would not see a user’s complete cross-service flow because the interaction runs through the chat, which he characterizes as more auditable.
A funnel widget turns follow-up questions into part of the interface
Salomon’s product-management example is the practical case for replacing a text response with an app resource. A user asks Claude for insights on a six-step e-commerce funnel. In the text-only version, Claude calls a PostHog server and returns event totals in a table. Salomon calls that answer factually correct but hard to interpret quickly: the reader must inspect each row and infer the shape of the funnel.
| Funnel step | Event | Total events | Share of page views |
|---|---|---|---|
| 1 | page_viewed | 745 | 100.0% |
| 2 | product_viewed | 533 | 71.5% |
| 3 | added_to_cart | 301 | 40.4% |
| 4 | checkout_started | 156 | 20.9% |
| 5 | payment_submitted | 99 | 13.3% |
| 6 | order_completed | 39 | 5.2% |
When both the PostHog server and Claude host support MCP Apps, the same data appears as a PostHog-branded horizontal funnel. The movement from 745 page views to 39 completed orders becomes visible at a glance. Salomon’s point is not only that the rendering looks better, but that the service’s recognizable experience can appear within a general-purpose assistant.
The interaction channel matters as much as the rendering. When the user asks for a visual explanation of funnels, Claude produces a generated HTML diagram with funnel stages and their drop-offs. Clicking the payment_submitted step creates a new chat prompt: “Tell me more about the payment_submitted step in the 6-step funnel.”
Claude then provides a narrower analysis: 99 users reached payment submission; that was 13.3% of users from the first step; and 57 of the 156 users who started checkout did not submit payment. The UI has not replaced conversation. It has supplied a structured route to the next question and carried the relevant context into it.
The proposed agentic web is composed from service-specific UI fragments
Liad Yosef extends the host-control model into a broader view of how people may consume the web. He describes planning an anniversary as a task that might otherwise require many browser tabs: calendar, shopping, travel, mapping, and repeated interactions with each service’s full dashboard. In his framing, much of that interface is irrelevant to the immediate task because it does not have the assistant’s context about the user.
His alternative is to break service interfaces into “atoms”: a calendar event, product card, map, booking result, or shopping-cart element. A personal assistant could select and compose those pieces inside one task flow rather than requiring the user to move among complete websites.
I don't need the UI. I need those atoms.
In Yosef’s anniversary scenario, a proactive assistant sees an upcoming anniversary and displays a Google Calendar event block rather than merely reporting the date. It can then surface Amazon flower offers, a map, and a cart component within the same conversation. The interfaces remain recognizable as service-specific components, but the assistant determines which component is relevant and when.
Yosef says this arrangement gives the user contextual, task-specific UI; allows a service to maintain its brand and identity; and means the host does not need to develop every specialized interface itself. He calls the arrangement the “agentic web,” in which websites shift into smaller interface chunks that personal assistants can surface in context.
That vision depends on the host-mediated interaction model demonstrated in the Spotify and PostHog examples. The host has context across calendar, shopping, travel, and prior conversation. It can coordinate components across services, while an individual service contributes a bounded interface and communicates actions back to the host.
The rendering flow works today, while state and interoperability remain open work
Ido Salomon is explicit that MCP Apps is still evolving. A slide lists sandbox capabilities, terminology, theming, mobile SDKs, UI termination requests, React rendering, tools for apps, unique origins for views, inline-script limitations, app sampling, model and view state, context updates, and portability. Salomon characterizes these as items already in the work, contributed by the community, or proposed—not as a settled set of completed capabilities.
One practical constraint is the cost of persistent, heavy interfaces. Salomon uses an Autodesk 3D architectural renderer as the motivating case. A company with a substantial app should not necessarily rerender it from scratch whenever a later request refers to it, he says. The team is considering whether a server could pass an identifier that helps the model keep updating an existing view rather than creating a new one each time.
Another direction is host-to-app communication. The interaction flow already demonstrated begins when a user acts inside an app and the app reports that action back to the host. Salomon says the group is also standardizing a reverse path in which the host or chat can operate the application—for example, filling out a form after the user asks the assistant to do so.
He introduces this direction as “app tools,” comparing it to WebMCP, then calls the capability “view tools.” He says it is in the specification and is expected to be released very soon, while leaving the terminology visibly unsettled.
MCP Apps is also intended to be agnostic about how an interface is produced. Salomon places predefined custom interfaces, declarative approaches such as JSON Render and A2UI, and fully generative UI on a spectrum. A predefined UI might be a complete AllTrails interface embedded in chat; a declarative system returns instructions for the host to construct the UI; and fully generative UI has the model create the interface itself.
Salomon says Claude’s “Imagine” capability uses MCP Apps behind the scenes even though its interface is generated on the fly. His point is that MCP Apps can carry both service-authored and generated interfaces rather than requiring one rendering approach.
The group is working on interoperability with A2UI, AG-UI, and WebMCP. Salomon says they released a guide for combining A2UI with MCP Apps: a server could write A2UI to ship an experience to Gemini while wrapping it as an MCP App for ChatGPT, and vice versa.
Portability depends on hosts implementing the same capability
The clearest demonstration of the “write once, run everywhere” claim is a side-by-side calculator example: the same application and codebase run in LibreChat and ChatGPT. Salomon’s claim is that an MCP App can run in clients that support the protocol, reducing the need to build a bespoke UI integration for each assistant.
The presenters point to MCP Apps or MCP-UI adoption and support across Claude, ChatGPT, VS Code, Cursor, Copilot, Postman, LibreChat, and other clients and tools. That support remains the condition for portability: the same resource can only render where the host implements the relevant capability. But the calculator example captures the intended development model—one server-shipped app resource, rendered by multiple compatible hosts.
For server and host builders, the practical entry point is the official ext-apps repository and SDK. Salomon says that because the SDK is maintained by the project, incorporated specification changes are reflected in it directly. Yosef says the MCP Apps workgroup meets every three weeks with Anthropic, OpenAI, and other participants, and that the repository accepts issues, pull requests, and proposals from the community.
The commercial bet is assistant-scale application distribution
Liad Yosef frames MCP Apps as a new way to distribute applications, not just a UI feature. He cites Sam Altman’s statement that ChatGPT had 800 million weekly users and describes that figure as roughly 10% of the world’s population. He compares that scale with the early web, which he says took around 13 years to reach that number of users, and says the opportunity represents more than 170 times the total addressable market of the Apple App Store at launch.
Those figures are Yosef’s commercial case for MCP Apps: an interactive interface built for a supporting assistant can be presented to the users of that host without a separate interface implementation for each client. He points to hosts including Slack, VS Code, Claude, OpenAI, Copilot, and Spark as evidence that the relevant surface is already emerging.