MCP Apps vs A2UI: Which Agent UI Standard Should You Use? (April 2026)

Two agent UI standards launched within weeks of each other in late 2025: MCP Apps and Google’s A2UI. Both add interactive interfaces to AI agents, but they take fundamentally different approaches. One is about developers building tools for agents to invoke. The other is about agents generating interfaces on their own.

TL;DR: MCP Apps are developer-built applications that extend agent capabilities. External developers (Figma, Asana, Slack) build tools that agents invoke during conversations, and those tools render interactive UIs in the chat. A2UI lets agents generate UI at runtime to visualize data and present information based on conversation context. MCP Apps are for building external tools. A2UI is for agents projecting dynamic interfaces.

What MCP Apps Are

MCP Apps are developer-built tools that extend what agents can do during conversations. External developers build applications that agents invoke when users need specific functionality. When an agent calls one of these tools, the host loads the app’s UI into a sandboxed iframe directly in the conversation.

Think of MCP Apps as plugins for AI conversations. The developer controls the entire implementation: the UI, the logic, the data handling. When a user asks ChatGPT to “create a Figma design” or “add a task to Asana,” the agent invokes the corresponding MCP App, which renders its interface for the user to interact with.

The MCP App Extension (SEP-1865) reached stable status on January 26, 2026, and is the first official extension to the Model Context Protocol under the Linux Foundation. The ext-apps SDK is at version 1.6.0 as of April 2026. MCP Apps currently run in Claude (web and desktop), ChatGPT, VS Code GitHub Copilot, Goose, Postman, and MCPJam.

You build MCP Apps by writing code: web UI components (Resources) and Tools served by an MCP server. The output is a bundled web application that the agent invokes when appropriate. The examples directory includes starter templates for React, Vue, Svelte, Preact, Solid, and vanilla JavaScript.

What A2UI Is

A2UI (Agent to UI) lets agents generate user interfaces at runtime. Instead of developers building every possible UI upfront, the agent decides what interface to show based on the current conversation context. The agent generates A2UI JSON describing the UI it wants to display, and your client renders it using native components.

This flips the traditional model. In a normal app, developers build the UI and the agent fills it with data. With A2UI, the agent builds the UI itself, choosing which components to use, what data to display, and how to structure the interface.

You define a catalog of pre-approved components (buttons, cards, charts, text fields), and the agent composes them into interfaces. Your client maps each component to its native implementation: React on web, Flutter on mobile, Lit for web components. The same A2UI JSON from an agent renders across platforms.

A2UI is already in production at Google in Opal, Gemini Enterprise, and Flutter GenUI. The ecosystem has grown to include integrations from AG2, Vercel’s json-renderer, and Oracle’s Agent Spec.

Google released A2UI in December 2025 under Apache 2.0. The stable release is v0.8, with v0.9 in draft as of April 17, 2026. Version 0.9 adds a new Agent SDK, client-defined functions for validation, client-to-server data syncing for collaborative editing, and a shared web-core library that simplifies building browser-based renderers. Official renderers exist for React, Flutter, Lit, and Angular, with community renderers in a dedicated ecosystem section. The project has 14.2k stars on GitHub.

Side by Side

	MCP Apps	A2UI
Purpose	Extend agent capabilities with external tools	Let agents generate UI for data visualization
Who controls the UI?	Developer builds the interface	Agent generates the interface at runtime
Built by	External developers (Figma, Asana, etc.)	The AI agent itself
What you ship	Complete application (bundled web app)	Component catalog + renderer
When UI is created	Build time (developer writes code)	Runtime (agent generates JSON)
Use case	Tools in conversations (forms, dashboards, workflows)	Dynamic data presentation (charts, summaries, visualizations)
Where it runs	Inside AI conversations (ChatGPT, Claude, VS Code, Goose, Postman)	Any app where agents need to show UI
Standard body	Linux Foundation (MCP)	Google (Apache 2.0)
Stable version	SEP-1865, January 2026	v0.8 (v0.9 draft)
Renderers	Any web framework (React, Vue, Svelte, Solid, Preact, vanilla JS)	React, Flutter, Lit, Angular

