MCP Apps and A2UI both put interactive interfaces inside agent conversations, but they work in opposite ways. This article compares rendering, security, host support, and cost, then gives a decision table that matches each standard to the jobs it handles best.
Your agent just produced the right answer, and it still shows up as a wall of text. Two open standards now fix that problem, and they disagree on almost everything else. MCP Apps ships a small web app that runs inside a sandboxed iframe. A2UI sends a JSON blueprint and lets the host draw it with its own native components. One gives the server control of the pixels. The other gives that control to the client.
This comparison looks at rendering, security, host support, and day to day cost, then ends with a decision table you can apply to your own agent today. Every claim about the two specs comes from the official MCP documentation, the A2UI project site, and Google's developer blog, checked in October 2026.
The split is easy to state. MCP Apps treats a UI as a resource that a server hands over. A2UI treats a UI as data that an agent describes. Everything else in this article follows from that single difference.
MCP Apps began as proposal SEP-1865 in November 2025. Anthropic, OpenAI, and the maintainers of the community project MCP-UI wrote it together, building on MCP-UI and on OpenAI's Apps SDK. In January 2026 it became the first official extension of the Model Context Protocol, with its own spec dated 2026-01-26 in the ext-apps repository.
The mechanism reuses two ordinary MCP primitives, a tool and a resource:
_meta.ui.resourceUri, which points to a ui:// resource.text/html;profile=mcp-app.postMessage, using a JSON-RPC dialect with ui/ methods such as ui/initialize.
Since the payload is plain web code, you pick the framework. The ext-apps repository ships starter templates for React, Vue, Svelte, Preact, Solid, and vanilla JavaScript. The App class from @modelcontextprotocol/ext-apps is a convenience wrapper, not a requirement. You can implement the postMessage protocol yourself if you want fewer dependencies.
A2UI, short for Agent-to-User Interface, is Google's open standard, released under the Apache 2.0 license in December 2025. The agent does not send HTML. It streams declarative JSON that names components and their data. The client keeps a catalog of components it trusts, validates every message against that catalog, and maps the result onto a native UI tree.
Google's own tagline sums it up: safe like data, expressive like code. The spec sits at v0.9.1, with v1.0 at the candidate stage as of October 2026. Renderers exist for Angular, Flutter, and Lit, and Google already uses A2UI in Opal, Gemini Enterprise, and the Flutter GenUI SDK. Payloads travel under the MIME type application/a2ui+json.
💡 Mental model: MCP Apps is "ship a miniature website." A2UI is "send a blueprint and let the host build it from approved parts."
With MCP Apps, the server decides how things look. The host only provides the frame, the sandbox, and the message bridge. That gives you the full web platform: D3 charts, WebGL scenes, PDF viewers, maps, a CesiumJS globe, or a Three.js scene. Those are real examples in the ext-apps repository, alongside a budget allocator, a cohort heatmap, and a system monitor.
The price is visual drift. An iframe does not inherit the host's design system for free, so your app can look like a foreign object inside the chat. It also carries the weight of a browser page: its own scripts, its own memory, its own load time.
With A2UI, the client decides how things look. The agent says "a card with a title, a chart, and two buttons," and the client renders its own card, its own chart, and its own buttons. Theming comes from the host, so the result matches the surrounding app on web, mobile, or desktop without a webview.
The format is also friendly to language models. It is small, structured, and designed for streaming, so a model can emit a UI step by step while the user watches it assemble. The limit is the catalog: if the client has no component for what you want, you cannot invent one inside the payload.
Here is the comparison in one view:
| Dimension | MCP Apps | A2UI |
|---|---|---|
| Payload | HTML bundle at a ui:// URI | JSON messages |
| Who renders | AI host, inside a sandboxed iframe | Client, from an approved catalog |
| Who controls looks | The app developer | The host application |
| Action flow | App requests host-mediated tool calls | Client validates and routes declared actions |
| Streaming | Tool inputs can stream to a preloaded app | Built for incremental generation |
| Platforms | Web first | Web, mobile, desktop |
| Status | Official MCP extension | Google-led, Apache 2.0, spec v0.9.1 |
Two very different threat models sit behind the two designs. One isolates code. The other refuses to accept code at all.
The app runs in a sandboxed iframe, so it cannot reach the parent page's DOM, read the host's cookies or local storage, or redirect the parent page. All traffic crosses the postMessage boundary, and the host decides what passes. The defense has several layers:
ui:// resources up front, the host can prefetch and review a template before any tool runs._meta.ui.csp field lists the external origins an app may load from._meta.ui.permissions.
A2UI skips the sandbox question by never executing anything. The renderer accepts only validated JSON, and only components that exist in the catalog. Google calls this capability-based security: the client renders trusted components and nothing else.
That does not make A2UI automatically safe. A button in the catalog can still trigger an action, so the client must authorize every declared action and validate every payload. The allowlist protects the UI. It does not protect your business logic.
Both standards move content from an agent to a screen, so both inherit the agent's weaknesses. A model that reads a hostile web page can be talked into rendering a convincing fake form, whether the form lives in an iframe or on a catalog card. Treat tool calls triggered from any generated UI as untrusted input: check permissions on the server, scope tokens narrowly, and require confirmation for anything that spends money or changes data.
Host support is the strongest argument for MCP Apps right now. The official docs list Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam, and Archestra.AI, and ChatGPT renders them too. The MCP project maintains a client matrix, and it matters: support for app UI is narrower than support for basic MCP tools. A client that calls your tools may still ignore your ui:// resource.
If you build a host yourself, you have two paths. The @mcp-ui/client package provides React components, and the SDK's App Bridge module handles sandboxed rendering, message passing, tool call proxying, and policy enforcement.
A2UI support depends on the renderer your client ships, not on a list of chat products. You pick Angular, Flutter, or Lit, define your catalog, and wire up a transport. The A2A protocol carries A2UI between agents, and AG-UI, the CopilotKit protocol, advertises day-zero compatibility. A2UI can also ride on MCP: payloads arrive through resources/read for static screens or tools/call for dynamic ones, under an a2ui:// URI scheme.
Pick by job, not by brand. This table shows how teams tend to split the work:
| Scenario | Better fit | Why |
|---|---|---|
| Product integration with auth and account state | MCP Apps | The server owns permissions and state |
| Approval flows for spending or data changes | MCP Apps | You ship a stable, tested surface |
| Rich media, maps, 3D, PDF viewers | MCP Apps | Full web platform in the iframe |
| Data exploration with changing layouts | A2UI | The agent chooses chart, table, or card |
| Generated reports | A2UI | Flexible layouts, changing data |
| One UI across web and mobile | A2UI | Same payload, native rendering |
| Close match to a design system | A2UI | Host theming applies |
Choose it when you already own a web product and want it inside the chat. Your server holds the logic, you control every pixel, and you can reuse React components you already have. Choose it too when speed of prototyping matters: a single HTML file is enough to ship.
Choose it when the screen is not known in advance. An agent that answers "show me last quarter" with a table today and a chart tomorrow suits a catalog far better than a hand-built page for every case. Choose it as well when your client is native, or when your security team will not approve third-party scripts in the chat.
The choice is not exclusive. Google's developer blog, published June 17, 2026, describes three integration patterns, and they change what "pick one" means.
a2ui:// scheme. No iframe is needed.For most teams, a split by job works. Put stable, high-stakes surfaces such as approvals, settings, and account views in MCP Apps. Put flexible, generated surfaces such as reports and summaries in A2UI. Serve both from the same MCP server so your agent keeps one connection. Pattern 3 is your escape hatch when a host lacks a renderer.
Review the split every quarter. If a generated surface starts needing custom charts the catalog cannot draw, that screen has outgrown A2UI and belongs in an MCP App. If an MCP App keeps getting rebuilt for each new data shape, it is a candidate for a catalog instead.
Writing A2UI payloads by hand gets tedious, and a language model that returns strict JSON is a natural drafting partner. GPT 5 Structured on PicassoIA is built for exactly this: you define a JSON schema, and every response conforms to it.
model field: gpt-5, gpt-5-mini, or gpt-5-nano.instructions. List the components your client accepts, with their properties.prompt, for example "an order summary with a table of items and a confirm button."json_schema to the message schema from the A2UI spec. Use json_schema rather than simple_schema, because the simple version does not support nested objects.reasoning_effort at minimal for quick drafts. For dense layouts, raise it and increase max_output_tokens, because high reasoning can use up the budget and return an empty response.💡 Treat the model's output as a draft. Your renderer's validator is the final gate, exactly as the A2UI security model intends.
Want to compare drafts from other models? Claude Sonnet 5 and Gemini 3.5 Flash are available on PicassoIA too, so you can run the same catalog and prompt through each and keep the cleanest result.
Whichever standard you pick, your agent's screens need pictures: product thumbnails, hero banners, header photos for reports. MCP Apps render images as plain HTML. A2UI renders them through whatever image component your catalog defines. Either way, you need the images first.
PicassoIA puts the generators in one place. Seedream 5 Pro, Flux 2 Pro, Imagen 4, and PicassoIA Image all sit in the text-to-image collection, so you can run one prompt across several models and keep the version that fits your layout. PicassoIA also exposes its generators through MCP connections, so an agent that speaks the protocol discussed above can request images directly.
Open the collection, write a prompt for your next card or banner, and generate a few variants. Pick one screen from your own agent, give it a real image, and see how quickly the visual side catches up with the logic.
