A2UI as MCP Extension

[zeroasterisk]

We are considering working on a MCP Extension for A2UI.

Would this be of interest to you? Give us an emoji 👍 if this matters to you.

[yannj-fr]

There is a real debate to open on terminology with MCP apps. What do we actually want to deliver, is Apps dealing with UI only or more …. A large field for discussions.
Happy to dedicate time and energy on this

[rodincave]

Would it make sense to add this to the MCP Apps extension instead or creating a new one?

[zeroasterisk]

also being discussed... if you have a short but firmly held conviction about how that would work, this is a place to voice it

[binioter-z]

Whether we're talking about MCP Apps in A2UI or A2UI in MCP Apps, combining the two will inevitably put more load on LLMs, resulting in slower response times and a greater risk of errors. But I haven't seen any clear advantages this integration offers over MCP Apps on its own. So what's the point of integrating them in the first place?

[binioter-z]

While an orchestrator can certainly reduce the load on LLMs through metadata and resources, this is essentially adding engineering complexity to compensate for the overhead introduced by the integration itself. The value of integration shouldn't just be 'theoretically feasible' — it needs to be backed by clear use cases and measurable benefits. Otherwise, we're just adding system complexity and maintenance costs without getting a worthwhile return.

[yannj-fr]

So you also consider that a2ui must live aside mcp apps or as a derivative of the current mcpapps ext (e.g additional mime) ?

[binioter-z]

Honestly, my main concern is that I haven't been able to think of a real-world business scenario where integrating A2UI and MCP Apps would make genuine sense. Without a concrete use case, it's hard to justify the added complexity.

[yannj-fr]

So you actually never used a ChatGPT app ? Or any app with a custom ui build over mcp servers? I have a few of exemple like any time series, when consumed in the end by a human is better to be visual, agentic commerce....

[binioter-z]

Of course I have — I use them regularly. But I'm still trying to understand the specific scenarios where A2UI and MCP Apps need to be tightly integrated. Could you walk me through your examples in more detail? For instance, with time series data, how exactly does the integration between A2UI and MCP Apps work in practice, and what would break if they were kept as separate layers?

[dongai-z]

We think this is a great idea! One question on the output contract between Agent and end-user:
In the "A2UI over MCP" model, once an Agent calls an MCP Server and receives an A2UI JSON payload, what is the recommended way for the Agent to deliver that result to the user?
For example:

• Should the Agent wrap the A2UI JSON inside a Markdown code block (e.g., json ... ) as part of a conversational response?
• Or should it emit the raw A2UI JSON directly, expecting the client to detect and render it?

[domfarolino]

We are considering working on a MCP Extension for A2UI.
[...]
Would it make sense to add this to the MCP Apps extension instead or creating a new one?

also being discussed... if you have a short but firmly held conviction about how that would work, this is a place to voice it

I see two paths, each with trade-offs:

1. A2UI-over-MCP
2. A2UI-over-MCP Apps

In Path 1, the client agent is a dumb pipe. It speaks to the 3p server over MCP, which returns A2UI resources directly via resources/read or as an embedded resource in a tool call response. A2UI's official "A2UI over MCP" document tells us that "in both cases, the client detects the application/a2ui+json MIME type and routes the payload to an A2UI renderer," so the client agent isn't interacting with A2UI at all, it's just a middle-man.

When user interactions generate userAction messages, the client agent packages them up exactly as they are, sends them to the 3p server over an MCP tool call. The MCP server forwards them again to the 3p's agent which processes the A2UI messages, and returns an A2UI response like an updateDataModel message. The MCP server packages the raw A2UI in a tool call response, and sends it to the client agent which just naively forwards it to the client renderer.

As far as I can tell, this is the flow:

sequenceDiagram
    autonumber
    actor User
    participant UI as 🎨 Client UI / Renderer
    participant Host as 🤖 Host AI Agent
    box rgb(30, 41, 59) Third-Party Stack
        participant 3PSrv as 🌐 3P MCP Server
        participant 3PAgent as 🧠 3P Specialist Agent
    end

    User->>UI: Interacts with Widget (e.g., Clicks Button)
    UI->>Host: userAction Payload (Pure A2UI JSON)
    Host->>3PSrv: tools/call (arguments: { raw_a2ui_payload })
    3PSrv->>3PAgent: Forward userAction to Agent Engine
    
    Note over 3PAgent: 3P Agent processes logic & updates state.<br/>Generates a brand new UI state layout.

    3PAgent-->>3PSrv: Returns new UI layout (Pure A2UI JSON)
    3PSrv-->>Host: response (EmbeddedResource: application/a2ui+json)
    Host-->>UI: updateComponents Payload (Pure A2UI JSON)
    UI->>User: Renders freshly mutated UI view

