MCP Apps: Primitives, Discovery, and the Future of Software

Hello, y'all. My name is Pietro. I'm the co-founder of Manufact. And, uh, today I want to talk to you about MCP Apps. Specifically, we're gonna talk about the primitives, so how these apps are built, how they work, and what they allow you.

How to distribute MCP Apps, so what is behind the discovery mechanisms of MCP servers and apps in general, and, uh, why I think you should care about this because this is how all software will be used.

So I'm sure most people here listening to this talk know what an MCP is. MCP has been around for quite some time, since two thousand twenty-four.

For a full year, it was, uh, like a very, uh, say, frequent talk amongst developers and companies that were rushing to build these MCP servers. MCP apps are a less familiar concept.

They've been around also for some, uh, quite some time, uh, more or less, uh,

since the, uh, the end of two thousand twenty-five. But when I talk to companies and people in general, I see that many people don't understand what they are and, uh, don't understand they can build them.

And, uh, specifically, they don't know how to distribute them,

MCP apps, but also they don't know the new way to distribute MCP servers as well. So I hope by the end of this talk, you're gonna know about this, and you're gonna be ready to build your first or iterate on your MCP, uh, server and app, and you're gonna be able to share it with the world in

a more efficient way that brings you more customers and more users.

A little words about me and Manufact, uh, my company. Uh, we build open source SDKs and Dev tools for MCP and, uh, MCP cloud, uh, called Manufact.

Open source SDKs, uh, by the name of mcp-use, uh, allow developers to build servers, um, clients and agents in an easier way. So we provide an abstraction over the official SDKs that allows developers to ship faster without worrying about how the spec works beneath.

We have eight million plus downloads across our SDKs, and we have ten K stars on GitHub.

Also open source, uh, but, uh, separate product is the Inspector. Uh, it's an open-source inspector, again, uh, something comparable to the official inspector from the Model Context Protocol maintainers that allows you to test these MCP servers and apps specifically, uh, on your local machine.

Once you build, once you test it, we have built the cloud for you to ship. So Manufact Cloud is a cloud vertical for MCP. We provide all the primitives for you to be able to ship MCP servers from your GitHub repo and test them immediately, share them with your team, run evals, run publishing checks to make sure

that your app is ready to be put, uh, submitted, and many other features that are completely specific to MCP.

Of course, we really believe in MCP. So let's look, uh, uh, a bit at the history of MCP and how did we get there. So MCP was launched in two thousand twenty-four, and by the end of, uh, May two thousand twenty-five, Ido Solomon and Liel Joseph started working on MCP-UI, which is this way to kind of let

MCP servers return UI components. Then, uh, this, uh, was, uh, like many, many people started talking about MCP-UI because this is like such a great opportunity to ship UI with your MCP servers to agents.

So build these interactive experiences where the agent is calling tools but is showing UIs to the user. This created a lot of movement. Many people enjoyed, uh, this proposal, and ChatGPT at some point released the App SDK, uh, which is a way to create these interactive MCP apps, so basically MCP servers that also return UI element.

Also, by the end of two thousand twenty-five, quite silently, both ChatGPT and, uh, Claude released and opened their stores for MCP. These stores allow you to submit your MCP server and have a one-click install experience for your users.

For the most time, these stores were closed in the sense they were, um, designed and, uh, only allowed for design partners, but things have changed, and I'm happy to talk about this later.

Um, in January two thousand and twenty-six, MCP-UI, uh, let's say, uh, converted to MCP Apps. Uh, MCP Apps is now the official extension of the Model Context Protocol that allows to return UI elements within MCP servers.

So this timeline, uh, is kind of an explanation of how the protocol evolved. And I think s-- two-- I think two major things happened in this timeline. First, MCP Apps.

MCP servers are not only returning JSON, and that allows much richer experiences. And the second thing, maybe even bigger, is that the stores opened. This was a great, uh, a huge move by the model providers, uh, Anthropic, OpenAI, Cursor, basically every LLM client out there to say, "Oh, MCP is the way, and we want to have a

way for people to publish vetted and quality MCP servers so that people can use them with a one-click install experience."

This is the situation right now with the stores.

The apps that are now being submitted to ChatGPT and Claude,

