MCP Apps – the Next Web

Okay, so hi everyone. We built this talk literally yesterday, so it might already be out of date. I'm Ido Salomon, I'm the creator of MCPUI and the co-creator and maintainer of MCP apps in the MCP steering committee. I'm also the creator of AgentCraft and a bunch of other projects that you might know. And I'm Liad, I work with Ido on MCPUI. I'm also the co-creator of the MCP AppSpec on the MCP App Steering Committee. And recently I co-founded a company called Aura about the agentic web and how to make the web more accessible for agents.

So MCP apps are all around us. You might not even realize it, but all the interactive apps that you've been seeing in Chattopity and Cloud and Gemini and others are actually MCP apps. And specifically MCP apps. And we're all familiar with these walls of text, right? When you ask a question of Chattopity or Gemini or Cloud, and you get this wall of text, but text is really the worst interface that you can imagine. Because if I want to aggregate data from different resources, I don't want to see something like that. I can't read that.

Instead of like staring at this wall of text, what if every application or every company could just send chunks of its UI, chunks of its identity to the chat? Maybe this is exactly what we want. Maybe instead of this, we'd actually want parts of user interfaces that we already know, that we know how to interact with, and that maintain the company's brand and identity inside the chat. And imagine that they won't be just presentational. Maybe we can make them even interactive, right? So I want to be able to click on a button inside the chat, and I want the chat to be responsive to that.

Maybe instead of this, we'd actually want parts of user interfaces that we already know, that we know how to interact with, and that maintain the company's brand and identity inside the chat. And imagine that they won't be just presentational. Maybe we can make them even interactive, right? So I want to be able to click on a button inside the chat, and I want the chat to be responsive to that. So we don't have to imagine the future. With MCP UI, which is a product I created in May last year, we actually built an open protocol for interactive apps over MCP. The basic idea there is how do we transmit UI and applications over MCP and how do we standardize the way that the host and the app communicate? The basic idea there was that we don't have to abandon dozens of years where we perfected UI and user experience just to adapt to the new web, to agentic web.

So actually, just a few months ago, we partnered with OpenAI and Anthropic to create really this official standard spec into MCP called MCP-Apps. It made a little bit of a splash with support from VSCode and Cloud to start off, but obviously a bunch of others now. And the adoption for MCP UI and now MCP-Apps was through the roof. So here you can see some of the early adopters, which are companies that bet on this spec. Just imagine, to invent a spec, it's like a chicken and an egg problem, right? And these companies bet on this spec from the first days. For example, Shopify from the early days shipped all of its stores in MCP UI standard. So all of the millions of Shopify stores right now are supporting MCP UI.

And this allowed chats to support it as well. And today, we have a staggering support for that. We have a support in VSCode and in cursor and Copilot and GitHub. And obviously, ChatGPT is also supporting MCP-App. Not just that, every app that you build on ChatGPT, OpenAI recommends to use MCP-App as the way to build it. And obviously, Cloud supports it. And basically, if you build an MCP-App, it's supported everywhere. But not only with the big hosts, with the big chats. We have amazing community support for MCP-Apps as well. MCP-Apps, it's an open protocol. It's maintained by the MCP committee, but it's also open for the community.

It's maintained by the MCP committee, but it's also open for the community. So we have a lot of community plugins and community adaption and community courses that are built to help people build MCP-Apps. And you can you can check out the repo later. But as you can see, we have a lot of issues and NPRs that are being opened to the spec by the community, which is amazing. That's the first time that we have a standard that's being supported everywhere. But the community is the one driving it. We have a work group for this, and we have a meeting every three weeks to decide where the spec is going to go. What do we need to change? We hear requirements from big hosts like OpenAI and Anthropic, but also from community hosts. And we try to embed them into the spec.

So let's look at a few of the core concepts behind MCP-Apps. So the first and most obvious one is how do we even transmit UI over MCP? So if we look at the old world, we'd have Cloud and we'd ask a question like, let's say I want to build the best playlist in the world. What would happen is that Cloud will send out a tool request to my MCP server. The response for that tool request would be text, which is obviously suboptimal. But with MCP-Apps, because the server supports it, instead of returning raw text, it will return this HTML component. This component will be passed over to Cloud or any other compatible MCP-Apps host, and that would be rendered into a fully interactive application.

