MCP-UI: Extending the Frontier — Liad Yosef and Ido Salomon, MCP Apps

A tool can return accurate information and still deliver a poor experience. In a chat response, a Shopify product, a Booking listing, and an Expedia result can collapse into the same wall of text. The user loses the recognizable interface; the provider loses its identity and the interaction patterns it has spent years developing. ChatGPT and Claude can already display interactive applications. The question is how to make those interfaces a regular part of tool use.

Instead of asking the assistant to describe everything, a provider could supply the relevant part of its own UI: a Shopify component, a Hugging Face widget, or a monday.com view. That component should also respond to interaction. Clicking the Hugging Face audio player should do something, not merely illustrate what a player looks like. This is the starting point for MCP Apps: carry an interface into the conversation, then give it a way to communicate with its host.

Ido Salomon dates his release of MCP-UI to May of the preceding year. Its core problem had two parts: transport UI over MCP and support communication between that UI and the host. Community SDKs made the approach usable without discarding existing UI and UX knowledge. Branding and familiar interaction patterns could survive the move into assistants.

Salomon and Liad Yosef subsequently worked with Anthropic and OpenAI on MCP Apps, announced in January 2026 as MCP’s first official extension. The talk names VS Code, Cursor, Claude, ChatGPT, and Microsoft Copilot among the adopting hosts. Standardization moves the interface beyond a particular provider–assistant integration toward a shared contract.

Earlier MCP-UI adoption provided the starting point. Yosef says millions of Shopify stores were sending MCP-UI chunks and all Hugging Face Spaces were MCP-UI widgets. These are his adoption claims, rather than measured deployment totals presented in the talk. He then describes broader MCP Apps support across VS Code, Cursor, Microsoft and GitHub Copilot, ChatGPT, Postman, Goose, and Claude, including ChatGPT’s recommendation to use MCP Apps when building ChatGPT apps.

The ecosystem also includes plugins, workshops, businesses helping others build apps, and even UI support in the terminal-oriented Pi. The official specification and SDK repository provides a common place to develop the standard with Anthropic, OpenAI, and community contributors. Yosef describes public workgroup meetings every three weeks: adoption is accompanied by an ongoing process for changing the protocol.

Consider a request to create a playlist. The assistant calls an MCP server tool. A text-only result can describe the songs; an MCP Apps integration can associate the tool with an HTML resource that the host renders as an interactive application. More precisely, the specification links a tool to a separately fetched UI resource through _meta.ui.resourceUri. HTML does not have to replace the tool’s textual or structured result.

Now the user favorites a song. If the widget updates Spotify directly and tells nobody else, a later question about which song was favorited leaves Claude without the relevant information. The backend changed, but the conversation did not learn about the change.

MCP Apps gives the widget a message path back to the host. In this example, the UI requests a tool call; the host receives that request and decides whether to call the server tool. The host remains in control of the action. This creates a route for keeping the interaction in context, although host mediation alone does not automatically insert every click into model context: the protocol distinguishes app-visible tools from model-visible tools.

The PostHog demonstration starts with a request in Claude to analyze a funnel. The initial response is accurate text, but understanding it requires reading through the report and reconstructing the funnel mentally. Asking to see it instead produces a visualization. Salomon identifies the result as PostHog’s own website component: PostHog controls the presentation and identity, while the user can understand the funnel at a glance.

A different need calls for a different interface. If the user does not know what a funnel is, Claude can generate an explanatory UI rather than simply repeat the analytics component. The demonstration moves from a provider-built view of data to a generated explanation of the concept. Clicking a particular funnel step then produces a follow-up about that step, turning the explanation into an exploratory interface. Server-provided UI, generated UI, and first-party host experiences can all participate in this interaction pattern.

The funnel interaction begins with a small server-side contract:

1. The user asks the host for funnel data.
2. The host calls an MCP server tool.
3. The tool points to a registered UI resource.
4. The host retrieves that resource for display.

The metadata link is the important connection. For a funnel tool, it can be expressed in TypeScript as:

const resourceUri = "ui://funnel/view.html";

const funnelTool = {
  name: "show_funnel",
  description: "Show the funnel visualization",
  inputSchema: {
    type: "object",
    properties: {},
    additionalProperties: false,
  },
  _meta: {
    ui: { resourceUri },
  },
};

const funnelResource = {
  uri: resourceUri,
  name: "Funnel view",
  mimeType: "text/html;profile=mcp-app",
};

export { funnelTool, funnelResource };

These declarations illustrate the linkage: the tool names the same URI that the server exposes as a UI resource. Resource registration and serving the HTML complete the server side.

On the host side, Salomon describes a React component that accepts the resource and a callback for messages from the UI. The host renders the view inside a sandbox, providing a boundary between application content and its surrounding assistant. The talk’s component description is architectural; current SDK examples should not be read as the exact historical slide API.

The return path completes the system. A click emits an event from the view toward the host and model. Depending on the message and host behavior, that can initiate another tool call, request additional resources, or produce a follow-up message on the user’s behalf. Rendering an HTML panel is only half of the integration; the other half is connecting its interactions to the assistant’s next action.

The same architecture changes how a user might work across services. Planning an anniversary ordinarily means opening tabs, learning different dashboards, and translating one intent into each company’s navigation. Yosef estimates, illustratively, that 90% of a company’s dashboard UI may be irrelevant to an agent. His proposed alternative is to decompose those destinations into the parts needed for the current task.

The scenario begins with a proactive assistant noticing an upcoming anniversary. Google supplies a Calendar component rather than only event data. Google retains its identity, the user recognizes the interface, and the host does not need to design a calendar interaction itself. Providers bring domain expertise and established user journeys that an assistant should not have to recreate on demand.