apps for ChatGPT and connectors for Claude are increasingly being accepted. As I was saying, in the beginning, this was a feature that was gated behind design partnership because the ecosystem was very young.

But now ChatGPT and Claude are both accepting more and more apps.

So this is, uh, uh, this is the moment to publish yours.

So let's see what MCP apps actually are and what you can do with them.

So an MCP app works in the, in the following way. Uh, much of this is very similar to MCP. The model

is, uh, in the host of the tools. The tools are in an MCP server, but the MCP server in this case doesn't return a JSON string again, but it returns a widget in a sandboxed iframe.

So the experience you see is your model is streaming text. At some point, it decides to make a tool call. The tool call is not just returning JSON, it returns a UI just underneath.

And this UI is a sandboxed iframe, so you can, as a company developing these apps, you can put almost whatever you want. But it doesn't end there. Actually, there is a bidirectional communication that happens between the iframe and the host application.

So from the iframe, from the MCP app UI elements, you can send messages back to the host. You can interact in several ways. Uh, I'm gonna talk, uh, more about that, uh, later.

The way this works is that MCP, uh,

declares UI resources at the initialization time. When the model calls the tool and it populates the arguments of the tool, uh, the tool can then populate the arguments of the UI resource, and that can be then displayed and rendered by the client.

As you see here, this is the kind of experience that you can see in an MCP app.

The MCP server returns tool, returns a UI resource that is populated with the tool arguments. And here you see. So without UI, you would see like a wall of text.

The UI allows you to organize the information in a more human-readable way.

So this is, uh, is like the basics of MCP apps. Uh, I think there are many m-- many times, uh, they've been talked about. And today I wanted to show a bit more what you can do because this is not often mentioned, and I think it's very interesting to design new experiences which this new protocol allow.

So first of all, again, the UI is displayed in the chat, and it exposes a communication channel between the UI element and the host application. So the host application will listen for these messages going through these channels and will react accordingly.

So this is the first primitive that I'm gonna talk about, so model context. In the UI, you can show whatever information you want. For instance, in this case, we're showing three articles, but the model doesn't really know.

It doesn't really-- It cannot really, uh, introspect in real time what is going on in the UI. But the, the protocol mandates, uh, this state, uh, or this set state primitive where you can update the state of the model with respect to the UI components.

So from the widget itself, you can call... This is in mcp-use syntax that makes this a bit, uh, easier. The set state primitive, and you can update what the model knows about what's being displayed.

So here we have a little demo that shows this.

Of course, uh, the, the, the message, uh, prompts the tool,

and the tool shows the UI. The state, uh, of the-- of this UI element is that nothing is selected, and the model knows about this. But if you modify the UI state, you can communicate this state change to the model itself.

So that basically, if, for example, here I send another message, the model will be aware of what happened in the UI element. And you can do this by simply setting this, uh, using this, uh, um, this primitive set state and update the state that the model knows about.

UI message. So this is another very cool feature where from the UI element, uh, the UI widget that your tool returns, you can send messages back to the model.

So not only the interaction is I am a user, I have my chat interface, I see the UI, and I want to send another message. Maybe there is some contextual message that you can-- you want to send.

For instance, here we have the same shoe example, and you might want to learn more about Trailblazer Pro. And, uh, you can of course link the click of this button, Learn More, to the primitive send follow-up message, and this will f-send a message to the chat itself, and the model can start giving you more information about the

Trailblazer Pro shoe in this case. Um, clients have different behavior regarding this, and this is true for many of the MCP features. For instance, Claude will display the message in the chat input and tell the user, like the user has the, the choice to send it or not.

While OpenAI is a bit more integrated in the sense it directly sends the mod-- the message to the model

and, uh, and starts streaming immediately the answer to that message.

This is a very cool feature. Uh, so again, we have the tool, uh, and, uh, we have a UI element that's populated from the tool itself, right? If the model streams the input tokens into the tool arguments, you can, uh, in live take those partial input and update the UI incrementally.

So as you see in this case, we see that the, the, the, the, the tool inputs are being populated, uh, dynamically or gradually, and, uh, the UI reacts accordingly.

I have a very cool demo about this just later in a video where, uh, I think one of the coolest demos of MCP apps, uh, in the-- uses exactly this pattern.

