AI Engineer Europe 2026
Beyond Components: Designing Generative UI for MCP Apps
Read the talk
Beyond Components: Designing Generative UI for MCP Apps
Ruben Casas of Postman examines the progression from static components to declarative interfaces and runtime-generated code, explaining why MCP apps provide essential containment and how shared human-agent workspaces could reshape interaction.
From a talk by Ruben Casas
At a glance
Ideas worth remembering
Distinguish where an interface runs from what the model generates; deployment inside a super app and the degree of UI generation are separate architectural choices. 3:57
Static component systems let agents provide data and properties to developer-built interfaces, as illustrated by the AG UI protocol and Goose auto visualizer. 6:17
Declarative UI uses descriptors such as JSON, YAML, or Python to assemble approved components, balancing personalization with design-system consistency, predictability, and potentially lower token costs. 7:29
Generative components can create HTML, CSS, and JavaScript at runtime, but their flexibility introduces the same fundamental trust concerns associated with executing unfamiliar code. 9:35
MCP apps provide a delivery boundary with sandboxing, authentication, tool calling, and interface-agent messaging for both third-party and first-party generated UI. 11:41
The Excalidraw MCP App demonstrates a possible direction beyond visualization: shared artifacts that humans and agents can edit together, while the ultimate interface model remains unresolved. 14:28
The interface has not caught up with the model
Ruben Casas traces a shift from early workflows in which developers prompted ChatGPT for component code, copied the result, corrected it, and repeated the process. He identifies GPT-5.2 and Opus 4.5 as models that demonstrated stronger performance on long-horizon work and high-fidelity UI generation, producing functional interfaces quickly and sometimes with meaningful design judgment. 0:15
His personal example is a blog rewrite generated from a single prompt. The resulting interface included a search box, a blur animation, and accessibility features he had not explicitly requested. For Casas, the significance is not simply that models can emit more code: they can sometimes make frontend decisions that exceed what their human operator initially specified. 1:30
That capability creates a central tension. If models can generate sophisticated frontend code, why do agent products still rely so heavily on text conversations and largely static interfaces? Casas frames contemporary interaction as direct access to a powerful new computer whose mature graphical interface language has yet to emerge. 2:49
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate where the interface runs from what the model creates
Casas distinguishes two competing deployment patterns. One puts chat inside many existing applications; the other concentrates interaction in an agent-centered super app such as ChatGPT, Claude, or Gemini, with MCP apps rendering third-party interfaces inside that shared environment. He treats both as plausible transitional arrangements and explicitly declines to predict which consumers will ultimately prefer. 3:57
The more consequential architectural question is separate: what is the model actually generating? Whether an interface appears inside a standalone product or a super app does not determine whether the model supplies component properties, assembles a declarative layout, or writes executable frontend code. This distinction makes it possible to compare interface-generation strategies without confusing delivery location with generation capability. 5:05
In the static component pattern, developers build components in advance while the agent orchestrates a tool call and supplies data or properties. The client then renders the corresponding predefined component. Casas emphasizes that this resembles familiar client-rendered interfaces: the primary difference is that an agent produces or selects the inputs. 5:05
He offers two concrete implementations. The AG UI protocol provides an SDK that maps a registered client tool to a React component, passing tool-call properties into the component. Goose, an MCP client, includes Goose auto visualizer, which organizes incoming data and matches it to visualization components created beforehand by the Goose team. 6:17
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Declarative UI expands flexibility without abandoning constraints
Declarative UI retains developer-built components and the surrounding design system but changes what the agent produces. Instead of only providing properties for a predetermined component, the agent emits a descriptor, such as JSON, YAML, or a Python representation associated with FastMCP2. A translation or rendering engine interprets that descriptor and assembles the final interface from approved components. 7:29
The gain is more dynamic composition and personalization within established visual and functional boundaries. Casas compares this approach to Netflix-style server-driven personalization, where different people receive different homepage arrangements even though those arrangements still use the same underlying Netflix interface elements. 7:29
He points to JSON Render, built by Vercel, as an example of mapping components through JSON and YAML to produce dynamic interactions. The essential limitation remains deliberate: the language model generates the descriptor, not the components themselves. As a result, the interface can vary in arrangement and content without becoming unconstrained executable code. 8:35
Casas presents declarative generation as a strong practical balance for the current moment. It preserves design-system consistency and predictable output while offering more flexibility than direct component-property mapping. He also suggests that this approach can be faster and potentially cheaper because the system does not need to spend as many tokens generating an entire interface from scratch. 9:35
Generates interface descriptors
Model-generated descriptors become personalized interfaces through a rendering engine and predefined components.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Runtime-generated components introduce a new trust boundary
The next step in Casas’s progression is generative components: allowing a model to write frontend code on demand at runtime. Rather than constraining the output to a descriptor interpreted by a fixed rendering engine, an agent can invoke the same model through reverse sampling or call another model to generate HTML, CSS, and JavaScript for delivery to the client. 9:35
Casas describes a Postman experiment built around a weather agent. In a single tool call, the system accesses a weather API, creates a joke, and generates the HTML, CSS, and JavaScript for an imaginative interface. In his description, the result does not depend on a predefined component catalog or an intermediate component-translation layer. 10:34
The additional freedom comes with a serious security limitation. If application developers do not automatically trust third-party code, they should not automatically trust model-generated code presented directly to users either. Casas therefore argues that runtime-generated interfaces require a delivery architecture with an explicit boundary, containment, and sandboxing. 10:34
Initiates runtime generation
A tool call invokes a model to generate executable interface code, which must cross an explicit sandbox boundary before client delivery.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:00
[upbeat music] Okay.
- 0:16
Hello, everybody. So I know I am the person standing between you and your lunch. And- [laughing] But this is gonna be a very interesting talk that combines the l- the previous two talks into the future.
- 0:27
And that's what I want to talk about today. So back in, uh, November 2022, what we used to do was we used to go to ChatGPT and ask ChatGPT to, um, create a component, and we would just copy, paste.
- 0:41
You had to ask, reply in code blocks, then, you know, again, fix it, repeat. And this is what I call the poor man's vibe coding. And we have come a long way.
- 0:52
Um, it, it kind of worked. Um, it was very exciting. You could get, um, models to could actually build some UI for you. Um, and surely that was not gonna write better code than me, right?
- 1:07
And then things improved very, very rapidly, very, very fast.
- 1:12
What happened last year, and if you are aware what happened in the, the, the last months of 2025, was this acceleration, an incredible inflection point, uh, where things changed, and it will go down in the history books as, uh, things changed very fast all at once.
- 1:30
And this is in part because of the release of, uh, two very important models, which were, uh, 5.2 ChatGPT... Sorry, it was, yeah, uh, GPT 5.2 and Opus 4.5, and they were not just very good at, uh, most of the tasks, uh, long-horizon tasks.
- 1:49
They were also very good at high-fidelity UI generation, and they were producing very good working UI, sometimes thoughtful, sometimes really, really good, and also very fast.
- 2:05
Now, I experienced this when, um, I tried one of these models, uh, tried to rewrite my, my blog. I know people have used this in, uh, more creative ways, but I just tried, you know, a single prompt, rewrite my blog, and then it did this, which I didn't ask for.
- 2:19
Um, it created a nas- nice search box with a blur animation, with accessibility out of the box. And then that's when I realized that in the space of, of three years, uh, from when ChatGPT was released to today, we went from, uh, you know, a few lines of code is great, uh, it can...
- 2:41
It runs. Oh, it now can write better front-end code than me.
- 2:49
And you know what? I, I don't mind. No, no ego. Uh, it's just reality. Um, so here is a question. If these models are so good at writing UI code, why are we still stuck in this mainly old paradigm of mostly static UI?
- 3:08
And w- where is, where is that Jarvis moment that we've been talking about, um, earlier? Where are my floating UI windows that appear and disappear, and why are we not there yet?
- 3:19
So my name is Ruben Casas. I am a staff engineer at Postman, and I've been looking at, uh, UI and generative UI for the past year, and I've been working with MCP Apps as well.
- 3:28
And today, I want to show you what we're doing today and where we're going in the future.
- 3:33
So the news are we have a new computer, and as, uh, Andrej Karpathy put it, interacting with this new computer is like talking to the terminal. You have direct access to this operating system, and the GUI has not been invented yet.
- 3:48
It's like we are in the '70s, where everything was just text. And we have a super intelligence, but we don't have a mature interface language. And today, we are still trying to figure out what is this new interface for, for this computer.
- 4:05
And people ask, "Is it chat?" I'll show you what we, what we're doing today. And actually, this was a very recent, uh, tweet last week where people were complaining that most SaaS companies have been adding, um, chat to their, their homepages, and everybody's just putting chat everywhere.
- 4:21
And, and that's, that's fine. I don't have a problem with chat. Um, it's not the final UI. It's okay for now.
- 4:29
But the question is, if it's not chat, then, then what is the interface, uh, for this computer? On the other hand, as we have seen with, um, ChatGPT, uh, MCP Apps, is there is another, uh, thought which is we will have one app or a super app to rule them all.
- 4:47
And this is where, uh, MCP Apps comes in, where instead of putting all of these chat windows into your homepages and into every single app that you use, we will have a super app like ChatGPT or Claude or Gemini where you will be interfacing with most of the, the UI and the websites that we have today.
- 5:05
Um, and this is good. Uh, this is the way we're using, uh, uh, MCP Apps today to, to render third-party UI inside one agent environment. Now, these two options both could be valid, and, and I believe these are part of the evolution towards finding out what is a new interface for, uh, that computer.
- 5:26
And to be honest, I don't know which one is gonna be the, the final one. Consumers will tell us. Um, but one thing is these are two different questions.
- 5:34
Um, the question is, uh, where does the, uh, UI run? So in this case, is it third-party UI, a super app, or in this case, chat everywhere? But most interesting is what is the model generating?
- 5:47
And this is what I want to talk about today in terms of how are we generating, uh, this UI. And we have seen this. We have mostly static, declarative, and, uh, generative UI.
- 5:57
And I'm gonna describe, uh, briefly this one. So we have, um-
- 6:02
To start with the, the static components way of rendening, rendering UI, which is what most agents, uh, do today. Uh, the agent is just an orchestrator. The agent makes a tool call via MCP apps or the direct, um, agent tool call.
- 6:17
Then we will have some parameters and data passed to predefine static components that have been created by developers, and this is very similar to we- what we have been doing, uh, for the past twenty years with, with UI.
- 6:32
Um, and then the client renders a component. And if you see here, it's very similar to just getting a server to send some data and then the UI will be rendered by the client.
- 6:41
But in this case, the agent will be, uh, generating that data and the props, uh, to, to do this. And some examples that we have today are, uh, the AG-UI protocol.
- 6:51
They have an SDK where you can register a, a client tool that, uh, maps to a React component. The tool call will receive some props. Those props will be mapped to a static component that then will be rendered to, to the user.
- 7:06
Another example is, um, Goose. Um, Goose is a, an MC- an MCP client where you can, uh, try most of the MCP features, and Goose has this really interesting feature called Goose Auto Visualizer, where you can just pass any type of data to Goose, and Goose will try to match that data, organize it, and then pass it
- 7:25
to a set of predefined components that the Goose team have created. In this case, we have a few, um, interesting components that you can, uh, use to visualize your data.
- 7:35
So that's the static way. That's the most common way of, uh, generating UI today. But I have seen an evolution recently, uh, what we call now declarative UI. And declarative UI, uh, takes it to, uh, at, at the next level.
- 7:51
So we will still have some predefined static components that developers build, and it contains your design system and all these co- uh, um, components that you have. But instead of the agent just passing the props and the data, the agent uses a, a descriptor that could be either JSON or YAML, or I've seen Python as well with,
- 8:10
with Fa- FastMCP 2, and they have a, a descriptor in, in Python that maps to these predefined static components. And then you have this translation rendering engine that takes those descriptors and convert them into the final UI.
- 8:26
How is this different? Well, in this case, um, it is more dynamic. There are still static components, but it's more personalized. And you... If you look at this and you think that this might look familiar as well, it's because it is not new.
- 8:41
Um, Netflix has been doing this for a long time, uh, since the, the personalization and server-driven UI era, where when you go to the Netflix homepage, you will get a, a UI that is completely personalized to you.
- 8:54
But that's still mapped to the Netflix components and UI elements. Another very good, um, tool that I've seen recently is, uh, JSON Render. Uh, JSON Render is, uh, being built by Vercel, and it is a way to map your components using JSON and also YAML, they released the YAML support recently, and create all of these very dynamic,
- 9:18
very good UI interactions, uh, that you can use today. But now, JSON Render, uh, still, they say, is constrained to your static components. And yes, they're still static components.
- 9:35
The LLM is not genere-generating those components. The LLM is generating the JSON. However, I think in, at this point in time, uh, declarative generative UI is probably the perfect balance today in terms of flexibility and consistency, because you still want your design system, you still want to have, uh, predictability of what the UI is gonna be generated,
- 9:58
also faster and also potentially cheaper at this point, uh, so you don't create and, uh, use a lot of tokens to create the UI. But as I mentioned at the beginning, why, why are we still stuck here?
- 10:09
And what's the next level? I think the next level will be, uh, generative components. And generative components, uh, goes into like the, the premise I, I put at the beginning, where the models are good at writing front-end code.
- 10:22
They are good at writing React. They are good at React, uh, creating JavaScript, CSS. And the question is why we don't let them just write that on demand at runtime.
- 10:34
What could possibly go wrong with that, right?
- 10:38
This model, um, of generating the UI uses the agent capabilities, and in this case, you can also use a tool call, but instead of calling this, uh, layout rendering engine, you can call the same model with reverse sampling, or you can call another model that will generate the HTML, CSS, JavaScript on demand, and then it will be
- 10:58
passed to the client. I did this experiment, um, I work at Postman on this experiment where I created, uh, this weather agent that goes to the API, the weather API.
- 11:08
It creates a joke. It creates the HTML, CSS, JavaScript, all in one tool call. And you get presented with this random but very, uh, imagi- imaginative UI, where everything is created by the agent.
- 11:22
There is no component. There is no translation.
- 11:25
So there is, of course, a problem with this approach. Uh, and the problem with this approach is, uh, if we don't trust third-party code, well, we should not trust, um, code that is being generated by LLMs and then just present it to the user.
- 11:41
Uh, generative UI and, and this level of generative UI needs a distribution model. And this distribution model requires a boundary, requires containment, and requires a sandbox, which is what we were talking about earlier.
- 11:55
This is where I think MCP apps matter a lot, because MCP apps are the best, uh, delivery mechanism, uh, for, uh, generative UI. We have the features provided by MCP, including authentication and tool calling and message passing between the UI and the agent.
- 12:14
Uh, it's sandboxed by default with that double iframe. It's the default for third-party UI delivery today. That's this become the standard. And one interesting thing is it's not just for thir- third-party UI.
- 12:27
It can also be used for first-party UI. And this is why I think what Anthropic is doing with the, the visualizer feature is very interesting strategically speaking, because they could have just created their own rendering, um, and, and architecture mechanism for delivering this in, uh, interaction in, in Claude, but they decided to go with MCP
- 12:52
Apps because MCP Apps provide most of those, um, features that I mentioned earlier, uh, out of the box. So if Anthropic decided to use MCP Apps for their first-party UI, uh, you can ask yourselves why cannot we do the same?
- 13:06
It is, um, a very, very strong protocol, and especially when the UI is being generated on the fly by the agents, by the, the code, uh, coding models, then is the best, um, mechanism for delivery.
- 13:21
Now, today is probably not the final form, and people keep saying, "Is chat the final form? Is MCP Apps the final form?" We're st- we're still trying to figure this out.
- 13:36
And the obvious future is probably too obvious, and we said about, "Where is my Jarvis? Where is my floating windows?" And if you think about it, that's the obvious th- thing that people would think how we would look like if we were generating or creating a new, uh, user interaction.
- 13:57
But what I think is we don't have enough imagination yet and, and this analogy, uh, I heard recently is very interesting. When, when, uh, radio came out in the '30s, um, the, the, the first ra- um, sorry, the, the TV came out, the first, uh, TV shows were radio shows with cameras because they could not imagine what
- 14:22
you could do with this new technology. So this new technology that we have today is very similar when television came out and we are still in the radio era where we don't know all the amazing things that we will do in the future with this new media, with this, the new power that we have with the, with
- 14:39
the new computer, and we can see that we cannot even imagine what it's gonna look like. Uh, of course, this is a speculative, but what do I think is actually gonna happen is we are gonna be moving, uh, beyond components and more towards a collaboration, uh, true human agent collaboration.
- 14:59
If you haven't heard about the, uh, Excalidraw MCP App, uh, definitely check it out because the Excalidraw MCP App is not just for, um, output and visualization of diagrams.
- 15:12
The Excalidraw MCP App does something very interesting, which it creates a, a shared artifact. It creates a canvas where a human and an agent can collaborate together into a shared space where you can go back and forth with the agent and ask, you know, "Change this," but you can also click around, modify the UI the way that
- 15:33
you are used to, and that becomes the new way of interacting, the new way of experiencing the, the agent, um, powers. And, and at the moment, again, we are very constrained to our imagination and, and I believe these agents are very, very powerful for just, to just use them as a orchestrator and a delivery mechanism to show
- 15:56
me some visualizations. So I believe beyond components, it will be the future of generative UI will be more a collaborative experience where, yes, we will have some generative UI, but that UI is gonna be super personalized and it's gonna be collaborative.
- 16:16
So we, we are still early. Um, we don't have the answer. People say, you know, "What is, what is the f- future of, uh, the user interaction, the user interfaces?"
- 16:27
We don't know yet, but we can shape that future, uh, and create this, uh, new computer. And that's me. Thank you so much, uh, for listening to this. [audience applauding] You can find me, uh, and ask any questions.
- 16:42
Thank you. [upbeat music]