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.