And by fully interactive, we actually mean fully interactive. So it's not just presentational. Like I said, we want the user to be able to interact with it and we want the user to be able to interact with Spotify in that example. But we can't really do that. We can't have the user click on something in the app and talk to Spotify because later the user will ask the chat, remind me which song I favorited, and the chat would know that. So MCP-Apps actually standardizes the way that apps are speaking to the host. So if a user clicks something, it sends a message back to the host, in this case, a tool call. And the host, the chat, is the one deciding what to do with this message. In this case, the host decided to actually call this tool call, but it can do anything it wants. And the benefit in that is that it stays in the host's context.

So everything goes through the host. So seeing is believing. So let's see a quick example of what that actually looks like. Let's say that I'm a product manager and I want to understand what's the status of my funnel to understand how users use it. Again, in the old world, I would ask a question, Claude would reach out to my MCP server, let's say it's PostHog. PostHog would return this textual response showing the status of my funnel, which is awesome, but it's factually correct, but it doesn't really help me. I mean, I can look at this and it doesn't mean anything. I can't really quickly understand what's going on. Luckily, because both PostHog and Claude support MCP apps, instead of doing that, I can just say, show me. And now, instead of getting this wall of text, I would get an interactive component, which was actually designed and built by PostHog. It looks like and feels like PostHog with their own identity and experience, and I can quickly understand what's going on.

MCP apps isn't just presentational, as we just discussed, and it's also not only static. It doesn't have to be something that PostHog generates once and then sends it over to me. It can actually be used for generative UI. So, for example, in Claude, you have the Imagine feature, which is really cool. A model can actually generate UI on the fly to explain things or drive the conversation forward. So, let's say that I'm a product manager, but I don't really know what a funnel is. So, I can ask what it is, and now, instead of, again, getting this block of text explaining it, I would get this interactive component, which wasn't prebuilt by anyone. It is actually built by the model and streamed in real-time into an MCP app and rendered to me. And not only is it really cool that it actually shows me the data in a way that I can consume, it's also fully interactive, as we mentioned.

What does this interaction even mean? It means that I can drive the conversation forward with clicks. I don't really have to rely on prompting something or inventing something that the model might understand or might not. So, if we took this example, and this is, again, totally generated, I can just click on this part of the funnel, and I would get an explanation just for that part. And I think that really cool part is that the model is actually aware of I can drive myself using this UI, so it would put this functionality into the UI. So, how does it actually work? There's a bunch of stuff going on here. So, if you look at the complete flow, the first part was prompting the model and saying, I want to understand the funnel. That resulted in a tool call to our MCP server, and again, because the MCP server supports MCP apps, it actually takes that, and instead of returning text, it returns a UI resource just through this identifier. If you look at the SDK, it's just a simple registration of a tool and resource. Super simple, this is the official SDK. I can take that, return it over the wire, back to the host.

The host can take this UI resource, and because it supports MCP apps in the client, and if you look at the MCP UI SDK, it's just a React component or a web component that accepts the resource itself, plus this callback for the messaging mechanism that we just saw, and renders it in a sandbox. The reason it's in a sandbox is obviously to keep it secure. As we said, it's not just presentational. I can click on it. That click actually resulted in an event that was propagated back to the host and then to the model, with the model then being able to take that and do a follow-up, like sending another prompt or another tool call back to our server. This architecture and this way of thinking, it ushers a new way of thinking about the web, because if we can allow apps to send chunks of their identity or chunks of their UI to the chats, then think what it does to the web, what it does to websites, what it does to browsers.

If I want to accomplish some sort of a task and say I want to plan an anniversary or an event, in the old world, which was a few months ago, I need to open the browser and look at all of these tabs just to complete something, right? The thing is not the number of tabs that I open. As a human, I need to convey my intent to those applications using their own UI. But I don't want to learn how to use each of those applications just to do what I want to do, because I have a personal assistant, I have an agent, I have something that knows me and that can help me convey my intent to those applications. So if we take these UIs and we just break them into atoms, into the parts that are really interested to me, because I'm not interested in 99 percent of what bookings dashboards look like, I just want to book a hotel, then I can have my personal assistant assemble this for me.

