Constraining UI variability, or enforcing a restricted UI/component set?

[domfarolino]

Content in an MCP App is kind of a free-for-all, since it's just a web app. The spec makes no mention of host-required style variables, interaction patterns, blessed UI components, etc., so anything goes. This level of UI variability/flexibility is generally unacceptable to hosts, who have evolved their own "UI design principles" and requirements to impose on UI inside an MCP Apps iframe, so they conform to the host's native styling and don't break their brand UX too much.

Style guidelines and Figma component templates have been published for both Claude and ChatGPT so far:

Claude:

• https://claude.com/docs/connectors/building/mcp-apps/design-guidelines#style-variables
• https://www.figma.com/community/file/1597641111449594397/mcp-apps-for-claude

ChatGPT:

• https://developers.openai.com/apps-sdk/concepts/ui-guidelines
• https://www.figma.com/community/file/1560064615791108827/apps-in-chatgpt-components-templates
• (is this still relevant? https://openai.github.io/apps-sdk-ui/?path=/docs/overview-introduction--docs)

If I understand correctly, failure to conform to a host's injected styles or UI patterns will likely cause an MCP App to be rejected by "app-store-like review" process. All of this comes from a very understandable place. After all, agent hosts are embedding 3p iframe content directly in their UI, and it's reasonable for them to retain some control over the UX of their product.

Unfortunately, the more host-specific requirements get imposed on developers, the less predictable and portable MCP Apps become. MCP Apps get less "write once run everywhere" and more "write some abstraction, and keep up with a list of ever-growing host-specific requirements for my UX", and over time I think this will cause significant fracturing.

It's probably not possible to solve this whole problem—there will always be some host-specific constraints we don't want to bake directly into the MCP Apps standard. However, as agent hosts like Gemini and others are looking to implement the MCP Apps standard, I'm repeatedly bumping up against the same problem of hosts (and sometimes 3p devs!) wanting an easily enforceable, restricted set of UI components that can be used inside the frame.

Some hosts are looking at https://a2ui.org/ as a path forward, which lets developers express a declarative JSON UI structure describing elements of a finite component library, that gets rendered in the host iframe without 3p script needing to be involved. I'm not proposing this specific approach as a concrete solution, but I'd like to offer it as a jumping off point for discussion.

There are tons of solutions here, ranging from heavy-handed ones like enforcing A2UI-like component libraries backed by renderers that 3Ps don't control, to light-weight ones like specifying how the host injects styles, or otherwise constrains UI variability. (The latter could be done by MCP Apps bootstrapping some closed-root shadow DOM that contains host styles/markup that's isolated from the 3p content inside the iframe, for example...)

The goal is to improve interoperability of MCP Apps across agent hosts and make the platform we're specifying more predictable and less implementation-defined, so developer don't have to write 3 different MCP App View UIs for 3 different agent platforms.

With that, are any hosts interested in firming up some kind of way to constrain UI variability of MCP Apps? Would love thoughts from other implementers here to kick things off. /cc @ochafik @aharvard @idosal @liady @chrishtr @bengreenstein @AbhiGemTest @bricedp.

[aharvard]

A2UI in goose could be cool. Even if A2UI is not the eventual winner, supporting A2UI could help us find one. Some initial questions.

1. Would we set up this capability as an additional, experimental MCP App mimeType?
2. Would we need A2UI to support MCP as a transport layer?
3. How close is the A2UI React renderer to being ready? What about React shadcn?

[liady]

@domfarolino that's a really good point and one that we're trying to standardize, to find the balance between the app-specific requirements and the hosts' UX requirements (see this comment).
Interoperability with A2UI could be very interesting in that sense (see this issue).
I think we should separate the two discussions - it's a good discussion on how much restriction we want to enforce in the MCP Apps spec, and parallel to that is the interoperability (or a complement layer) with A2UI.
btw - we can use that as a first case for a new mime type, one that's declarative and not a strict "black box"