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

[upbeat music] Okay.

Uh, hi, everyone. Uh, we built this talk, well, not really yesterday, we built this talk this morning, and it might already be out of date. Uh, I'm Ido Salomon.

I'm the creator of MCP-UI, uh, co-creator of MCP Apps and maintainer, and also the creator of AngelCraft, if you were on the previous session.

I'm Liad. Uh, I work with Ido on MCP-UI. I co-created the MCP Apps spec, uh, with Ido, and I'm also co-founder of, uh, Erel Labs, which is, like, human agentic interfaces company.

So MCP apps are all around us. You might not even realize it, but the interactive applications you see today in ChatGPT, Claude, and others are actually based on MCP and the MCP Apps spec.

But why do we need MCP Apps, and what's MCP Apps? I mean, you heard David this morning talk about it a little bit. Um, we used to text. We used to, um, MCP tools sending texts to our chat agents, but that's not ideal, right?

Because chat, chat is really-- uh, text is really bad. And actually, this was one of the main blockers of companies or, uh, tools not to send their data to ChatGPT because they didn't want to be reduced to, like, this thing, this wall of text, where you don't have identity.

You don't know if, if this information came from Shopify, Booking, Expedia, or, uh, a-any other company. But what if every tool or every company could just send its own UI to the chat?

So instead of us looking at this thing, we can just imagine that for the parts that are relevant, we can have the relevant UI, the relevant UI for Shopify, from Hugging Face, from Monday.

And this can... it can be not only presentational, this can, this can be interactive. So we want to be able to respond to a user click on this Hugging Face widget.

So we don't have to imagine it anymore. Uh, so back in May last year, I released MCP-UI. Uh, the concept was pretty simple. There were a bunch of stuff around it, but the concept was pretty simple, of how do we take UI and find some way to pass it over MCP.

We need some general way to do that, uh, so we can both have, uh, MCP over... Uh, uh, sorry, have UI over MCP, and have the communication between the UI and the host.

Uh, obviously, it also had community SDKs, and the general motivation was we don't need to throw away everything we know about UI and UX just to get into this new world of agents.

Uh, we can simply adapt and use that and preserve our branding and identity and still, uh, be practical. And just a few months back, uh, MCP-UI, we partnered with, uh, Anthropic and OpenAI to really put this into the MCP standard as the first official extension, uh, called MCP Apps.

Uh, and as you can see here, it made kind of a big splash. We had support from a bunch of hosts. Now VS Code and Cursor and Claude and ChatGPT and, like, Microsoft Copilot and a bunch of others already adopted it, and you have these really cool interfaces built in right to your assistants.

And going back a little bit, there were early adopters for MCP-UI. So these are some of the companies, um, shout-outs for Hugging Face, uh, Sean, if you're here, uh, that adopted MCP-UI.

So even a year ago, Shopify was already sending MCP-UI chunks of all of millions, uh, stores of Shopify, online stores send MCP-UI chunks. Uh, Hugging Face, all of Hugging Face Spaces were MCP-UI, uh, uh, widgets.

And now, once it's standardized, we have much bigger adoption. Um, so we have VS Code, uh, we have, uh, Cursor, we have Copilot, um, uh, GitHub. ChatGPT are supporting MCP Apps.

Not only that, ChatGPT are recommending MCP Apps as the way to build ChatGPT apps, so it's really standardized. Um, obviously, a shout out to Postman and Goose and Claude, uh, re- w- the first one that released Claude Apps that actually supported MCP Apps.

But it's not just support from the big companies or the big hosts. We also have huge community adoption. Um, we have, uh, people that building plugins around MCP Apps, uh, building, uh, workshops around MCP Apps, um, building all, all kind of support around MCP Apps.

Py just announced support within MCP Apps, which is amazing. It's like a terminal, right? But we have UI in the terminal right now, and we have all of these advocates that, uh, that are speaking about MCP Apps.

There are even companies that are built around MCP Apps to help other businesses build, uh, those apps. Um, we have, uh, an official MCP Apps repo with, uh, with Anthropic and OpenAI.

There's, uh, an amazing community engagement. We, uh, recommend for you to check it out. We have a, uh, a workgroup, wo- public workgroup meetings, and we're meeting tri-weekly, once every three weeks, just to push this standard forward because as we can see, it's gonna be the global standard for UI inside chat apps.

Um, and we're gonna talk a little bit about the concepts behind MCP-UI.

Yeah. So let's talk about the core concept. So the first and obvious one is how do we even pass UI over MCP? Um, so in the old world of, uh, a few months back, uh, when we wanted to do whatever, let's say we wanted to, uh, create the best playlist ever, uh, we would type something into the