So I can have my assistant say, hey, I see that you have an interesting date coming up. And instead of just pulling the data from Google Calendar, it can actually display the Google Calendar chunk to me. Now, for me, it's helpful because I know Google Calendar. For Google, it's helpful because they keep their identity and branding. And for the chat, it's helpful because it doesn't need to generate it from scratch. And if it calls to Amazon, then instead of just pulling the data from Amazon, it can actually show me a chunk of Amazon. And again, it doesn't need to generate the entire user flow from scratch. We have domain experts for that. We have Amazon, which is a domain expert, and booking, which is a domain expert, and TripAdvisor or Kayak, which are domain experts.

So my experience can be look like that, can look like that. And I don't need to open a browser. I don't need to open multiple tabs. And my assistant can pull just the parts that they want, because it knows me, it knows that I prefer to have a hotel in the countryside, so it knows to pull the map from booking. And booking is the one providing the map, but my assistant is the one driving it. And with that, there's a new interaction mindset between the apps and the users, because the apps no longer control the user journey, right?

If that's Shopify, for example, if I'm doing something in Shopify's cart, then instead of just doing it, it sends a message to the host. So the application no longer knows what I'm doing in my journey. It doesn't have my intent and apps need to adapt to that. So MCP apps standardizes the way for an application to send a message like we've shown. And these messages lie on a spectrum according to the control the application has in the user. So if the application just notifies the chat that something happened, that's the application control, or the application can actually ask the chat to run a prompt for it. So this is a new software flow between the application, the chat, and us as humans.

And it's not the end. Yeah, so now it is actually a global standard, as we just described. And the spec is still evolving. If you look at this list, it's just a partial list of some of the stuff that we've actually implemented based on community feedback and contributions over the past few months. We have the official SDK and the XDAV repo, which has all that nice stuff that you saw earlier in the architecture example. And the cool thing about the SDK is that all the changes we have in the protocol are reflected into the SDK immediately within that same PR. So if you are using the SDK, you keep up to date with the protocol as we change it. And you can see the different issues that we have and the different contributions we have over time.

And I think the next question is, what's next? This is only the beginning for MCP apps. It's only been around for a few months. It's already powering all of the agentic apps across all the hosts. But there's still a lot more to do to really enable the next wave of applications. So one of the first things is reusable views. We've actually had this coming from a bunch of different providers, a bunch of different apps. When they have really heavy JavaScript loaded inside the application, and we reload it every time we need to, every time the user prompts for something else within that application, it's actually very heavy and really limits the user experience in that regard. So we are working on a way for them to reuse existing components so they wouldn't need to reload it each time.

And one of the other questions that we keep getting is how the chat can interact with the app. So we said that the user can interact with the app, but the chat wants to interact with the app as well. Right? Maybe I want to write something to chatGPT and have chatGPT favorite the song for me. So if you've heard of WebMCP, that's one proposed API to do that. And MCP apps actually implementing a more robust way of doing it. So instead of the user clicking and then it communicates to the chat, the user can interact with the chat and the chat can make changes in the app itself. So that's something that we're working on supporting in MCP apps.

And you've probably heard about generative UI methods. Right? So what we described right now is an app sending a UI that's displayed as a black box to the chat. But what if the chat wants to generate or change the UI? We can put it on a spectrum. We have predefined UIs, which are the UI, like Zillow or TripAdvisor that just send chunks of their UI to the chat. We have declarative UI if you heard of JSON render or ways for the app to define which UI it wants to generate, but the chat is the one generating it. And then you have the fully generative UI that the chat just generates on its own. And the nice thing about MCP apps is that it's agnostic to the way that the UI is generated. MCP apps is an umbrella protocol for every method of UI generation. And actually what we mentioned earlier, the imagined feature of Cloud, which generates UI out of thin air is actually using MCP apps under the hood. So MCP apps really solves this entire circle of UI that's displayed in chats. And we're working on interoperability with other standards as well. And the cool thing about an MCP app, like we said, it has a huge adoption. So if you build it once, it will literally run everywhere. You can see here, LibreChat, which is like an open source chat, and to the left and then ChatGPT on the right. And that's the same MCP app, the same code base that just runs everywhere.

