A2UI over MCP lets agent tools return native JSON UI payloads while sandboxed MCP Apps handle custom stateful workflows securely across hosts.
What A2UI Over MCP Actually Does
Agent tools have historically returned text or structured data that the host application then had to render on its own. A2UI changes the contract: a tool can return a native JSON UI payload describing the interface it wants shown — form fields, buttons, tables, selection lists — and the host renders that description using its own components. Because the payload is declarative JSON rather than markup or executable code, the same tool response can display correctly in a chat client, an IDE panel, or a mobile agent without the tool knowing anything about the host's rendering stack.
Running this over MCP means the UI description travels through the same tool-call channel the agent already uses to invoke capabilities. The model requests an action, the tool responds with both a result and a UI to represent it, and the host draws that UI. This keeps the interface generation close to the logic that produced the data, so what the user sees stays consistent with what the tool actually returned.
When to Reach for MCP Apps Instead
Declarative payloads work well for stateless, one-shot interactions, but they fall short when a workflow needs to hold state, respond to intermediate input, or run custom logic between steps. MCP Apps address this by running a sandboxed application the host hands control to for the duration of a task. The app manages its own state and interaction flow while the sandbox constrains what it can reach, so custom behavior does not translate into custom access to the host or the user's machine.
Reach for an MCP App when the interaction is genuinely stateful — a multi-step configuration, a wizard that branches on prior answers, or a view that updates continuously as underlying data changes. Reach for A2UI when a tool simply needs to present its output in a native, host-agnostic way.
Choosing Between the Two Patterns
The decision usually comes down to how much interaction lives inside the UI itself versus how much stays in the agent loop. Use this rough split:
- A2UI payloads — displaying results, collecting a single form of input, or offering a fixed set of choices that go straight back to the agent.
- MCP Apps — workflows that maintain internal state, need custom rendering the declarative schema cannot express, or should run client-side logic without further round trips.
- Both together — a tool returns an A2UI summary and offers to open a full MCP App when the user wants deeper, stateful control.
Practical Guidance for Building With Them
Design tool responses so the UI degrades gracefully: a host that does not yet support A2UI should still get usable text, and one that does gets the richer native view. Keep declarative payloads focused on presentation and let the agent own the decisions, so the same tool behaves predictably across hosts. For MCP Apps, treat the sandbox boundary as a feature — assume the app cannot and should not touch host resources directly, and pass anything it needs explicitly.
Because both patterns move interface concerns into the tool layer, test each tool against more than one host early. That surfaces rendering gaps and state-handling assumptions before they reach users, and it keeps the same agentic tools portable as new hosts adopt the protocol.