feat(samples): add generic A2UI MCP App renderer in React

[liady]

What

Adds a third micro-app to the a2ui-in-mcpapps sample: server/apps/react/, a generic, server-agnostic A2UI renderer for MCP Apps, selectable in the sample host as "Generic React Renderer".

Unlike the Basic and Editor apps, it contains zero server-specific logic. It is pure chrome: the MCP Apps handshake comes from the official @modelcontextprotocol/ext-apps SDK (App class, including automatic size-changed iframe resizing), rendering is @a2ui/react (v0.9 basic catalog) driven by a @a2ui/web_core MessageProcessor, and all content arrives through tool results. Any A2UI-speaking MCP server can serve the built react.html as its own ui:// resource if it follows two conventions:

1. A2UI payloads travel as marked embedded resources — tool results (including the entry tool's result, which produces the initial render) carry A2UI messages as EmbeddedResource content blocks with mimeType application/a2ui+json, each marked with _meta: {"ui": {"content": {}}}, and the ui:// resource serving the renderer declares _meta.ui.contentMimeTypes: ["application/a2ui+json"] (on resources/list and resources/read). This is the MCP Apps Dynamic View Content contract: the marker tells hosts to forward the block to the View unmodified and keep it out of model context; the declaration is the reviewable contract of what the View can parse; routing stays on the tool's _meta.ui.resourceUri. The renderer still accepts unmarked A2UI blocks as a legacy allowance for servers that predate the marker (extractA2uiMessages(content, {allowUnmarked: false}) turns it off).
2. A2UI actions map to tools — each action name matches an app-visible tool name (_meta.ui.visibility includes "app"), and the action's resolved context becomes the tool arguments; the response payload is applied incrementally to the live surfaces. (The mapping is overridable: the GenericA2uiApp component takes an optional actionToToolName prop for servers whose action vocabulary differs from their tool names.)

The sample host negotiates dynamic content by advertising contentMimeTypes: ["application/a2ui+json"] (alongside mimeTypes) in the io.modelcontextprotocol/ui extension capability at initialize.

This is intended as the seed of an extractable/reusable artifact: the renderer is a standalone React component (GenericA2uiApp in src/generic-a2ui-app.tsx, with main.tsx only mounting it), so it can be reused either as the prebuilt react.html or as a component.

Changes

• server/apps/react/ — the renderer: GenericA2uiApp component + extract-a2ui-messages.ts (unit-tested with vitest), built with Vite + vite-plugin-singlefile into a self-contained public/react.html. No inline.js post-processing needed (React has no forced chunking, unlike the Angular apps).
• server/ — v0.9-vocabulary counter payload (simple_counter_a2ui_v0_9.json), ui://react/app resource, get_react_app entry tool (declares the template via _meta.ui.resourceUri) and increase_counter_v0_9 app tool. All A2UI payload blocks are built by an a2ui_content_block() helper that sets the _meta.ui.content marker, and the ui:// resources declare contentMimeTypes in both resources/list and resources/read.
• client/ — third option in the app selector; entry-tool lookup becomes a map; null-guard on the relay target when delivering tool input/result; advertises the io.modelcontextprotocol/ui extension capability with mimeTypes + contentMimeTypes. Everything else (tool allowlist, resource URI) already derives from _meta.ui.
• samples/community/package.json + yarn.lock — the new app is picked up by the existing mcp/a2ui-in-mcpapps/server/apps/* workspace glob; added to build:web and the lockfile.
• READMEs — sample README documents the two conventions and build "Option C"; server/apps/README.md and server/apps/react/README.md cover the React build and the component's props.

Noteworthy implementation detail

vite.config.ts sets resolve.dedupe for @a2ui/web_core / @preact/signals-core (and friends). With duplicated copies in node_modules (hoisted vs nested), the bundle gets two signal-library instances and data-model updates stop propagating to rendered components — the UI renders once and silently never updates. Worth knowing for anyone who copies this app as a template.

Testing

• Unit tests for the payload extraction (yarn test, vitest, 16 cases: single/array payloads, legacy mime type, non-object JSON, invalid JSON, non-resource blocks, marked vs unmarked _meta.ui.content selection, isViewContentBlock).
• Verified end-to-end in the sample host (Angular client + Python SSE server): selecting "Generic React Renderer" completes the ui/initialize handshake via the ext-apps SDK; the entry tool's embedded v0.9 payload renders the counter card; clicking "Increase counter" relays tools/call increase_counter_v0_9 through the host and the returned updateDataModel patches the counter in place (no surface rebuild).
• Regression: the Basic (v0.8) and Editor apps still load and work.
• tsc --noEmit clean; yarn build:all emits a single-file react.html with no external references.

Builds on #1949 (merged) for the _meta.ui template declaration, the standard tools/call relay, and the host fix for JSON-RPC id-0 responses (the ext-apps SDK numbers requests from 0).

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a generic, server-agnostic React A2UI renderer and updates the MCP Apps host and server to support it, aligning with the 2026-01-26 protocol version. The feedback highlights several important improvements: adding safety checks to prevent runtime crashes when messaging the iframe target, implementing a connection guard for the singleton MCP app to avoid duplicate connections, cleaning up event handlers on unmount to prevent memory leaks, and robustly validating parsed JSON payloads. Additionally, unit tests should be added for the new React renderer to comply with the repository's style guide.