That's the beauty in a globally supported standard. And this is exactly what we wanted with MCP apps. We didn't want ChatGPT to define their own and Cloud to define their own and Gemini to define their own, but we wanted one standard that's acceptable for everyone. So if you look at it, it's not just technology, it's not just a protocol. It's actually a new way to distribute applications, a new way for users to interact with them.

So if we look just a few months back, Sam Alton said that ChatGPT has 800 million weekly active users. That's insane. That's 10% of the world's population. If you look at the internet at large, it actually took 13 years just to get to that same point. If you take this and compare it to other app stores, if you look at just a few years back and we have the iPhone with 6 million users when the app store launched, we now have closer to a billion users just from ChatGPT. That's over 170 times the total addressable market we had back then.

So how do you get started? As a server, as an app developer, you go to the MSTP Apps Repository. We have guides. We have the official SDK that you can use. You can use the official skills because you don't really have to write code anymore and use that to really develop your app. And how do you get started as a host, as a client? Let's say you're developing your own agent host. You basically take, you go to MCP UI, to the website that supports the official client SDK, and use that to build your app with a bunch of other apps built in.

You basically take, you go to MCP UI, to the website that supports the official client SDK, and use that to build your app with a bunch of other apps built in. And another important question is, if I want to affect the spec, if I want to impact the spec, because that's going to be the basis for the new internet. That's going to be the basis for the new web. So if you want to get involved in how the spec is going to evolve and which host is going to support it and what are we going to support in the spec, then you can go into the official MSTP Apps Repository. Like we said, it's an open repo. You can just propose issues and PR to that. But more importantly, please join the Discord. We have a working group Discord that's dedicated just for the MSTP Apps Working Group inside the MCP Committee. And this is where decisions are being made or announcements are being made. And we have the Community Discord where we have hundreds of implementers from chats and hosts and apps and from the community just talking and raising questions and helping each other. So please be part of this discussion.

We said a few things in the last 20 minutes that might sound scary about where people actually use browsers or apps the way that we were used to. But it's not scary. It's actually a new opportunity that we're hoping that you're excited about to take our existing applications, rethink the core user experience that we're aiming for, and then break apart this monolithic app into a web of apps, you can think of it as atoms, that we can actually bring back together using an agent to mediate this whole thing for us and help us reason about it. And with MSTP Apps, even this early in the state of the new web, we can write it once and run it everywhere. We don't have an iOS versus Android situation from the start. So what does the future look like? We're not at Jarvis just yet. But with MSTP and MSTP Apps in particular, we can create really rich user experiences and interfaces that seemed impossible just a few months ago. So thank you. Thank you very much. Good seeing you.

I think that the first question I have for you is, what are some of the best uses of MCPUI or MCP apps that you've seen? So maybe some of your favorite instances of it? I think something that we see because it's already a few months in the wild, it's very interesting that the most performing or the most valuable apps that we see are actually the creative apps, like Repl.it or Lovable or Excalidraw, because they fit really nicely with the flow of the chat. So you write something and then you say, OK, show me in Lovable or build something in Excalidraw. So these are the apps that people are actually using and loving. That really fits into the flow.

Fantastic. I haven't thought about that because I've used vibe coding tools like V0 or Level, but to be able to maybe see a preview in the chat window before it actually writes the app, that's really cool. Do you have an example? Yeah, I think obviously that's probably one of my favorite use cases, just because it's really cool and fun. The other one is kind of the productivity angle. We see that most of the apps are actually productivity apps, the ones that are actually being submitted. And it's cool for a bunch of reasons, because if you look at dashboards in particular, these huge beasts that we had until now, it was really hard to navigate. But now it's really simple to just get that specific chunk of what it is that you're trying to do and just get that out of the way.

And I think for me personally, when I use apps, that's the first thing that I enjoy. That's amazing. I mean, it sounds like a new way to even have a tutorial for an app. Like you're saying, instead of being presented with a giant dashboard, now the user just prompts and they get exactly the thing. They don't have to click around or try to find the thing that they need. That's really cool.

