Design Engineering

MCP Apps' Final Spec Turns Design Systems Into Graceful Degradation

MCP's 28 July 2026 spec graduated MCP Apps to eleven clients, letting hosts theme a team's UI with tokens that carry no guarantee of arriving at all.

You install a browser extension and trust it to behave inside somebody else’s page. Ship an interactive UI into a chat app, and the relationship flips: you’re the guest now, and the host gets a vote in how your work looks. That’s the practical shape of a change the Model Context Protocol made official on 28 July 2026, when its final 2026-07-28 spec shipped and MCP Apps — the extension that lets a server return interactive HTML that renders inline inside a host’s chat window — graduated from experiment to supported standard , backed across eleven clients including Claude, ChatGPT, Cursor and Microsoft 365 Copilot. Anthropic frames the release as riding real momentum: over 400 million monthly SDK downloads , four times last year’s rate, and 950-plus servers already listed in Claude’s connectors directory, with Figma, Intuit, Netlify, PostHog, Xero and Zoom named as backers. For a design engineer, the headline isn’t distribution. It’s that the component library your team ships onto this surface is composed by you and colored by whoever built the chat app it’s running inside.

The palette a host owes you is whatever it feels like sending

The mechanism is CSS custom properties. A host can inject values for a large, standardized set of variables — background, text, border and focus-ring colors in several states, font families and weights, radii, shadows — and the MCP Apps specification is explicit that this is a courtesy, not a contract:

Hosts can provide any subset of standardized variables, or not pass styles at all.

That single line is the whole craft problem. A view can’t assume any given token exists; it has to define a sane fallback for each of roughly 37 of them, or risk a white card sitting jarringly on a dark host background — the exact failure mode an independent build-side account from sunpeak opens with. That same guidance is blunt about the discipline this demands: don’t branch on which product you think you’re running inside, because that breaks the moment a new host ships; feature-detect instead, and test every combination of host, theme and display mode you plan to support, since Microsoft 365 Copilot’s inline widgets and its optional side-by-side workspace, documented separately , behave differently enough to need their own pass. Anthropic’s own published design guidance points the same way: lean on host tokens for structural elements — backgrounds, text, borders, icons — and save brand color for accents and identity, on the theory that a design system’s job here is to survive contact, not to reproduce itself exactly.

The component library your team ships is composed by you and colored by whoever built the chat app it's running inside.

What survives when the structure isn’t yours to set

That reframing is the real subject. A design system built for a product a team fully controls is, by definition, a single source of truth — one palette, one component set, rendered identically everywhere the team deploys it, the same assumption behind why shadcn/ui’s swap from Radix to Base UI mattered enough to be news: defaults propagate. MCP Apps breaks that assumption on purpose. The surface is sandboxed for security — apps “can’t access the parent page, steal cookies, or escape their container,” per the official docs — but that same isolation means a host is free to hand you none of its tokens, all of them, or anything in between, and your component still has to look intentional. That’s a harder version of a question this magazine has already raised about whether a design system’s rules survive contact with an agent that’s supposed to follow them : here the agent isn’t misreading your tokens, the host is simply declining to send them.

Google’s design team, which ships the competing A2UI standard, argues MCP Apps solved the wrong problem. Instead of sending HTML, CSS and JavaScript to render inside an iframe, A2UI sends a declarative JSON payload and lets the host draw everything through its own native components, which Google’s developer blog contends avoids “a fragmented user experience, characterized by aesthetic inconsistencies like clashing design systems or redundant scrollbars.” It’s a serious objection: A2UI buys automatic light/dark and accessibility adaptation for free, at the cost of a fixed component library and trouble with real client-side logic — Google’s own fix is a hybrid, native rendering for standard elements and iframes for specialized ones. MCP’s own documentation concedes the underlying point too, noting that if a use case doesn’t need conversational integration, “a regular web app might be simpler.” Nobody is forced onto either surface.

But teams that do choose MCP Apps — and Figma, Intuit and Zoom already have — inherit a genuinely new design-engineering task: deciding, token by token, what has to stay yours when the structure around it isn’t. Brand color as accent, not architecture; type and spacing borrowed wholesale; a fallback defined for every variable a host might simply skip. The single source of truth doesn’t disappear so much as it moves one layer down, from the components themselves to the rules for how they behave when nobody hands them a theme at all.

This article was written by AI. How Pipeline works.