Loading

Assuming I have this right, initially I found it pretty odd. I want to walk through why, and then describe a few things that changed my mind.

Why if feels wrong

First, the two things that "speak A2UI" aren't talking to each other. They're mediated by an MCP middle-man which is just a "transport" for opaque A2UI payloads. I found myself wondering if the MCP protocol is adding any value to A2UI here, if it's not integrating semantically with it any more than, say, REST would?

Second, the two agents aren't talking to each other either, which is exactly what A2A is designed for! It smells wrong that the two agents which can talk over A2A, especially since A2UI officially supports A2A as a transport, are bypassing that and using MCP as a REST middle-man basically.

There's nothing inherently bad here, but it felt inelegant. I wasn't sure what making MCP an official "transport" of A2UI, or making MCP be A2UI-aware, buys us besides another way to shuttle opaque A2UI payloads. It seemed to miss the opportunity to make MCP Apps and A2UI—two major agentic UI paradigms—to play well together.

What does A2UI 🤝 MCP Apps integration actually look like?

As mentioned, I was expecting to find a meaningful semantic integration between MCP Apps and A2UI that I felt Path 1 precluded, and that we could achieve with Path 2. We've talked about this in the MCP Apps WG calls, and I've spoken with @liady about this offline a bunch too, but the more I think about it the more skeptical I am:

1. Glue layer: I think what we envisioned was a "glue" layer between MCP Apps and A2UI that would let the two speak without having to know about each other. This might let an MCP App contain an A2UI renderer and display an A2UI resource, but "intercept" all A2UI interaction messages, and convert them into MCP tool calls that the host would just proxy through to the 3p MCP server. While it sounds nice, it's basically indistinguishable from Path 1. That's largely because that's how MCP Apps works today. UI interactions might result in JavaScript event handlers firing tools/calls through the App bridge, and the agent doesn't need to know how to handle them—it just proxies them back to the 3p MCP server, acting as a middleman.

2. Reuse of MCP is actually useful: The value of MCP-as-transport isn't in touching the A2UI payload, it's everything before it: OAuth, capability negotiation, and the fact that the same session is also carrying the server's other tools, so you're not standing up a second connection/protocol just to integrate UI. Obviously A2UI-over-"REST" would have to reinvent that session/auth story, and more. In short, MCP as a carrier for A2UI payloads is valuable even if it does nothing semantic with the bytes.

3. 3p agents: It's not clear how often my complaint about "two agents not talking to each other over A2A" will hold. My diagram assumes that 3p A2UI templates are generated by 3p agents, but I think it's just as likely that they will be hand-crafted in advanced and registered as static MCP resources. In those cases, MCP doesn't push anyone away from A2A.

Benefits of A2UI-over-MCP Apps

With all of that said, I think the difference between Path 1 and Path 2 is pretty minimal. If MCP doesn't semantically engage with A2UI content, then what's up for grabs is basically a namespace question, a little reuse, and some insurance:

• Namespace: does A2UI support get negotiated under its own top-level capabilities MCP key, or as a mimeType inside MCP Apps capability negotiation?
• A little reuse: If A2UI lives in the MCP Apps extension rather than being a parallel mechanism, it could inherit host context (theme, locale, containerDimensions, display modes, etc.) and the standardized CSS variable set for free, instead of needing its own separate context-passing convention. There's probably more reuse opportunity too.
• Insurance: I think the strongest argument for making A2UI a first-class MCP Apps content type is if it turns out there is real semantic overlap between MCP Apps and A2UI that we haven't surfaced yet, folding A2UI in as a content type forces us to design through that overlap properly, inside one spec, instead of leaving two of the biggest agentic-UI primitives evolving on separate tracks and discovering the seams the hard way later.

[curtiskrygier]

Hi - I also echo the feeling that in principle A2UI over MCP doesn't feel right. Ultimately it feels like it's a question of landing on the best distribution channels for A2X protocols. Today if you have an opensource A2UI use case and you want to distribute it, MCP feels like the place to land... so ultimately feels like the right call has been made for the longevity/relevance of A2UI

I think A2UI absolutely deserves to be a first class protocol of the future - but the more I test my a2uicatalog with MCP, the more I start to see some considerations that surface. I am experimenting with the performance of different models with my own catalog and noticed Haiku struggling with some of my catalog atoms, because it surfaced the fact that some degree of judgement was needed - eg when to split an apps script page over 2 pages due to character limits. This initially pushed me down the path of appreciating that the MCP Pipe actually allowed for some supra catalogue enforcement and to some degree gating, a pre catalogue if you like. However this actually helped me realise that using a model such as Haiku or lower is actually a good "grey/not declarative enough" detector. The solution I am working through is actually to add prose to any atoms where Haiku could not figure it out but Sonnet could....