There's a lot of questions about security. There's a question of how do we do authentication? Let's actually start there. Is there anything in the spec for logging in a user or maintaining state across sessions or across components? Yeah. There are a few mechanisms at work. I would say that it's the main one is just to proxy the request outside through the host. So the idea there is that apps should most of the time use tool calls, and those tool calls are actually executed by the host.

I see. So the creator of the MCP server is kind of in charge of that. As long as they've implemented OAuth, at that point they can just have user sessions. So they know who the user is. Is there anything in the spec that gives them the context or the history of the chat so they can see previous components or that kind of thing in the window itself? So an MCP app, that's just an extension to the MCP protocol, meaning that everything that's allowed or possible over MCP is possible with an MCP app.

So they know who the user is. Is there anything in the spec that gives them the context or the history of the chat so they can see previous components or that kind of thing in the window itself? So an MCP app, that's just an extension to the MCP protocol, meaning that everything that's allowed or possible over MCP is possible with an MCP app.

So an MCP server author can get whatever it can get from the MCP spec, even if it's using an MCP app. I want to refer to a question about the security but from the HTML part of it. There was a question about running HTML in a third party HTML in a host. That's obviously risky, but MCP apps, as part of the spec, the host is running it in a secured iframe.

Everything that goes into and out of the iframe goes through post messages, and the iframe can't interact with the chat itself. So everything is like a black box. If the app had access to history that maybe wasn't pertaining to the app itself, that could be a security breach as well. The developer gets to control what they have access to, but the host is the one that limits it. As front-end developers, we have an edge in the MCP apps world because we already think in a micro front-end way, and MCP apps are some sort of micro front-ends living in one big host.

Okay. So basically, the developer gets to control what they have access to. But the host is the one that limits it. Host app. Okay. I see. Great. Let's see. There's a question about how easy it is to get started. Let me try and find it. Essentially, like let's say we're already front-end developers, we already know React. What's the learning curve to build an MCP app? Can we use what we know? Yeah. It's exactly the same as building a web app, basically. You can just replace all the stuff that you used to do directly for the server to really do it through the host and through the model. But just like an extra superpower that you didn't have until now, you don't need to build your own connection to chat GPT or GPT 5.5. You can just use the host and use the user's data and their own servers. So for example, if you want to schedule an appointment for your application, you can now just do it through the host and tell it, okay, use the MCP server of the specific host. I would even say that as front-end developers, we have a little bit of edge in the MCP apps world because we already think in a micro front-end way, and MCP apps are some sort of micro front-ends living in one big host.

So if you know how to design micro front-ends and these islands, you know how to design and build MCP apps. The next talk is about micro front-ends, I believe. It's a good segue. It's a good segue. Let's see. I mean, this kind of gets into the question that was asked earlier about authentication, but does the spec include anything for maintaining state or is that really just up to the server implementer? Yeah, that's a good question. It already contains something in regards to keeping context within the host. So the idea there is that, let's say something happened in the app and I want the model to know about it for the next turn. So there is already an API to set context for the model for the next turn. There's also an upcoming feature of maintaining some kind of private state for you to store whatever it is that you want for the next time you're rendered. And there's also, currently, the pattern is to just store stuff on local storage or anything else that is already available to you as an app in a browser. Right.

Sorry, there's a really good question here that I don't want us to miss. Yeah, go for it. Which one is it? The within-app MCP apps adoption will cause engagement drops as users favor LLMs over websites, by Sergey. And I think the reason that I think it's a really important question is because MCP apps is really cool as a frontier spec, but as we get into mass adoption of it, we get to these questions from the providers, right? Because the Shopifys and the Amazons of the world, they ask, wait a second, but I can't control the user journey. I can't upsell anything. I don't know even if the user looked at something. And the entire model that's based on eyeballs and based on user browsing through the website, that's going to break. And I think that the important idea here is that MCP apps actually help the brands. So instead of just sending the data, they can send chunks of the UIs. People are going personal assistance. A lot of the traffic is going to come from the Geminis and Chagipites of the world and less from the Chromes of the world. And MCP apps actually help bridging this gap, right? So it just helps with that. It doesn't impact that. Definitely. A lot of questions here. If there's any that you see, definitely call them out. I'm going to try to pick one next.