chat and it would send out a tool call to our MCP server. Uh, so far so good. Um, what we would get back in response would be text. Uh, and as you know, text is suboptimal.

But if we are using MCP Apps, what we can do is instead return a resource. So we can return this actual HTML back to the host. The host supports MCP Apps, so you can take that HTML and transform it into an interactive application.

And when we say interactive, we mean interactive. So this is not just presentational. MCP Apps also standardize the way that this UI can talk to the user and to its backend, because just imagine, if the user wants to favorite this song, then the suboptimal thing that would happen is that for this UI to speak to, um, Spotify's

backend and, and favorite this song, and then later when the user asks Claude, "Remind me which song I, I favorited?" Claude wouldn't know, because the UI spoke directly to the backend.

But MCP App standardizes this message passing so that every UI chunk sends message back to the host. The host gets this messag- message, in this case, like a tool call, and the host decides what to do.

In this case, it decides to actually call the server tool, but the control is in the hands of the host, and everything stays in context.

Okay. So seeing is believing. Uh, let's see a quick example of what that looks like. So this is Claude, like actual Claude. Uh, and let's say that, uh, I want to do something like analyze my funnel.

Uh, so I type that in. In the old world, uh, it would go out to, let's say, PostHog, and I would get this textual response, which is accurate, uh, but it doesn't really help me understand what's going on.

I have to read this whole thing now and kind of try and see, uh, what's the deal. But with MCP Apps, instead of doing this, I can just say, "Show me."

And now... [clicks] Okay, the clicker is not yet up to par. But, uh, now what we'll have is this nice UI visualization actually created by PostHog. So they control the identity, the experience.

Uh, it's actually their component that you would see in the website. Uh, and now I have, like, a really cool way to just see the funnel in one glance.

Uh, that's not all. I mean, the, the MCP Apps isn't just UI generated by the server. Uh, there are also really cool innovations from Anthropic and other companies, uh, to do generative UI on top of MCP Apps or even first-party UI in general.

So for instance, this Claude feature, uh, says... Let's say that I don't know what a funnel is, which is, uh, reasonable. Uh, I can ask what a funnel is, and instead, again, getting that long textual answer, what would happen is that Claude would be able to generate this UI for me, explain exactly what I need, or create

some UI that I need to do some action and present it to me in a way that is very digestible. Uh, this is obviously applicable to a bunch of other stuff, and you will see it in other hosts as well. [clicks]

So let's look at, uh... Like, another cool thing is here is that this is not just presentational. Like we said, it's interactive. So I can just click on it, uh, and it would give me a follow-up on the specific step of the funnel, uh, that I have questions about.

So you can imagine how this goes into, uh, into a bunch of other directions when you want to do interactive, uh, exploration.

So how does it work, uh, in general? Uh, so let's go through the stages. Uh, we went to the host, and we prompted something. We asked for, uh, funnel data.

Uh, what happened is that it sent out a tool call to our MCP server. And again, instead of just returning text, that tool was actually pointing to a resource.

That resource was our UI. So, uh, if you look at the, uh, um, code for it, then it's super simple. Like, you just register a resource, and you just have it.

Uh, so we return that resource back to the host. Uh, and the host, because it also supports MCP Apps, can take that, transform it, put it, uh, if you see, like, look at just, uh, code-wise, if you want to build a host, it's just like a, a React component that accepts that resource and also this callback, which

is the way that we handle messaging between the UI and the host. Uh, so we take that, and we render it inside a sandbox, so it's secure. Um, like we said, it's not presentational, so we also clicked on it.

And once you click, what happens is that there is a bunch of events going back from the UI, from this view, uh, all the way back to the model.

So it can actually, uh, take out to, uh, do other tool calls or, uh, even follow-up messages on your behalf or fetch additional resources, uh, really completing this end-to-end bidirectional flow.

So when we look at that, when we look at this flow, when we look at this architecture, it's not just technical change. It's not, not just the technology that's changing.

It's also how we perceive the web, because this is ushering a new web, a web where we don't need websites. We don't need all of those tabs just to organize, uh, um, an anniversary.

We don't need to familiar ourse- familiarize ourselves with bunch of different UIs. We don't need to, um, um, to force ourselves to pass our intents to dashboards of companies, uh, where 90% of this UI is not relevant for an agent.

If I have a personal assistant, I don't need most of it. I can just take this, and I can just decompose it to atoms and let my agent build them for me, right?

Because I, I have my assistant I can weigh my, my intent to. So for example, my agent, my proactive assistant can say, "Yeah, I see that you have an important anniversary coming."

And instead of Google just sending the data, Google can actually send a chunk, right, of the Google Calendar. And now this is a win-win-win, because for Google, it's amazing.

