The piece separates consistency from portability cleanly — the question is whether it actually demonstrates the harder one.
The line worth keeping: MCP gives an A2UI document somewhere to run. A2UI gives the document a portable rendering contract.
MCP is the pipe and A2UI is the parcel — the protocol only guarantees the same payload arrives everywhere; whether it renders as the same UI once it lands is a separate bet the article mostly asserts rather than shows live.
The article itself draws this line — it just doesn't fully sit with the weaker half of it.
The author's central claim is that MCP Apps isn't competing with A2UI; it's the distribution layer that gets an A2UI document to a live surface at all, while A2UI is what makes the arriving thing legible as structure rather than opaque markup.
>MCP gives an A2UI document somewhere to run. A2UI gives the document a portable rendering contract.
The evidence offered is the Wall Builder payload rendering in both Claude and ChatGPT off the same MCP tool call, with no per-host adaptation. But the article is upfront that this specific pair proves less than it looks like: both hosts are mounting code the server itself ships.
>Video 2 shows the same content rendering in ChatGPT — same payload, same tool, no adaptation.
The argument only reaches genuine portability — not just consistency — if an independently built renderer draws the same document the same way. The article names this gap itself rather than hiding it, which is the one place a summary would have missed the seam entirely.
>The stronger claim shows up when the renderer isn't shared.
Read charitably, the piece isn't claiming the two-host demo proves cross-renderer portability — it's explicitly using that demo only to establish the cheaper claim (consistency, which even a fixed HTML template gets you), and pointing at a *different*, earlier piece of work (the Gemini Enterprise field report) to carry the harder claim. That's a defensible division of labour across a series: this article's job is to lay out the stack and prove the floor; the ceiling gets its receipts elsewhere. Judged only against what it sets out to prove — that a typed document, not markup, is what makes an MCP Apps surface re-interpretable rather than merely repeatable — the two-host demo is exactly the right evidence, correctly scoped.
Both demonstrated legs — Claude and ChatGPT — go through what the article calls the plain anonymous MCP endpoint, mounting the renderer the server ships. That's nearly definitional: of course two iframes running identical code produce identical output. The actual test of the claim — an independently implemented A2UI renderer drawing the same document — is not demonstrated live here at all. It's asserted by reference to Gemini Enterprise from a prior report, and even the language used for that case is doing unquantified work: the piece calls it 'not pixel-identical, but the same UI structurally' without saying how much structural drift would still count. Without a threshold, that clause can absorb almost any divergence and still be called a pass.
Take a single A2UI document for a surface with real interaction and state — not just a static layout like Wall Builder's visual chrome — and render it through two implementations that share no SDK or codebase: the catalog's own reference renderer, and a from-scratch conforming one. Check functional equivalence (which controls fire, what state updates on interaction), not just visual similarity. If an independently built renderer diverges on behaviour while still passing as 'conforming,' the portability claim shrinks to portability-within-one-vendor's-implementation-family — a materially weaker and still useful result, but a different one than 'the host becomes almost incidental.'
The article is honest about its own scope — 'narrower than it might sound' — which is precisely why the one unproven step is worth naming rather than letting the demo's polish stand in for it.