Next, an Amazon product component preserves the shopping experience instead of reducing Amazon to a product database. Booking supplies a venue component; the assistant also selects a map because it knows the user prefers somewhere close to nature rather than in the city. The assistant knows the person; the provider knows the domain. Their responsibilities complement each other, allowing the anniversary plan to develop within one conversation.

Once the interface sits inside an assistant, the service no longer exclusively controls the user’s journey. A Booking interaction can become a message to the host rather than a transition through Booking’s own pages. Yosef describes a spectrum according to how much authority the UI keeps over what happens next.

The notification example makes the distinction concrete: increasing a Shopify cart quantity can update Shopify directly while notifying the host. Thus, the earlier description of clicks going through the host does not mean every backend operation must take that route. A tool-call request delegates execution of a particular operation; a prompt delegates much more of the decision itself.

Yosef extends this into a forecast: familiar browsers and websites could change within two years as personal assistants assemble small UI components around users’ intentions. He frames 2026 as the year to establish MCP Apps as a global UI standard. These are ambitions for the interaction model, not prerequisites for using the protocol today.

The specification is still evolving. Salomon says all or almost all of the recent changes displayed in the talk arrived over roughly two months through community and workgroup contributions. His recommended implementation path is the official ext-apps SDK, with skills that help coding agents create applications. The reason to use it is practical: maintainers update the SDK alongside the specification, reducing the burden of tracking protocol changes independently. Issues and workgroup participation feed back into that process.

One roadmap item addresses repeated application initialization. At the time of the talk, rendering an app again created a new instance. Salomon cites Autodesk as an example where repeatedly starting a heavy application makes users wait. The proposed reusable view would let the host reference an existing view and push new data into it, preserving the running application instead of rebuilding it for each interaction.

Another proposal reverses the interaction direction. So far, the user operates the UI and the UI sends messages toward the model. What if Claude could operate the view—click buttons or fill forms—through tools exposed by the application? Yosef points to WebMCP as related work and describes standardizing app-exposed tools to close this loop. The model-to-view proposal was still an open PR under committee discussion during the talk.

MCP Apps does not require one method of creating interfaces. The first option is a predefined application: Airbnb builds its UI and sends it to Claude or ChatGPT as a largely self-contained component. Yosef estimates that predefined UI suits 80% of cases; he presents this as a design judgment rather than a measured result.

Declarative UI occupies a middle position. With approaches such as json-render, the application declares the structure while the host renders the components. Both sides participate in the resulting interface. This is useful when a host wants a consistent appearance rather than a Booking widget, an Airbnb widget, and an Expedia widget with unrelated styling in the same conversation.

At the generative end, the model creates an interface during the conversation. Yosef says Claude’s generated visuals stream into an MCP app underneath. The protocol’s role is independent of who authored the interface: it carries the UI and supports the interaction loop for both third-party applications and first-party host features.

The intended direction is interoperability with other UI approaches, including Google’s A2UI and WebMCP. Yosef names LibreChat and ChatGPT as examples of hosts that can receive the same application codebase. That portability applies among compatible hosts: MCP Apps is an optional extension with capability negotiation, not a guarantee that every MCP client renders applications.

An application embedded in an assistant can reach people where they already work. To illustrate the scale, Salomon recalls Sam Altman reporting 800 million weekly ChatGPT users around October. An October 2025 OpenAI statement supports more than 800 million weekly users at that time.

Salomon compares that audience to 10% of the world’s population, says the internet took roughly 13 years to reach that scale, and then describes ChatGPT’s audience as one billion without specifying a measurement basis. Adding the opportunity represented by Claude, VS Code, and other hosts, he claims potential reach at least 160 times the iPhone user base when the App Store launched. These comparisons frame the distribution opportunity, but their denominators are not established here, and the billion figure should not be treated as a verified weekly-user milestone. Host audiences also overlap; potential reach is not the number of users an individual app can immediately access.

There are two implementation entry points. For an app or server, Salomon directs developers to ext-apps and its official skills. These provide a way to start with a coding agent rather than manually assemble the entire integration. The displayed installation options cover a Claude Code plugin and the Vercel Skills CLI.

For a host, the speakers recommend MCP-UI’s client SDK and its React rendering component. The host takes responsibility for displaying applications and handling their messages. Salomon says this integration opens access to hundreds of existing apps, including Booking-related offerings. That is an ecosystem claim, not a promise that rendering alone supplies every provider’s access requirements.

Yosef returns to the app-building path with Claude Code as the concrete coding-agent example, then separates implementation from participation:

• Specification work: Open issues, submit PRs, and join discussions in ext-apps.
• Committee participation: Use the official committee Discord for surveys and discussions involving hosts and the community.
• Developer support: Join the community Discord to exchange tips, troubleshoot integrations, and request features with server developers and host companies.

The ecosystem needs both sides of the connection: applications worth embedding and hosts that make them usable.

The provocative suggestion that websites might lose their central role leads to a more useful design question: what is the core experience an application should provide? Salomon frames this as a rare opportunity to reconsider the product, rather than a reason to abandon everything already built.

A product need not exist only as a monolithic destination. Its essential interactions can become components in a wider web of applications, with a model mediating between them. Early standardization makes it possible to build those components for multiple compatible hosts instead of creating a separate integration for each assistant. The vision is not yet Jarvis, as Salomon acknowledges, but it includes something developers can act on: bring a focused, recognizable experience into an assistant—including a host of their own.