MCP Apps: Primitives, discovery, and the Future of Software - Pietro Zullo, Manufact, Inc

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

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

I'm sure most people here listening to this talk know what an MCP is. MCP has been around for quite some time, since 2024. For a full year there was, 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—quite some time, more or less

since the end of 2025. But when I talk to companies and people in general, I see that many people don't understand what they are, and don't understand they can build them, and 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 going to know about this, and you're going to be ready to build your first, or iterate, on your MCP server and app, and you're going to 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, my company. We build open-source SDKs and DevTools for MCP, and the MCP cloud called Manufact.

Open-source SDKs by the name of MCP use allow developers to build servers, 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 8 million-plus downloads across our SDKs, and we have 10k stars on GitHub. Also open-source, but the separate product is the inspector. It's an open-source inspector, again, something comparable to the official inspector from the model context protocol maintainers, that allows you to test these MCP servers and apps specifically 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 submitted, and many other features that are completely specific to MCP.

Of course, we really believe in MCP. So let's look a bit at the history of MCP and how did we get there. So MCP was launched in 2024, and by the end of May 2025, Ido Solomon and Liad Hozef started working on MCP UI, which is this way to kind of have MCP servers return UI components.

Then this was, like, 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 we have 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 this proposal, and ChatGPT at some point released the App SDK, which is a way to create these interactive MCP apps, so basically MCP servers that also return UI elements. Also, by the end of 2025, quite silently, both ChatGPT and 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 only allowed for design partners. But things have changed, and I'm happy to talk about this later.

In January 2026, MCP UI, let's say, converted to MCP Apps. MCP Apps is now the official extension of the model context protocol that allows you to return UI elements within MCP servers. So this timeline is kind of an explanation of how the protocol evolved.

And I think 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, a huge move by the model providers, 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 situationright 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 a—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 following way. Much of this is very similar to MCP. The model is in the host of the tools. The tools are in an MCP server. 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, but 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. I'm going to talk more about that later. The way this works is that MCP

declares UI resources at the initialization time. When the model calls the tool and it populates the arguments of the tool, 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, like, the basics of MCP Apps. I think that many, many times they've been talked about. I think today I wanted to show a bit more of 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 allows.

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 going to 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, cannot really introspect in real time what is going on in the UI. But the protocol mandates this state, 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 an MCP use syntax that makes this a bit 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, the message prompts the tool, and the tool shows the UI. The state 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, using

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, 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 a stray blazer pro. And you can, of course, link the click of this button, "Learn more," to the primitive send follow-up message.

And this will send a message to the chat itself, and the model can start giving you more information about the stray blazer pro shoe, in this case. 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 choice to send it or not. While OpenAI is a bit more integrated in this sense, it directly sends the message to the model and starts streaming immediately the answer to that message.

This is a very cool feature. So again, we have the tool, and 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, in live, take those partial input and update the UI incrementally.

So as you see in this case, we see that the

tool inputs are being populated dynamically or gradually, and the UI reacts accordingly. I have a very cool demo about this just later in a video, where I think one of the coolest demos of MCP Apps

uses exactly this pattern. So you can, for example, imagine, like, you could have a UI component that renders something, like an SVG, and there is MCP Apps doing that. We also seen, we actually created a Remotion MCP App where we use Remotion to create a video with React, and we render the Remotion video inside the widget in real time as the tokens stream in.

Another thing you can do is, from the widget itself, you can call other tools. So first of all, you can call the tool, of course,

in 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's there in the MCP server.

Again, the primitive is very simple. This code on the left here is always from MCP use.

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

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

your private information. And MCP Apps allow you to do that. So when you call a tool, you return a widget which is populated with some arguments, but you can return other outputs as well. As in normal MCP servers, the return of an MCP tool is a 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 is 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 this is what the UI will show.

So this is a card showing the information, private information 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 this UI card, and we can even return 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, allow, like, experiences 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 another set of functionalities which I think are minor, or let's say less

counterintuitive or less advanced. Here we show the request display mode, which basically your MCP App widget is displayed in line with the tool call, but it can even put full screen. So the full chat is going to be your MCP widget, and the input box is going to be overlaid on top of the widget.

And for instance, this is very cool for video editing. You can imagine a widget showing some graphical interface, and you can chat it to improve what's shown inside the widget, and the model can directly stream into the widget you're looking at.

It can also be put in picture-in-picture or inline, which is the normal case. There's other primitives that allow you to open external links from the MCP widget itself. 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, and many other things.

So I wanted to show you here a few videos of MCP Apps, because so far I've just been showing

some mockup that I created for this presentation. But this is, for example, in Cursor, we're using the MCP App. Cursor is one of the clients that supports MCP Apps. And as you see here, our MCP App returns the analytics of the Remotion MCP server app that I was talking to you about just before.

