Doppeltes Problem und Lösung
Liad Yosef (AI & MCP Lead bei Monday.com, Co-Moderator der UI-Arbeitsgruppe) stellt MCP-UI als Lösung für ein doppeltes Problem vor. Erstens erzeugen textbasierte Oberflächen für Nutzer Textwände. Zweitens, und kritischer, verlieren Anbieter (Shopify, Airbnb, Amazon) ihre Identität, wenn sie nur Text senden – der Chat entscheidet, wie er dargestellt wird, was ihnen ihren Platz in der Wertschöpfungskette nimmt. MCP-UI erlaubt es jeder Anwendung, "UI-Chunks" zu senden – Teile ihrer Identität – wodurch visuelle Wiedererkennung und über Jahre optimierte Nutzererfahrung erhalten bleiben.
Technische Architektur und Sicherheit
MCP-UI ist ein offenes Protokoll + SDK zum Senden von UI über MCP und zur Standardisierung der Host/UI-Kommunikation. Die Architektur beruht auf sandboxed iframes, die Sicherheit garantieren: Der UI-Code hat keinen Zugriff auf den Ursprung (Origin) des Hosts, kann keine Cookies/Speicher stehlen und kommuniziert ausschließlich über post messages. Drei Inhaltstypen werden unterstützt: externe URLs, rohes HTML, remote DOM (ein leistungsfähiges Konzept, das die Definition der Struktur von der Darstellung trennt – derselbe MCP-Server kann eine identische Antwort an unterschiedliche Clients senden, die diese mit ihren eigenen Komponenten rendern).
Kommunikationsspektrum und Zustand
MCP-UI definiert ein Kommunikationsspektrum, das die Verantwortungsebenen der UI gegenüber Nutzeraktionen darstellt: (1) Notify – die UI führt eine Backend-Aktion aus und benachrichtigt den Chat; (2) Tool call – die UI fordert das Auslösen eines bestimmten Tools an; (3) Prompt – die UI fordert die Ausführung eines Prompts an; (4) Intent – die UI sendet die Absicht des Nutzers, der Host entscheidet, was zu tun ist. Diese Islands-Architektur (verschiedene UI-Inseln, die innerhalb eines einzigen Kontexts zusammengesetzt werden) erfordert ein ausgefeiltes Zustandsmanagement über 4 Ebenen: Agentenkontext (für den agentischen Ablauf), interner App-Zustand (Präferenzen, Steppers über Cookies/localStorage), Backend (Daten, die für den agentischen Ablauf nicht relevant, aber für die Synchronisation nötig sind), und zwischen Komponenten geteilter Zustand.
Konkrete Demonstration: Sprint-Management
Die Demo zeigt einen Engineering Manager, der "Sprint-Status" erfragt. Statt nutzlosem Text liefert MCP-UI ein interaktives Monday-Widget mit einer visuellen Aufschlüsselung. Klick auf "blockierte Aufgaben" → zeigt die Aufgabe "Implementierung der Authentifizierung", zugewiesen an Sarah. Klick auf "Analysieren" → der Kommunikationsmechanismus sendet einen Prompt an den Agenten, der, über einen weiteren MCP-Server mit Gmail verbunden, automatisch E-Mails abruft und entdeckt, dass Sarah krank ist und Jordan den Code kennt. Das Widget fügt eine farblich hervorgehobene Analyse ein, die eine Neuzuweisung an Jordan vorschlägt. Klick auf "Neu zuweisen" → eine Intent-Nachricht löst einen MCP-Tool-Aufruf aus, der den Ablauf abschließt. Entscheidend: der Anbieter hat die Gmail-Integration nicht selbst gebaut – der Agent hat die Verbindung anhand des vorhandenen Kontexts hergestellt.
Mehrschichtiges Theming
Um eine Erfahrung wie eine "Zusammenstellung von Drittanbieter-UIs" zu vermeiden, unterstützt MCP-UI ausgefeiltes Theming: benutzerdefiniertes CSS (Shopify implementiert es bereits), CSS-Variablen, Theme-Tokens und remote DOM (das leistungsfähigste – remote UI, gerendert mit Host-Komponenten, garantiert visuelle Konsistenz bei gleichzeitigem Erhalt der Struktur/Interaktionen des Anbieters).
Anwender und Ökosystem
Massive Verbreitung bereits im Gange: vollständige Shopify-Einführung, Postman, Goose, Libra Chat (Hosts); Hugging Face (alle Spaces stellen MCP-UI bereit), 11 Labs, MCP Storefront (Anbieter). Community-SDKs in Ruby, Python, TypeScript, Go. Community-Projekt unter mcpui.dev mit vollständigen Anleitungen.
Zukunftsvision: Rekomponiertes fragmentiertes Web
Transformative Vision: Heute öffnet man 10 verschiedene Tabs (Amazon, Kalender, Booking) für eine einzige Aufgabe (Planung eines Geburtstags), jeder mit einer komplexen UI, deren Inhalt zu 90 % irrelevant ist. Zukunft: Ein persönlicher Assistent komponiert UI-Atome von Anbietern – Google Kalender sendet einen Event-Chunk, Amazon einen Produktlisten-Chunk, Booking einen Chunk mit Angeboten und Karte. Es ist keine Anbieter-zu-Anbieter-Integration nötig – der Assistent verfügt über den vollständigen Kontext. Ergebnis: in wiederverwendbare Komponenten zerlegbare Apps, ein zugänglich gemachter Jarvis, weil der Integrationsaufwand entfällt.
Herausforderungen der Roadmap
Drei zentrale Herausforderungen: (1) Auth/SSO – derzeit ist der Zustand im Kontext/UI oder in einer In-UI-Authentifizierung fest verankert, ein nahtloses SSO wird benötigt; (2) Native Clients – ChatGPT/Claude werden nativ, viele unterstützen keine iframes/webviews, es wird eine abstrakte Payload untersucht, die in HTML oder nativ konvertierbar ist, mit Capabilities-Aushandlung; (3) Standardisierungs-Adoption – die Technologie ist bereit, es braucht Schwung aus der Community.