Beyond Components: Designing Generative UI for MCP Apps — Ruben Casas, Postman

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

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

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

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

Casas identifies MCP apps as a strong delivery mechanism for generated interfaces because the protocol supplies capabilities such as authentication, tool calling, and message passing between the interface and the agent. He also highlights default sandboxing through a double iframe, presenting containment as a prerequisite for distributing dynamically generated UI rather than an optional enhancement. 11:41

Although MCP apps commonly deliver third-party interfaces into an agent environment, Casas argues that the same architecture can support first-party UI. He points to Anthropic’s visualizer feature as an example of choosing MCP apps instead of inventing a separate rendering and delivery mechanism, suggesting that teams can reuse the same protocol features for interfaces generated within their own products. 11:41

His longer-term proposal moves beyond displaying generated widgets toward human-agent collaboration around shared artifacts. The Skeletro MCP app illustrates this direction through a canvas that both a person and an agent can modify: the user can request changes conversationally while also clicking and editing the interface directly. The interface becomes a shared working space rather than a one-way visualization of agent output. 14:28

Casas explicitly characterizes the future as uncertain and speculative. Chat, MCP apps, floating windows, and familiar component metaphors may all represent intermediate forms rather than the finished interaction model. His strongest prediction is narrower: generative interfaces will become more personalized and collaborative as builders discover interaction patterns that make fuller use of agent capabilities. 13:06