MCP Apps lets an MCP server return HTML resources that hosts render as interactive UI instead of reducing a company's product to text.
2
Interactions go back through the host, which can call tools or send follow-up messages while keeping the action in the conversation's context.
3
The standard supports predefined, declarative, and fully generative UI, with reusable views and model interaction still being developed.
Summary
Liad Yosef and Ido Salomon explain MCP Apps as an extension that carries interactive UI over MCP. An MCP server can return an HTML resource, and a compatible host can render it in a sandbox. The UI keeps its company's identity and user experience, while clicks and other events pass through the host. This lets the host decide whether to call a tool, fetch another resource, or send a follow-up to the model. A PostHog example shows how a funnel can appear as a visual, interactive component inside Claude. The speakers describe a shift from websites and large dashboards toward smaller UI pieces assembled around a user's intent. They also cover reusable views, model-controlled interaction with apps, and several ways to generate UI. MCP Apps is designed to work across hosts such as ChatGPT, Claude, VS Code, Cursor, and Copilot, although the specification is still changing.
Text responses can reduce a company to an anonymous wall of words. Liad Yosef and Ido Salomon argue that a tool should be able to send the relevant part of its own interface into chat. A Shopify, Hugging Face, Monday, or other component can retain its branding while presenting information in a familiar way. The component can also be interactive, so a user can click a widget rather than describe every next action in text. The original MCPUI project started from this problem, with the goal of passing UI over MCP without throwing away existing UI and UX practices.
The server returns a resource that the host renders as an app
In the older flow, a tool call returned text. With MCP Apps, the tool can point to a resource containing the app's HTML. A host that supports the extension takes that resource and turns it into an interactive application. The speakers stress that this is more than presentation. The app can communicate with the host through standardized messages, which gives the host a consistent way to handle UI events. The approach allows existing web technologies, branding, and interaction patterns to move into agent interfaces.
Routing events through the host keeps actions in context
A direct UI-to-backend call can lose the model's awareness of what happened. The speakers use a song-favoriting example: if the UI talks directly to Spotify, Claude may not know which song was favorited when the user asks later. MCP Apps sends the UI's message to the host instead. The host can interpret it as a tool call and invoke the server. This keeps the action in the conversation and lets the model continue with a follow-up, another tool call, or an additional resource request.
The demonstration compares a textual PostHog response with an MCP App. A text answer contains accurate funnel data, but the user has to read it and work out the pattern. The app returns a visual funnel created by PostHog, so PostHog controls the component's identity and experience. The view is interactive. A user can click a particular funnel step and ask a follow-up about it. The speakers also show that a host can generate UI for an explanation or action, so MCP Apps can support both server-created components and generative experiences.
MCP Apps uses a bidirectional flow inside a sandbox
The architecture starts with a user prompt, a tool call to an MCP server, and a response that points to a UI resource. A host renders the resource, with a callback handling messages between the component and the host. The component runs in a sandbox for security. When someone interacts with it, events travel from the view back to the model through the host. The model can then make more tool calls, send follow-up messages, or fetch resources. This creates an end-to-end flow in both directions.
The host assembles small UI pieces around the user's intent
The speakers describe a web where an assistant can use only the parts of an application relevant to the user's request. Instead of opening tabs and learning several dashboards, a person could plan an anniversary in one chat. Google could provide a calendar fragment, Amazon a product fragment, and Booking a venue and map fragment. The assistant could select relevant pieces based on what it knows about the user, while each company contributes the interaction experience it understands best. The services no longer own the whole user journey because interactions pass through the host.
MCP Apps gives UI authors different levels of control over what happens after an interaction. A notification tells the host that something occurred, while the UI can handle the main action itself, such as updating a Shopify cart. A tool call asks the host to call a particular tool. A prompt gives the host the most control by asking it to run a prompt and decide what follows. This message spectrum lets an app choose whether an event stays local or becomes part of the model-driven flow.
The speakers place UI generation on a spectrum. Predefined UI is a company's own interface, such as Airbnb sending its component to a host. Declarative UI lets an app describe structure while the host renders the components, giving the host more control over visual consistency. Fully generative UI lets the model create the interface at runtime. MCP Apps does not require one source of UI. It can carry third-party UI and first-party generative UI, including Claude's generative experience, and the group is working on interoperability with A2UI and WebMCP.