So you can, for example, imagine like, uh, you could have a UI component that renders something like an SVG, and there is MCP ser-- MCP apps doing that. Um- We also seen, uh, we actually created a Remotion MCP app where, uh, we use Remotion to create a video with React, and, uh, we render the Remotion video inside

the widget in real time as it tokens the stream in.

Another thing you can do is from the, from the widget itself, you can call other tools. So first of all, you can call the tool, of course, uh, in the, um, in the, uh, the, in the tool that was originally called to gather other data.

But from the UI, for example, you can have a button that triggers another tool call to gather additional data about what, uh, what is there in the MCP server.

Again, the primitives is very simple. This is code on the left here is, uh, always, um, from mcp-use.

This is another very interesting thing that you can do with MCP apps. So sometimes, uh, what happens is, uh, for instance, you, uh, want your MCP server to return certain informations, but you want to, um, not show the full information because maybe it's, uh, uh, it's private information that you don't want to give to the, to the

model providers. Um, and therefore you might want to redact that information, right? This is like a known privacy issue, uh, with MCP servers that you don't want to return and put into the, uh,

um, your private information. And MCP, uh, apps allow you to do that. So when you call a tool, you return a widget which is populated with some arguments, or you can return other outputs as well.

As in normal MCP servers, the, the return of a, of an MCP tool is list of outputs of different types. You can imagine in this case, there is a structured output which is sent into the widget itself, and there's an additional output that can be sent directly to the model.

So something common that you do is you show a very rich UI, like in this case, and, uh, and this is what the UI will show. So this is a card showing the information, private information of, of this person, but the model will only see the information you want.

So there's two types of output, the ones that are shown in the UI, to put it simply, and the ones that are sent to the model. Like a common-- to maybe understand this better, a common pattern that you see is

you show the full information in the UI, and then you instruct the model with a text output of what the user is seeing.

For instance, we return, uh, uh, this, this UI card, and we can e-even return,

um, nothing to the model. But just say the user is seeing its private information in the widget above.

So this is a pattern that allows you to, you know, give, uh, allow like, uh, experiences in, in fields where maybe sharing data to the LLM is not possible because of privacy issues.

In this case, you can show the UI to the user, but the model won't see the data that you display in the UI unless you choose so.

There's, uh, another set of functionalities which, uh, I think are minor or let's say, uh, less, hmm,

counterintuitive or less, uh, advanced. Uh, here we show the request display mode, which basically your MCP app widget is displayed in, uh, in line with the tool call, but it can even put the full screen.

So the full chart is gonna be, um, your MCP widget, and the input box is gonna be overlaid on top of the widget. And for instance, this is very cool for video editing.

You can imagine a, a widget showing some, uh, graphical interface and, uh, you can chart it to improve the, the, what's shown inside the widget, and the models can directly stream into the widget you're looking at.

It can also be put in a picture-in-picture, uh, or in line, which is the normal case. Um, there is a other primitives that allow you to open external links from the MCP, uh, widget itself.

Um, you can listen to the theme of the host so that you know your MCP app is synchronized in theme with the host your users are using. There are many other things.

So I wanted to show you here a few videos of, uh, MCP apps, uh, because so far I've just been showing, uh, uh, some mock-up that I created for this presentation.

Uh, but this is, uh, for example, in Cursor, we're using the MCP app. Uh, Cursor is one of the clients, uh, that, um, supports MCP apps. And as you see here, uh, our MCP app returns the analytics of, uh, the Remotion MCP server app that I was, uh, talking to you about just before.

And for instance, this is very, uh, useful in, in analytics. Uh, for instance, uh, we use Postgres MCP a lot, and then, uh, the Postgres MCP will show you a UI element with your, with your analytics so that you as a human can understand what's going on, but the model itself can read those analytics, uh, and go

do its job on the code that you're, you're writing. Um, on Claude, uh, so this is the demo I was telling you about. So here we're using the Excalidraw MCP server, and here you will see the streaming functionality that I, that I mentioned just before.

So, uh, you can see here that Claude is first, uh, reading the-- some instructions that are returned as tool by the Excalidraw MCP server. And, uh, at some point, it will call the tool which is showing the canvas, and it will stream tokens into the canvas.