It gets to keep its identity. For me, it's good because I kn- I know this interface. I, I recognize that it's Google. But it's good for the host as well, because the host doesn't need to render that.

We have domain experts. We have companies that spend decades in perfecting user journeys, and we can't expect Claude or ChatGPT or any host to, to automatically generate all those UIs.

And if I continue and I ask something for Amazon, so instead of Amazon just sending me the data of, of the product and thus reducing itself to be just a database, it can just send this chunk of Amazon, and I look at it and say, "Oh, it's Amazon.

Okay, I know." And then I can complete the entire pl- planning of my, uh, anniversary- The entire planning in just one, uh, assistant chat, right? And you can see that it pulled just the relevant parts of it because it pulled the, um, the venue from Booking, but it knows me.

It knows that I prefer something that's close to nature and not in the city, so it also knew to pull the, the map from Booking. That's because the assistant knew me.

Booking doesn't know me that well, but Booking knows how to, how to book a venue, so this is real synergy between those. Um, and we have to think about this new interaction mindset.

Why? Because we have to remember that in this flow, the apps, the services, the tools, they no longer own my journey in the, in the platform, right? If I click something in Booking, it doesn't go to Booking's back end, it goes to, um, it goes to the host, like we said.

So, um, what we did with MCP Apps is that every click, every interaction actually sends this kind of, like, message back to the host. Um, and like we said, it-- this is breaking the model for, for all of the, uh, for all the companies, so this is like a new philosophy.

Um, but the messages can, can be put on a spectrum. So this spectrum represents how much control the UI wants for itself and how much control it gives to the host.

So for example, notification, that's the highest level of control the UI has. It just notifies the host that something happened. For example, if I inc-increase the number of items in my cart, it doesn't need to, to go to the host.

It goes back to Shopify, but it just notifies the host that something happened. A tool call is the UI se-telling the host, "Call the tool." And prompt, that's like the, uh, the UI just releases all control and say- tells to the host, "Just run this prompt and see what happens."

Um, so MCP Apps really standardizes this new software flow, and that's something that we need to remember. Perhaps in two years, we won't have browsers as, as we know them.

We won't have websites as we know them. We'll have a personal assistant that, uh, accepts only small chunks of UI, and this will replace our, uh, our web journey.

Um, 2026 is going to be the year that we're gonna standardize MCP Apps as a global standard for UI, and, um-

Yeah, but the spec is still evolving. I mean, there are a bunch of stuff happening. Uh, just in those last, I think, two months, we shipped all of those, uh, or almost all of those based on community feedback, based on community work done by the work group, which you can join.

Uh, so you're encouraged to do this. Uh, there is the official SDK, xtapps. Uh, you can just use that to build your applications. It's very simple. There are built-in skills, so you just let your coding agent do it for you.

You don't actually need to code anything, uh, God forbid. Uh, so you have this, and then it's important to remember that the reason to use this SDK, uh, is that it's just always compliant with the spec.

Like, we always update both. Uh, so feel free to use it. Uh, you can see that just the issues and stuff that people open on it, so please feel free to do it.

Uh, so what's next for MCP Apps? Uh, obviously there are a bunch of stuff, uh, in the pipeline. Uh, but just to give you, like, a taste, uh, so we have reusable views.

Uh, the idea here is that today, for simplicity, whenever you render an app, we actually render a new one. Uh, so let's say that you're working with the same app multiple times.

Uh, if you keep re-rendering it and you have some heavy application, so for example, Autodesk, uh, had this problem, uh, it just takes a really long time, and your experience will be bad.

So we are working on, uh, ways to solve it. Uh, the first one is just why can't we just reference that same view and push data into it? Uh, but a second one is actually to take this and flip the script.

So, um, another thing that, uh, we've been working on is interactions, not for the user to interact with the, with the app, and then the app sends it to the model, which we just saw.

But what if we want the model to be able to interact with the view? We want Claude to be able to click on buttons or to, uh, fill forms or do anything inside the UI.

So today we have solutions like WebMCP and, uh, things like that. We are working on a standardized way, so when the user interacts with the model, the model ca- the app can actually expose tools for the model to interact with it, thus closing this loop.

Um, and, uh, you can, you can check out the PR. It's still an open PR, but that's something that we work on in the, in the committee. And the most important thing is that MCP Apps supports all ways of, uh, all the ways of, uh, uh, generating UI, because that's a question that we always get asked.

What about generative UI? So if we put it on a spectrum, then we have the predefined UI. That's like the classic MCP App. Just like Airbnb building its own UI, sending it to Claude or to ChatGPT.

