For two years the hard part of an agent was getting it to do something. The last mile — getting it to show something richer than a wall of text — was hand-rolled in every app. Within two months at the turn of 2026, the two labs with the most leverage each shipped a standard for that last mile, and they disagree in a way that's worth understanding before you pick.
Google announced A2UI on December 15, 2025, Apache-2.0, as an open project for agent-driven interfaces. Six weeks later, MCP Apps landed as the first official extension to the Model Context Protocol, backed by Anthropic and OpenAI and built on the community MCP-UI work. Both solve the same sentence — let an agent return interface, not just text. They solve it in opposite directions.
The split: who owns the pixels#
MCP Apps sends code. A server declares a UI resource at a ui:// URI — bundled HTML, CSS, and JavaScript — and the host fetches it, renders it inside a sandboxed iframe, and talks to it over postMessage JSON-RPC. The UI is, effectively, a small web app the server author controls end to end. Whatever the browser can draw, the server can ship.
A2UI sends data. The agent emits a declarative JSON tree describing what to render — a card, a form, a chart — and the host renders it with its own native component catalog across Flutter, Angular, or React. The agent may only reference components the host has pre-approved; no HTML, CSS, or JavaScript crosses the boundary. In A2UI's own framing, it's UI as data, not code.
That is the entire fork, and it's a bet on ownership. MCP Apps hands the server the pixels. A2UI keeps them with the host.
"Declarative and safe" reads as strictly better than "arbitrary code in a sandbox." It isn't. The real trade is expressive ceiling against consistency floor.
What each bet costs#
Because MCP Apps ships real web code, it wins on expressive range — 3D, bespoke charts, custom interactions, anything. It pays for that three ways: iframe overhead on every render, aesthetic drift (each app looks like a foreign embed in your product), and a standing sandboxing burden, because you're rendering untrusted output and containing it is now your problem. Google's own comparison post is blunt that iframe reliance can produce "fragmented user experiences with aesthetic inconsistencies and performance hurdles."
A2UI inverts every one of those. Nothing executable crosses the wire, so the untrusted-code problem largely disappears; the host draws with its own widgets, so everything matches the product's design system and runs at native speed. The cost is a genuine ceiling: an A2UI agent can only render what the host's catalog already exposes. A server author cannot ship a widget the host never anticipated. Safety and consistency arrive together — and so does the limit.
Neither is the "correct" answer. If your surface is a consumer chat product where brand coherence and performance are the whole game, the ceiling is a feature. If you're shipping a developer tool whose value is a novel visualization, the ceiling is a wall.
The tell that this isn't winner-take-all#
The most useful signal came from Google, and it's the reason to treat this as a layering question rather than a bake-off. Google published an "A2UI over MCP" pattern that carries A2UI's native rendering over MCP's tool transport — bypassing the iframe entirely. MCP handles what it's already good at, tool and data connectivity; A2UI handles the rendering, natively, in the host's design system. The post sketches three integration patterns, including serving fixed A2UI payloads as plain MCP Resources for things like privacy notices and config forms — cacheable, predictable, zero iframe.
When the company that shipped one of the two standards publishes the guide for running it on top of the other, the market has told you the frame. This is not MCP Apps versus A2UI the way MCP, A2A, and AG-UI occupy different layers of the same stack. It's two rendering strategies that compose.
How to actually choose#
Start one level up. If your agent renders inside a single app you fully own, you may not need either standard — a component-mapping library like the Vercel AI SDK or Tambo is less machinery and keeps the widgets in your codebase. Portable UI standards earn their complexity when the same agent has to render across surfaces you don't control: a third-party MCP client, an embedded assistant on someone else's page, several frontend frameworks at once.
Once you're there, the decision reduces to the split. Reach for MCP Apps when expressive freedom is the point and you can afford the iframe and the sandboxing — a rich, self-contained mini-app the server owns. Reach for A2UI when consistency, native performance, and data-not-code safety matter more than an unbounded palette, and you're willing to render only what the host exposes. And if you find yourself wanting both — native rendering and MCP's connectivity — that's not indecision. Google already wrote the pattern for it.