And I think Remotion did some of the coolest, uh, animation around how those tokens are shown. Uh, as you see here, this is like a mermaid, uh, syntax that is sent into the tool and the, the UI updates as the tokens are streamed in.

The-- Some of the, some of the coolest, uh, demos here. By the way, very, very useful to draw diagrams as well.

Um, and this is again ChatGPT, um, uh, using the Manufact, uh, MCP app, uh, showing the same analytics that I was, uh, telling you about. And as you see here, the rendering is, uh, is, is a bit better in ChatGPT.

Uh, it was better. Basically, this is very similar to how it uses. Maybe, uh, this is a good time to talk about the client support. There's many clients that support MCP apps.

Some do more, some do less. Uh, and, uh,

these three I think are the main, uh, that people are using. And, uh, of, of course, all the different, uh, versions of, uh, Claude and ChatGPT. Uh, so both, uh, uh, Claude Cowork, Claude Desktop, uh, support MCP app.

ChatGPT and Codex support MCP app. Uh, and Cursor, uh, both in the agent mode and in the normal side chat supports MCP app. But there's, uh, many more that support MCP apps, such as VS Code and, and, and countless, uh, others.

And I think it's actually interesting to, to mention here, uh, that another thing you can do, you might be developing your MCP server, and, uh, you don't know if the host where your users are using the MCP server supports or not MCP apps.

What you can do is, since we know who the client is from the metadata that is exchanged, uh, uh, via MCP, uh, you can, um, return a UI element only for those, um, hosts that actually accepts and can render those, um, those widgets.

And that this is not really a big deal because most, uh, non-MCP app clients, so MC-- uh, MCP client that don't support MCP app will not... will simply not show the widget.

But I found developing these servers many times that if you don't show the widget, you need to return a different output because, um, it-- some of the information was returned in the widget, but may-maybe you want to give it to the model if the widget is not shown.

Uh, so this is something that also mcp-use helps you with, with some primitives that, um,

that allow you to, to know if the client, uh, your MCP server is connected to actually supports MCP apps or not.

Again, um, a little, uh, uh, idea of how you can build, uh, these MCP apps with mcp-use. We are, uh, one of the most popular SDKs to build these, uh, MCP apps.

And the way we design our SDK is that basically you design your MCP server, uh, as you always did. So you have, uh, your MCP server constructor, and then you define tools.

And from the tools, you can simply return widgets

which are automatically registered from this widget file in the resources folder. So whatever you put as a widget file in the resources folder will be registered as a UI resource that you can return from a tool.

And the widget, um, the widget file is just a React, uh, component. Uh, uh, and you can also use your existing, uh, UI components, and, uh, it will be compiled into HTML and CSS

and then, um, returned and linked to the tool.

We have a skill, uh, and we have a template. Uh, you can just run MPX create mcp-use app, and, uh, it will give you a template that you can start from.

So let's talk about distribution and discovery, which I think, uh, it's, uh, of course, a very important topic. Uh, maybe, uh, even less known than how MCP apps work.

I'm talking to many people, and they don't know there's a store for MCP, and they don't know how to submit. So I wanted to talk about-- a bit about this as well.

So the store is like a huge new distribution channels. Again, here I'm bringing the three most popular clients, ChatGPT, Claude, and Cursor, uh, which the three of them, they all support a self-serve submission process.

ChatGPT was one of the first supporting thi-this. Claude, since a couple weeks, they have, um, self-serve submission form for team and enterprise, um, accounts. And also Cursor,

um, allows you to submit your MCP server se--

Uh, the way you submit is different for all three, but basically what happens is that you need to make sure that your MCP app is compliant. MCP apps or servers can be both, uh, submitted in all these three stores, so it, it doesn't need to return a UI or your server to be eligible for submission.

Um, and the three processes to get your app submitted is different, and they have different speed. So it's gonna take maybe a bit more on, on Claude, uh, for now.

Uh, and ChatGPT instead is speeding up a lot the acceptance of these, uh, of these apps. And, um, again, the process is, uh, you link your remote MCP server, they will scan the tool, and they will make sure that all the tools are correctly annotated and have, uh, the correct arguments.

And, uh, um, and once this is done, they're gonna scan, uh, the, the authentication as well. So if your server requires authentication, you have to declare it and, uh, you need to make sure that it works.

