Markdown source

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

Source Video

Local Cache

Transcript

Hello y'all. My name is Pedro. I'm the co-founder of Manufact. And uh 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. 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 2024.

For a full year, it was a it became very uh say frequent talk amongst developers and companies that were rushing to build these MCP servers. MCP apps are less familiar concept. They've been around also for some quite some time uh more or less uh since the uh 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 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 going to know about this and you're going to be ready to build your first or iterate on your MCP uh server and app and you're going to be able to share it with the world in a more efficient way brings you more customers and more users. A little words about me and the Manufact uh my company. Uh we build open source SDKs and the tools for MCP and MCP cloud uh of the Manufact. Open source SDKs uh by the name of MCPUs uh allow developers to build servers um >> [clears throat] >> 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, uh the other 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. The Manifold 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 emails, 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 a bit in the history of MCP and how did we get there. So, MCP was launched in 2024, and by the end of uh May 2025, Idel Solomon, the other co-founder, started working on MCPUI, which is this way to kind of MCP servers that return UI components.

Then, uh this was like many many people started talking about MCPUI because this is like such a great opportunity to ship UI with your MCP servers to agents. So, it is interactive experiences where the agent is calling tools, but it's showing UIs to the user. This created a lot of movement. Many people enjoyed uh this proposal, and the ChatGPT at some point released the app SDK, which is a way to create these interactive MCP apps. So, basically MCP servers also return UI elements. Also, at the end of 2025, quite silently, both Character AI and Cloud released and opened their stores for MCP.

These stores allow you to submit your MCP server and have [clears throat] a one-click install experience for your users. For the most time, these stores were closed in such that 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 I say converted to MCP apps. MCP apps is now the official extension of the Model Context Protocol that allows to return UI elements within MCP servers. So this timeline is kind of an explanation of how the protocol evolved. And I think still 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 probably OpenAI, Perplexity, and basically every LLM client out there to say, "Oh, MCP is the way and we [clears throat] 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 uh that are now being submitted to Character AI and Cloud apps for Character AI and connectors for Cloud increasingly being accepted.

As I was saying in the beginning, this was uh each one of them was gated behind design partnership because the ecosystem was very young, but now it's a GPT and called are both accepting more and more apps. So, this is a 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 a in the host owns the tools. The tools are in a 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 a 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 uh more about that uh later. The way this works is that MCP uh declares UI resources at 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 uh 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 a like the basics of MCP ops. Uh I think they're many many times uh they've been talked about. And 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 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 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 uh introspect in real time what is going on in the UI. But the protocol mandates 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 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, 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 into the model itself. So, then 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 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 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. Or 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 Trey Blazer 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 send a message to the chat itself, and the model can start giving you more information about the Trey Blazer Pro shoe in this case. Um clients have different behavior regarding this, and this is true for many of the MCP features. For instance, Cloud 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 model 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 tool inputs are being populated uh dynamically or gradually, and the the UI reacts accordingly.

I have a very cool demo about this just later in a video where in 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 uh MCP apps doing that. 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 the tokens are streaming 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 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 what is there in the MCP server. Again, the primitive is very simple. This is code on the left here is 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 is uh there's private information that you don't want to give to the to the model providers, and therefore, [clears throat] you might want to redact that right? This is like a known privacy issue with MCP servers that you don't want to return and put into the uh >> [clears throat] >> your private information. And MCP uh also allow you to do that. So, when you call a tool, you return a widget, which is populated with some arguments. 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 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 uh and this is what the [clears throat] 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 a uh this this UI card, and we can even return um nothing to the model. But just say, the user is seeing his private information in the widget above.

So, this is a pattern that allows you to, you know, give uh allow it 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 I think are minor or let's say less >> [clears throat] >> intuitive or less 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 chat is going to be your MCP widget and uh 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 a widget showing some uh graphical interface and uh you can chat that we improve the the what's the shown inside the widget and the model can directly stream into the widget you're looking at. It can also be put in a picture-in-picture or in line which is the normal case. Um >> [clears throat] >> there's a other primitives that allow you to open external links from the MCP widget itself.

[clears throat] >> You can listen to the theme of the OS so that you know your MCP app is synchronized in theme with the host your users are using. And there are many other things. So I wanted to show you here a few videos of MCP apps because so far I've just been showing uh uh uh some mock-up that I created for this presentation. Uh but this is for example in Cursor we're using the MCP app. Uh Cursor is one of the clients uh that supports MCP apps.