When to Use MCP Apps

Use MCP Apps when you’re building a tool that extends what agents can do. If you have a product or service that users should be able to access from within AI conversations, MCP Apps let you build that integration.

MCP Apps work well for:

• External products and services: Integrate your existing product (like Figma, Asana, Slack) into AI conversations
• Specialized workflows: Build tools for specific tasks (form builders, data analyzers, project managers)
• Controlled experiences: You define exactly how the UI works, what the user can do, and how data flows
• Cross-host distribution: Ship one app that works in ChatGPT, Claude, VS Code, Goose, and Postman

The tradeoff is that you’re building and maintaining a full application. You control the implementation, which gives you flexibility but requires ongoing development work. MCP Apps also only run inside hosts that support the extension, so they’re scoped to AI conversations rather than general-purpose agent contexts.

If you’re building an MCP App, sunpeak is an open-source MCP App framework that includes a local inspector replicating the ChatGPT and Claude runtimes, pre-built components, and a testing framework for unit, E2E, and visual regression tests. You can scaffold a project and start developing without connecting to a live AI host.

npx sunpeak new sunpeak-app
cd sunpeak-app && pnpm dev
# Inspector at localhost:3000

When to Use A2UI

Use A2UI when you want agents to generate their own interfaces for presenting data and visualizations. If your agent needs to show different UIs based on what the user is asking for (charts for data analysis, forms for data collection, summaries for reports) A2UI lets the agent choose the right interface dynamically.

A2UI works well for:

• Dynamic data visualization: The agent decides how to visualize data based on what makes sense (charts, tables, cards)
• Context-aware interfaces: The UI adapts to the conversation. Different questions get different layouts.
• Cross-platform agent experiences: The same agent-generated UI renders natively on web, mobile, and desktop using framework-specific renderers
• Internal tools: When you control both the agent and the client, A2UI lets agents compose UIs from your design system without building each screen by hand

The tradeoff is that you’re delegating UI control to the agent. You define the component catalog, but the agent decides what to show. This requires agents that understand when to use which components, and careful catalog design to give them the right building blocks. A2UI v0.9’s client-defined functions help with this by letting the client validate agent-generated UIs before rendering.

A2UI is a protocol, not a framework. You’ll need to integrate a renderer (Google provides official implementations for React, Flutter, Lit, and Angular) and define your component catalog.

Can You Use Both?

Yes, and it’s becoming more practical. A2UI v0.9 lists MCP as a supported transport alongside WebSockets and REST, so an agent could generate A2UI JSON and deliver it through an MCP tool call. You could build an MCP App that uses A2UI to render agent-generated content inside the conversation iframe.

That said, this is a niche pattern. If your use case is “agent picks which charts to show,” you probably want A2UI with your own client. If your use case is “developer builds a tool that agents invoke,” you want MCP Apps. The overlap exists mostly in scenarios where you need both developer-built structure and agent-generated content within the same conversation.

The Bigger Picture

MCP Apps and A2UI represent two different models for agent interfaces.

MCP Apps follow the extension model. External products and services (Figma, Asana, calendars, project management) get integrated into conversations through developer-built applications. The developer controls the implementation, the agent controls when to invoke it. Six hosts support MCP Apps today, with more adopting the standard.

A2UI follows the generative UI model. Instead of developers anticipating every possible interface upfront, agents generate the right UI for each moment based on conversation context. The agent controls both what to show and how to show it. Google, AG2, Vercel, and Oracle have adopted the protocol, and the ecosystem continues to grow around the v0.9 draft.

Both are open standards. Both are in production. The choice depends on whether you’re building a tool for agents to use (MCP Apps) or letting agents generate their own interfaces (A2UI).

Sources:

• MCP Apps Overview
• MCP Apps Extension GitHub
• A2UI v0.9 announcement
• A2UI GitHub
• A2UI.org
• VS Code MCP Apps Support
• Introducing A2UI: An open project for agent-driven interfaces