There's a few more different steps which are details for all the, all the providers. Uh, but it's, uh, important to say that once, uh, your app is submitted, it's gonna be, uh, partially manually or partially automatically tested.

Uh, so you will have to provide some test cases and some test prompts, and then, uh, it will be, uh, either accepted or rejected. And, uh, uh, if accepted, you're gonna be able to publish it and, uh, make it available on the stores that you can find on chatgpt.com/apps, uh, on the Connectors directory on, uh, Claude or

on the, the Cursor directory. Again, we, we, we did many submissions, uh, and, uh, we, we tried to make this process easier. So, uh, if you want to submit your app, I, I think you should go to manufact.com where we vet your app to make sure that it's, um- Ready to be submitted.

So we check, uh, and we try to do all the checks that those clients will do, uh, in the submission process. And also we run, um, we generate some of the submission artifacts that you need to submit, like screenshots and test cases for you in, in our cloud directly if connected to your MCP server.

Something very, very cool about this is that once your app is in the store, not only can people find it by searching on the store, not only you can send a URL to your customers, and they're gonna be able to install your application in one click.

So you don't have to share that ugly JSON file anymore with your MCP configuration. But it's very important that dynamic discovery of MCP server is happening. Today, Claude, uh, is the only client that actually does this.

But for all apps in the stores, when Claude needs a-- is, like, assigned a task that doesn't have a specific tool to do, it will actually search in the MCP registry for the right connector to do the task.

So imagine, uh, what this means for your particular product. All the p-- There's many, of course, active users on those applications. So more than a billion active users,

which will manifest an intent directly in the chat. And through the intelligence of the model, the model will choose what is the best connector.

Uh, and if you're there, uh, and, uh, you do your work to be the connector that is selected, this is gonna be like a, a huge wave of, uh, high-intent individuals that want to-- need your product and, uh, will find it, uh, dynamically and organically on those, uh, on those platforms.

So this is very important. Uh, Claude does this today, um, and, uh, ChatGPT is, uh, expected to do this pretty soon.

So, uh, that was my descripti-descriptive part of the talk. Uh, I just want to, uh, uh, say I think it should be kind of clear by now how important it is to be on the stores.

It can, uh, bring my experience, uh, being on the store brought us a lot of traffic. And, uh, personally, as a user of MCP, today I'm checking if a product has an MCP server, and that for me is like the most basic buying decision.

I run most of my day-to-day work on Claude Cowork or Claude Code because I love the, the, the possibility to share the context between my code base and my different connectors.

And this to me is, uh, so important. For instance, one workflow there that I often run is, uh, I have my Granola MCP where I have my meeting notes, I have Linear where I track my tickets.

Of course, I'm in my code base if I'm using this from Claude Code, and, uh, I can basically pull the meeting notes with some customer feedback and feed it back in the-- In Linear, maybe I create tickets for the rest of the team.

And then I have the agent that pulls the Linear ticket through the Linear MCP and just starts doing it. Opens the PR and, uh, and, uh, and closes the Linear ticket.

And, uh, I, I mean, in an ideal world, it would even send an email back through MCP to the customer saying, "Oh, this is fixed." But, uh, maybe we're not there yet.

Um, but, uh, but that's definitely true. And in fact, uh, just a few days ago, Paul Graham, uh, the founder of Y Combinator, said, uh, "AI apps are the new browsers."

And in this case, uh, the I-- AI apps are Claude Code, Codex, Claude Cowork. I fully agree with this.

If you think about it, Google Search in a way has been, uh, substituted by looking on ChatGPT. So now that we have connectors where you can not only search, but you can also do stuff in the real world, um,

all those, all those, um, operations are gonna be moved to the chat as well. So in a way, I think, uh, that if AI apps are the new browsers, MCPs are the new website.

And, uh, as a website, they can return a UI with MCP apps.

So again, uh, I don't want to look at your dashboard anymore. I want to use it in Claude. Um, and if any dashboard, I want to see it in the Claude Code application.

So ship an MCP app. Uh, thank you very much. I hope you enjoyed the talk, and, um, uh, hope there's many questions about this. I'm super happy to help.

Um, by now, [chuckles] I'm very, uh, expert on the topic. So thank you very much. Uh, have a good one.