API discovery: OpenWork’s Remote MCP Apps contract is a practical public source for a builder who wants to put a narrow interface beside an agent response without inventing a second tool protocol. A standard MCP server advertises io.modelcontextprotocol/ui; a tool binds an exact UI resource with _meta.ui.resourceUri; and the host retrieves that resource through resources/read.
Try it
Build a read-only “release room” card around one harmless MCP server. Let its launch tool return a small UI resource that renders a deployment checklist, a service-status snapshot, or a plain-language release note. The card can make structured output easier to scan, but it should keep the underlying tool definitions, result metadata, and resource URI tied to the server that supplied them. That is the useful design test: not whether a widget appears, but whether the interface still knows where its authority came from.
The fresh OpenWork implementation makes that boundary explicit. Its host resolves an app-requested tool only on the originating server; workspace tool denies still apply; and a call that is not explicitly read-only and non-destructive requires an approval. The same-server rule is a guardrail against an attractive but dangerous shortcut: treating an embedded UI as a passport to every tool an agent happens to know.
Copy-paste agent instruction
Build a disposable, read-only MCP Apps compatibility test for one harmless release-status tool. Have the server advertise io.modelcontextprotocol/ui; make the launch tool set _meta.ui.resourceUri to one exact ui:// resource; serve that HTML through resources/read; and preserve the server's tool schema and structured result. Keep every app-requested tool call on the originating server, reject cross-server calls, and require explicit user approval for any call that is not read-only and non-destructive. Use mock data and disposable credentials only; record the host version, connection setup, resource URI, tool result, and approval behavior.Test caveat
OpenWork documents two paths with different readiness. A normal server comes through Connect, which still owns configuration, member access, credentials, and tool policy. Its static URL adapter is deliberately tighter: a bounded, self-contained HTML document, immutable revisions, and a feature gate until a compatible Desktop host is released. A successful render therefore does not certify authentication, browser isolation, server availability, or compatibility with every MCP Apps host. Start with a disposable connection and a harmless read-only tool before testing an app-requested call.