MCP Apps Are Server-Rendered UIs That Agents Generate. Here's What That Means for the No-Code Frontend.

For two years, "agent interface" meant one thing: a chat box. You type, it types back. Maybe it calls a tool and shows you a JSON blob. Maybe it renders a Markdown table if you're lucky.

The MCP 2026-07-28 release candidate changes that completely. MCP Apps (the spec formerly known as SEP-1865, now merged and shipping) lets MCP servers deliver full interactive HTML interfaces that render inline inside any compliant host. Claude Desktop, ChatGPT, whatever. The agent doesn't just answer your question. It builds you a mini-application.

And I don't mean "here's a link to an app I generated." I mean the interface appears *inside the conversation*, sandboxed in an iframe, with bidirectional communication back to the MCP server through JSON-RPC. The tool response isn't text anymore. It's a dashboard, a form, a data explorer, a config panel. Rendered on the server. Surfaced by the host. Interactive immediately.

This isn't an incremental improvement to chat. It's a different category of thing.

How do MCP Apps actually work?

The architecture has three pieces: the Server, the Host, and the View.

The **Server** is a standard MCP server that declares tools and UI resources. The UI resources use a `ui://` URI scheme. Think `ui://weather-dashboard` or `ui://customer-lookup`. These are HTML templates (`text/html;profile=mcp-app`), registered upfront during tool discovery, not returned dynamically in tool results.

The **Host** (Claude Desktop, say) learns about these UI resources when it connects to the server. When the LLM decides to call a tool that has a UI attached, the Host fetches the HTML template and renders it inside a **sandboxed iframe** (the View). Before the iframe even receives data, it goes through an initialisation handshake: `ui/initialize` from the View, host context (theme, capabilities, dimensions) back from the Host. Only then does the tool data arrive, as `ui/notifications/tool-input` and `ui/notifications/tool-result`.

Then the interesting part. The View can call *other* tools on the server. The user clicks something inside the iframe. The View sends a `tools/call` request to the Host. The Host proxies it to the Server. The result flows back to the View. All through `postMessage`. All auditable. All using the same MCP JSON-RPC protocol the rest of the ecosystem already speaks.

Two things matter here that aren't obvious at first glance. First, the UI template and the tool data are separated, and the Host can prefetch and cache the template before the tool even runs. Second, this is progressive enhancement. If a host doesn't support MCP Apps, the tool still works fine. It just returns text instead of HTML. No forking. No separate code path.

What does this mean for no-code frontends?

Here's where it gets interesting for builders.

Right now, if you want to give a user an interface for reviewing support tickets, you build it in a no-code platform. Drag a table component. Configure filters. Set up permissions. Publish.

With MCP Apps, the agent builds the interface on demand. A customer support agent connects to your ticketing MCP server. The user says "show me high-priority tickets from the last 24 hours." The server renders a filterable table *right there in the chat*. No visual builder involved. No platform. No deployment step.

The implications get pretty staggering if you follow them through. An MCP server becomes not just a collection of tools: it becomes a UI factory. Each tool can carry its own interface. A data agent renders a chart. An ops agent renders a command centre. An HR agent renders an approval workflow. All from the same server, all on demand, all inside the conversation.

I've watched no-code platforms spend five years trying to make interface building simpler. Drag-and-drop, AI-assisted layout, component libraries. MCP Apps sidesteps the question entirely by making the agent the interface builder. The user doesn't see a builder at all. They just ask for something, and the interface materialises.

Is this a threat to drag-and-drop builders?

The short answer: partially, but not in the way people think.

If your no-code platform's entire value proposition is "you can build a table view without writing code," MCP Apps is a direct threat. An agent can generate a table view in an iframe faster than a human can drag one onto a canvas, and the generated version is contextually relevant. It already has the right filters applied, the right columns selected, the right data queried.

But here's what generated UIs don't have: persistence, governance, or shared state. An MCP App is transient. It exists inside one conversation. When the chat ends, the interface evaporates. There's no URL you can bookmark. No permission model that says "this team can see revenue data but not PII." No audit log of who viewed what. No way for two people to look at the same dashboard simultaneously unless they happen to be in the same chat thread.

This is the difference between a tool and a platform. MCP Apps are brilliant tools: reactive, contextual, zero-friction. They're terrible platforms: ephemeral, ungoverned, single-user.

What this means in practice is that MCP Apps and no-code frontends aren't really competitors. They serve different moments in a workflow. MCP Apps handle the ad-hoc, investigative, "I need to answer this question right now" interactions. No-code platforms handle the structured, recurring, "this is how our team manages customer data every day" interactions.

The builders who get this right won't pick one and ignore the other. They'll connect the two.

Where's the governance layer?

This is the gap nobody is talking about yet, and it's going to matter a lot once MCP Apps hit production.

The spec provides sandboxing: mandatory iframe isolation, declarative CSP, auditable `postMessage` channels. That's good. It means a rogue MCP server can't steal cookies from your chat client or escape its container.

What it doesn't provide: authentication scoped to the UI, role-based permissions, an audit trail, or any concept of multi-user access. The spec explicitly says the Host handles consent flows for tool calls initiated by the View. But "user clicked approve" is not the same thing as "user has permission to see this data according to organisational policy."

Think about what happens when an MCP App renders a customer table. The server sends *all the data* to the iframe. There's no row-level security. No field-level masking. The Host's consent dialog might ask "Allow this app to call the `query_customers` tool?" but it cannot ask "Do you have permission to see customer 847's phone number?" That level of governance has to live somewhere else.

This is where governed no-code platforms (Stacker, Bubble, Retool) fit into the MCP Apps story. They already solve this problem. They have permission models, audit logs, data residency controls. An MCP server that routes its tool calls through a governed platform's API layer inherits all of that. The UI renders in the chat, but the data never leaves the governed boundary without the right permissions applied.

I think this is the actual architecture that emerges: MCP Apps as the interface layer, governed platforms as the data and permissions layer. The agent generates the UI. The platform enforces who can see what. Neither does the other's job well.

So what do you do with this?

If you're building no-code products right now, MCP Apps should change how you think about your frontend. Not in the "everything is doomed" direction, though.

Start thinking of your platform's interface as one of several surfaces an agent might render into. Your drag-and-drop builder is the governed, persistent, multi-user surface. MCP Apps are the ad-hoc, conversational, single-user surface. Both pull from the same data and permissions layer. Both are valid. They're complementary.

The platforms that win here are the ones that make their permissions engine available to MCP servers. If an MCP App can render a customer dashboard inside Claude and the data comes through your platform's auth layer (with row-level security, audit logging, the works), you've just turned every MCP host into a distribution channel for your product.

That's a much bigger opportunity than "agents will replace frontends." Agents won't replace frontends. They'll generate them, transiently, and the governed platforms will make those generated UIs safe enough to use with real data and real teams.

MCP Apps don't kill the no-code frontend. They give the no-code frontend something better to do: stop worrying about which component library to ship and start becoming the permissions and audit layer every MCP-generated interface needs.