And for instance, this is very useful in analytics. For instance, we use Posture MCP a lot, and the Posture MCP will show you a UI element with your analytics so that you, as a human, can understand what's going on, but the model itself can read those analytics and go do its job on the code that you're writing.

On Claude, so this is the demo I was telling you about. So here we're using the Excalibur MCP server, and here you will see the streaming functionality that I mentioned just before. So you can see here that Claude is first reading some instructions that are returned as tool by the Excalibur MCP server.

And 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 animation around how those tokens are shown. As you see here, this is like a mermaid syntax that is sent into the tool, and the UI updates as the tokens are streamed in.

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

And this is, again, ChatGPT using the Manufact MCP App, showing the same analytics that I was showing you above. And as you see here, the rendering is a bit better in ChatGPT. It was better. Basically, this is very similar to how it uses.

Maybe 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. And

these three, I think, are the main that people are using. And of course, all the different versions of Claude and ChatGPT. So both Claude Cowork, Claude Desktop support MCP App, ChatGPT and Codex support MCP App, and Cursor, both in the agent mode and in the normal side chat supports MCP App.

But there's many more that support MCP App, such as VS Code and countless others. And I think it's actually interesting to mention here that another thing you can do, you might be developing your MCP server, and 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, the MCP, you can return a UI element only for those hosts that actually accept and can render those widgets. And this is not really a big deal because most known MCP App clients, so MCP clients 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

some of the information was returned in the widget, but maybe you want to give it to the model if the widget is not shown. So this is something also MCP user helps you with, with some primitives that

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

Again, a little idea of how you can build these MCP Apps with MCP use. We are one of the most popular SDKs to build these MCP Apps. And the way we design our SDK is that basically you design your MCP server as you always did.

So you have 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, the widget file is just a React component. You can also use your existing UI components, and it will be compiled into HTML and CSS, and then returned and linked to the tool. We have a skill, and we have a template.

You can just run mpx create mcp-use up, and it will give you a template that you can serve.

So let's talk about distribution and discovery, which I think it's, of course, a very important topic. Maybe even less known that 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 a bit about this as well.

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

Claude, since a couple of weeks, they have a self-serve submission form for team and enterprise accounts. And also Cursor allows you to submit their MCP server.

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 submitted in all these three stores, so it doesn't need to return a UI or server to be eligible for submission.

And the three processes to get your App submitted is different, and they have different speed. So it's going to take maybe a bit more on Claude for now, and ChatGPT instead is speeding up a lot the acceptance of these Apps.

And again, the process is 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 the correct arguments.

And once this is done, they're going to scan the authentication as well. So if your server requires authentication, you have to declare it, and you need to make sure that it works. There's a few more different steps which are details for all the providers.

But it's important to say that once your App is submitted, it's going to be partially manually, partially automatically tested. So you will have to provide some test cases and some test prompts, and then it will be either accepted or rejected.

And if accepted, you're going to be able to publish it and make it available on the stores that you can find on chatgp.com/apps, on the connectors directory on Claude, or on the Cursor directory. Again, we did many submissions, and we tried to make this process easier.

So if you want to submit your App, I think you should go to manufacture.com where we vet your App to make sure that it's ready to be submitted. So we check, and we try to do all the checks that those clients will do in the submission process.

And also we run, we generate some of the submission artifacts that you need to submit, like screenshots and test cases, for you 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 going to 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 is the only client that actually does this. But for all Apps in the stores, when Claude is like assigned a task that doesn't have a specific tool to do, it will actually search in the MCP registry for theright connector to do the task.

So imagine what this means for your particular product. There's many, of course, active users on those applications, 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.

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

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

So that was my descriptive part of the talk. I just want to

say I think it should be kind of clear by now how important it is to be on these stores. I can bring my experience. Being on the store brought us a lot of traffic. And 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 possibility to share the context between my codebase and my different connectors. And this to me is so important. For instance, one workflow that I often run is 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 codebase if I'm using this from Claude Code. And I can basically pull the meeting notes with some customer feedback and feed it back 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 closes the Linear ticket. And I mean, in an ideal world, it would even send an email back through MCP to the customer saying, "Oh, this is fixed." But maybe we're not there yet. But that's definitely true. And in fact, just a few days ago, Paul Graham, the founder of Y Combinator, said, "AI apps are the new browsers."

And in this case, the AI apps are Claude Code, Codex, Claude Cowork. And I fully agree with this. If you think about it, Google Search, in a way, has been 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, all those operations are going to be moved to the chat as well.

So in a way, I think that if AI apps are the new browsers, MCPs are the new website. And as a website, they can return a UI with MCP Apps.

So again, I don't want to look at your dashboard anymore. I want to use it in Claude. And if any dashboard, I want to see it in the Claude Code application. So ship on MCP App. Thank you very much.

I hope you enjoyed the talk, and I hope there's many questions about this. And super happy to help. By now, I'm a very expert on the topic. So thank you very much. Have a good one.