And as you see here uh our MCP app returns the analytics of the remote 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, we use Pulsar MCP a lot and then the Pulsar 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 and go do its job on the code you're you're writing. Um on Claude, 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 as before. So, you can see here that Claude is first 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 we motion it's one 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 the UI updates as the tokens are streamed in.

There's some of the some of the coolest demos here. By the way, very very useful to draw diagrams as well. Um and this is again ChatGPT um uh using the Manifold uh MCP app uh showing the same analytics that I was telling you above. And as you see here, the rendering is uh is is a bit better in ChatGPT uh it's 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 app. 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 versions of Claude and ChatGPT uh so both Claude Co-work, Claude Desktop support MCP app, ChatGPT and Codex support MCP app. Uh and Cursor uh both in the >> [clears throat] >> agent mode and in the normal side chat supports MCP app, but there is uh many more that support MCP app such as VS code and and and comes as others. And I think it's actually interesting to to mention here uh that another thing you can do you might be developing your MC server and uh you don't know if the host where your users are using the MC server supports or not MC [clears throat] apps.

What you can do is uh since we know what the client is from the metadata that is exchanged uh uh the MC app uh you can um return a UI element only for those um host that actually accepts and can render those um those uh widgets. And then this is not really a big deal because most uh non-MC app clients so uh MC client that don't support MC 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 returning the widget but maybe you want to give it to the model if the widget is not shown. Uh so this is something also MC user helps you with with some primitives that um that allow you to to know if the client uh your MC server is connected to actually supports MC apps or not. Again, um a little uh idea of how you can build these MC apps with MC users. We are one of the most popular SDKs to build these uh MC apps.

The way we design our SDKs that basically you design your MC server uh as you always did. So you have your MC 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 and you can also use your existing uh UI components. And uh it will be compiled into HTML and CSS.

[clears throat] >> And then um returned and linked it to the tool. We have a scale uh we have a template. Uh you can just run NPX create MCP app and uh it will give you a template that you can serve. 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, you're um 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, uh since a couple weeks they have um self-serve submission form for team and enterprise uh accounts. [clears throat] And also Cursor allows you to submit their MCP server set 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 you it doesn't need to return a UI your 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 going to take maybe a bit more on on Claude uh for now uh and uh ChatGPT instead is it's up a lot the acceptance of these uh 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 um And once this is done, they're going to scan the 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 all the providers. Uh but it's important to say that once your app is submitted, it's going to be partially manually or 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 chadigpt.com/apps on the connectors directory on uh cloud or on the >> [clears throat] >> the cursor directory. Again, we we we did the many submissions and we we try to make this process easier. So, if you want to submit your app, I think you should go to manifester.com where we vet your app to make sure that it's um 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 in our cloud directory 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 >> [clears throat] >> 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 Cloud is the only client that actually does this, but for all apps in the stores, when Cloud needs 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 what this means for your particular product. All the people There's many of course active users on those applications or more than 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 a huge wave of uh high intent individuals that want to need your product and will find it uh dynamically and organically on those on those platforms. So this is very important. Cloud does this today and [clears throat] ChatGPT is expected to do this pretty soon. So that was my discrete descriptive part of the talk. I just want to uh uh I think it should be clear by now how important it is to be on the stores. I can bring my experience. Being on the store brought us a lot of traffic.

Personally, as a user of MCP, today I'm checking if a product has an MCP server and that's for me is like the most basic buying decision. I run most of my day-to-day work on Cloud Co-work or Cloud 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 so important. For instance, one workflow that I 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 code base if I'm using this from Cloud Code.

And 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 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. Um but uh but this is definitely true.

And in fact, 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 AI apps are Cloud Code, Codex, Cloud Code Work. 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 cannot only search, but you can also do stuff in the real world, >> [clears throat] >> all those all those um operations are going to be moved to the chat as well.

So, in a way, I think uh that if AI apps are the new browsers, the ChatGPTs are the new websites. 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 Cloud. And if any dashboard, I want to see it in the Cloud Code application. So, ship an MCP app. Thank you very much. I hope you enjoyed the talk and I'm uh hope there is any questions about this and super happy to help. Um by now, have a very uh expert on the topic. So, thank you very much. Have a good one.