Yeah, I think there are questions about cost. Yeah, so increased token usage. Some people have said, instead of using MCP servers, we just use a CLI. With MCP UI, it doesn't exactly have the same carryover. So yeah, what do you think about increasing token costs or how does this work? Yeah, so MCP versus CLI, I think it's a big discussion we can have. They're not really competing. They're more complementary in a way. But I think in general, the idea here is that MCP apps are actually saving you tokens in a way because you don't need to pass this huge chunk of text anymore. You just pass this HTML, which isn't actually part of the conversation. So it's completely out of the token spend. You just get what you need to see without this extra overhead. And it's also important to remember that this isn't specifically for ChatGPT or Cloud or anything else. This is supported across a wide range of open source hosts that use local models.

So for example, LibreChat that we saw earlier, Goose support sets. So you're not actually bound to big providers with their token spend. You can actually use your own provider. That's good to know. So I've used like Quin36 or Jemma4. Do you know if they've been trained on it yet or is it really just a tool call? It's a tool call. Tool calls, okay. Okay, nice.

Yeah, I mean, we can go to this next one. We kind of talked about the security earlier, but the concept of running a third party HTML inside the session opens up a new attack surface. How can we ensure the security in this case? So I think I was referring to that MCP apps is being rendered in a secure iframe. So it's not really rendering HTML inside the host. It's completely abstracted from the host. That makes sense. And to kind of talk about the previous question, you mentioned like it can send HTML. Is it also possible to send a remote URL or a URI of where the HTML is and can that be rendered?

So in MCPUI, like the original spec, there was an option to just send a URL to be rendered in an iframe. Okay. We kind of phased that out for a number of reasons. We might put it back if there is enough demand, but it's also still possible to send an HTML that just loads a script. So you can still separate developing the server from developing the UI. You would just put that bundle, whatever you want. You can imagine that there are conflicting interests between the apps that want to send as much of their content as possible and the hosts that want to maintain it visually consistent and they want to audit everything. That's the reason that we compromised on raw HTML that the host can actually vet before they present it. That makes sense.

I think we did cover on the rising costs, but this next one, how will MCP apps work with the new standard proposed by Google WebMCP? I don't know if I've seen this. Can they benefit each other? Are you working with them or is it similar? So we hinted to that in the talk as well. We're working very closely with WebMCP folks at Google. WebMCP is actually, it's complimentary to MCP apps because WebMCP is a way for agents to interact with websites as a source of truth, whereas MCP apps is how to send parts of the websites to the chat. So it's like on two edges of the spectrum. We actually work very closely with them to have this one complete narrative of how an agent interacts with UI and shows back the UI to the user. So again, it's complimentary and it's not contradictory. It would probably be like a shim to transfer between them. Okay. All right.

So many questions. Let's find a good one. Yeah. So there's a question here about wouldn't we be better off using a protocol for agents to interact with websites better and just it's tied to WebMCP, which is this proposed API. But the idea that, I think the philosophy that we're trying to drive is that websites as the source of truth, as we know them today, are going to give way a little bit to personal assistance as the entry point to the web. So doubling down on a protocol that will allow agents to interact with websites, that's something that's very, very short term. That's something that's meant to bridge only this period in time where websites are still the source of truth. Right. And if you look at Google, we have AI mode now, which is probably going to be like the main way for you to access the browser. So we are moving towards checks. Yeah.

Do we know if it does AI mode have MCP app support or is there been any talk or is that WebMCP or? No. So we are, as I said, working with Google and Google is adopting MCP apps in a bunch of their products, Gemini included. I see. Whether or not it will be in search or in what capacity is still to be. Okay. I get time for one more question. Is there a list of awesome MCP apps or maybe even a list of example code repos where people can find examples and start building their own? Yeah. In the repo, in the Xtapps repo that we showed you have a list of dozens of example apps that really show all the capabilities of the specs. So it's really recommended to check them out. And there's also like a thousand apps in Chattopiti and a few hundred apps in Cloud. So you can check them out there and see what is possible. Yeah. Fantastic. The future looks bright. Thank you so much for your talk. Thanks for having us.