What this did surface for me is also how the MCP dimension can act as a tie breaker or rules guardian in the event of conflicting catalogue/intra catalogue rules.

Concrete example of the tie-breaker point, since @binioter-z is right to ask for one rather than theory: I hit this directly while building out my MCP layer. My top-level server instructions told the calling model to paginate content above ~2000 characters, but a specific tool's own description (more specific, more accurate) said the real limit was closer to ~8000. Nothing caught the contradiction until a live Haiku test read both and followed the wrong, more general one - producing a result that was more fragmented than it needed to be.

Once I noticed it, I wrote a small mechanical check - not another model, just a script verifying that every size-related number quoted anywhere across the server's instructions and tool descriptions traces back to the same canonical source. It immediately caught a second, previously-unnoticed inconsistency in an unrelated tool's own description that I'd missed by eye.

That's the tie-breaker/rules-guardian role in practice: the MCP layer isn't just relaying catalogue content to the model, it's positioned to catch and resolve exactly this class of conflict - session-scope vs tool-scope within the MCP layer , today , catalogue vs catalogue as this scales - deterministically, before the calling model has to guess which rule wins.

Finally on the MCP Apps aspect, my two cents @domfarolino -- I keep landing on DVD vs Netflix as the clean analogy. MCP Apps (one complete, predeclared HTML resource) and Meta's newly open-sourced Astryx (a React component library an agent uses to write finished, compiled code) are both, via different mechanisms, on the "composed product" side - you get a complete thing, once. A2UI is on the "streamed" side - progressive, server-driven, updated live, no code compiled or single artifact shipped.

Both sides are legitimate, useful, for different jobs. I don't think A2UI belongs inside MCP Apps any more than Netflix belongs inside a DVD case - but that's not an argument against MCP Apps, which solves a real problem (interactive dashboards/forms rendered directly in chat) that A2UI isn't trying to solve.

[domfarolino]

but that's not an argument against MCP Apps, which solves a real problem (interactive dashboards/forms rendered directly in chat) that A2UI isn't trying to solve.

Is A2UI not trying to solve that same problem? It's just a difference of pre-declared, custom developer experience vs. declarative UI with no custom business logic. Right?

[curtiskrygier]

@domfarolino — yes agreed, it's generative UI, and that's good for the category — both there to solve the same problem, in different ways.

On custom business logic though: this is achievable through A2UI at the spec level — catalogs can define custom functions with reactive/computed evaluation, and what I've built on top is a derived-state pattern using that for cross-turn diffing.

[wrenj]

you could also embed an iframe in a2ui just for running scripts, and still do native rendering.

security wise its no different than MCP Apps (unless your scripts can manipulate the native components to get out of the sandbox)

[curtiskrygier]

@wrenj thanks — your post helped me have that Eureka moment. At times the paradigm of A2UI feels so abstract. I was already able to operate A2UI in the Google Apps Script iframe "jail." I feel like I now see the matrix.

I've been spending a lot of time in the Google Apps Script layer, which I think will still be a first-class surface for Workspace Enterprise customers — with all the benefits of a declarative catalog: agent-legible, governable, no surprises because every primitive is pre-enumerated. But the MCP Apps dimension is what clicked for me: controlled opaqueness. You get access to all primitives in the iframe instead of just the ones you've curated into a catalog — with the agent still in the loop via chat, not handed the raw DOM.

Why should you care, if you already have a catalog? Because it's a release valve, not a replacement. Curation is what makes agent behavior legible — but curation is slow, and it caps you at whatever you've enumerated. MCP Apps lets you reach past that cap when curation would be too limiting, without losing governability, because the agent still only acts through chat/tool calls rather than a raw handoff to the DOM.

One thing worth naming explicitly: the iframe is just a sandboxed HTML surface — the spec doesn't say what runs inside it. So you can mount the A2UI renderer itself inside the MCP Apps iframe, compose HTML from catalog atoms, and sit that right alongside custom/opaque HTML for whatever falls outside the catalog. That's what the screenshot shows. But once it's rendered, the host has no protocol-level way to tell which DOM came from catalog atoms and which is opaque — that boundary exists only on your side, in how you composed the page. Making the catalog-composed part inspectable/governable by the host feels like the open piece between "MCP Apps as dumb transport" and real semantic integration.

I'm blown away by the A2UI team's foresight on the protocol — this wasn't obvious to me until I'd actually built the curated version by hand and felt where it strained.

I acknowledge my complete U turn here, but feel like the penny finally dropped for me - look forward to digging into this a lot more. Currently working on converting some playbooks I made into the componentid/childlist to align properly with A2UI v1. All seems like it will be directly portable to MCP Apps surface which feels v powerful.