That's predefined. That's a black box. That's good for eighty percent of the cases. But we have things that are a little bit more structured, like declarative UI, like if you know JSON Render or, uh, um, uh, things like that, where the app can just declare the s- the structure of the UI, but the components are being rendered

by the host. So the host and the app are sharing the, uh, UI functionality and visibility. That's good for hosts that want to control, um, the look and feel of the apps.

For example, just imagine Claude probably doesn't want to have a Booking UI, then an Airbnb UI, then an Expedia UI in the same chat flow, right? So this is pretty, pretty good, uh, uh, middle ground.

And in the other hand, you have the fully generative UI, which is what, um, uh, Claude, uh, Anthropic released, uh, a few weeks ago, um, where the model just generates the UI out of thin air.

Now, the nice thing is that MCP Apps is really agnostic to how you generate the UI. MCP Apps doesn't assume that Airbnb create- created the UI. Any, any part of this process can create the UI, and the feature that Claude released, which is the generative UI on the fly, actually uses MCP Apps under the hood, right?

So it's a generative UI that's being streamed into an MCP app, and then MCP Apps close that, closes that loop, so it's good for third-party UI, which is the black box, but also first-party UI.

So that's, um, that's something that we're wo-working on standardizing. Um, we are doing, uh, a lot of work to do interoperability with other UI protocols like, um, A2UI, which is, uh, the generative UI protocol by Google, WebMCP, like we said, and we just wanna build a unified standard for UI, uh, in chat apps.

Um, yeah, and that's a, like, a cool summary about MCP Apps. If you build an MCP app, it runs everywhere. LibreChat is an MC- an MCP app, uh, uh, client.

ChatGPT is a ChatGPT app client, but the same application works for... The same code base works for every, uh, every host.

Cool. Uh, so if you think about it, this isn't just some tech, right? This isn't some protocol. This is a new way to distribute applications. Uh, so if you look at just a few months back, uh, Sam Altman said, I think it was October, that eight hundred million people are using ChatGPT on a weekly basis.

That's 10% of the world population. It's insane. Uh, the, the internet took, like, 13 years to get to that, uh, number of users, and now it's not even 800 million, it's a billion.

And it's not just ChatGPT, it's also Claude and VS Code. You have a potential audience that is at least 160 times the number of users that iPhone had when the App Store launched.

Uh, so how do you get started? Uh, there are two main ways. Uh, as a server, like, if you're developing an app, uh, so like I said, you go to xApps repo.

There's a QR code if you wanna do it quickly. You have the skills, just use that. Uh, the other way is in... The skills. The other way is that if you're a host, so if you are building an application that actually, uh, hosts applications, uh, you can just take mcp-ui's SDK, which is the recommended client SDK.

Uh, it's also just fully compliant with the spec. You just take that React component, and you're done. It just supports apps out of the box, and you get hundreds of apps from Booking and other providers out of the box.

Um, so, uh, ju-just to emphasize, uh, there, there was a slide about skills. So it's really easy to create an MCP app. Just if you visit the site, uh, we just, uh, passed through it, but it's just a skill.

You just push it to Claude Code, and you generate an MCP app out of thin air. If you wanna get involved in the spec itself, in how MCP apps are going to operate, in how...

If you wanna help build the future of UI in, uh, in agents, um, then obviously visit the official MCP Apps repo. That's xApps. Open an issue, open a PR, participate in the discussion.

We also have the official Discord for the MCP Apps committee, where we do surveys, and we interact with the, with the community and with other, uh, hosts to, to decide on things that relate to MCP Apps.

And there's the community Discord, which is, I think, the coolest place to be because you have all of the users of MCP Apps, be it, um, um, people that build, build servers, uh, companies that build hosts.

They just talk to each other, share tips, um, uh, troubleshooting, um, asking for features. That's the place to be if you're interested in MCP Apps.

Uh, so we said some scary stuff along the way, uh, like the web is dying, and there's, like, all your websites are, uh, meaningless at the point, at this point.

But I kind of hope that you don't look at this as a threat, but more as an opportunity. Uh, like, basically, a once in a, I don't know, 20 years opportunity to think about your apps again, and think, "What is the core user experience that we're looking to get?"

And imagine it not as a monolithic single app where people go to, but actually a part of a new web of applications, these chunks of UI that allow you to communicate between each other using a smart model in between.

That's, that's pretty insane. Uh, and with MCP Apps, even this early in the ecosystem, and this early in how agentic apps work, we already have standardization, and they all work the same.

You can write your app once, and it will run everywhere.

So what does the future look like? Um, we're not yet at Jarvis, but with MCP in general and MCP Apps in particular, you can bring experiences that were impossible just a few months ago to every host in the world, including your own.

So, thank you.

Thank you very much.

Bye. [applause] [outro jingle]