# Eine Notiz von der anderen Seite derselben Grenze _Drei Gedanken zurück zu generativer UI, MCP Apps, Kontext und Governance._ **Kurzfassung —** Generative UI verändert die Ökonomie aufgabenspezifischer Schnittstellen. Struktur macht Modellleistung kontrollierbar. Kontext sollte ausserhalb eines einzelnen Modells bleiben; Governance gehört an die Verbindung zwischen Kontext, Modell und Schnittstelle. > **Archiv-Update · September 2026** > > Ruben Casas’ Talk bleibt eine hilfreiche Quelle. MCP Apps sind inzwischen eine offizielle MCP-Erweiterung mit einer stabilen Spezifikation vom 26. Januar 2026. Die Unterstützung unterscheidet sich weiterhin je nach Host; „MCP Apps liefern die Auslieferungsschicht“ bedeutet deshalb keine universelle Verfügbarkeit. Dieser Text begann als privater Brief an [Ruben Casas](https://www.youtube.com/watch?v=hCMrEfPG2Yg) nach seinem Talk *Beyond Components — Designing Generative UI for MCP Apps*. Der Talk gab mir Sprache für etwas, dem ich mich aus einer anderen Richtung genähert hatte. Ruben kam von Protokollen und Rendering. Ich kam von Adoption, Kontext und Governance. Drei Gedanken blieben hängen. **Argumentkarte · Von generativer UI zur gesteuerten Verbindung** Sechs Zustände führen von statischen und deklarativen Oberflächen über generative UI zu getrennten Schichten für Schnittstelle, Modell, Kontext und Governance, einer gesteuerten Verbindung und einer Konversations-Canvas-Schleife. ```text 01 · Statische Komponenten Der Host wählt eine vorgefertigte Komponente. Daten und Eigenschaften ändern sich; die verfügbare Oberfläche bleibt fest. Host-Anwendung → vorgefertigte Komponente 02 · Deklarative UI Das Modell erzeugt eine strukturierte Beschreibung. Der Host validiert und rendert begrenzte Komponenten, Eigenschaften und Layouts. Modell → Beschreibung → Host-gerenderte UI 03 · Generative UI Die Aufgabe erhält eine aufgabenspezifische Oberfläche. Kontext formt eine temporäre Schnittstelle, deren Interaktion den nächsten Schritt beeinflussen kann. Aufgabe + Kontext → Oberfläche → Interaktion 04 · Schichten trennen Schnittstelle, Modell, Kontext und Governance haben unterschiedliche Aufgaben. Austauschbarkeit und Portabilität bleiben Ziele, die explizite Grenzen voraussetzen. Schnittstelle · Modell · Kontext · Governance 05 · Die Verbindung steuern Richtlinien kontrollieren, was verbunden wird. Einwilligung, Berechtigungen und Audit vermitteln, wie Kontext Modell, Werkzeug und Oberfläche erreicht. portabler Kontext → gesteuerte Verbindung → Modell + UI 06 · Kollaborativer Canvas Konversation wird zur Arbeitsoberfläche. Die Person verändert die temporäre Oberfläche; diese Interaktion wird Eingabe für den nächsten Modellschritt. Konversation → Canvas → Interaktion ↺ nächster Schritt ``` ## 01 — Ökonomie der Spezifität statt Bildschirmevolution Bei generativer UI liegt die Versuchung nahe, die Revolution als völlig neuen Bildschirm zu denken: räumliche Canvases, schwebende Fenster, Schnittstellen ohne Namen. Das mag kommen. Die unmittelbarere Veränderung ist für mich jedoch ökonomisch. Photoshop, Premiere, VS Code, DAWs und Figma haben uns längst ein dauerhaftes Designmuster gezeigt: **dichte, aufgabenspezifische Oberflächen**. Die Schnittstelle passt sich der Arbeit an. Generative UI verändert die Kosten dieser Spezifität. Statt über Jahre feste Panels und Menüs auszuliefern, kann ein System pro Aufgabe, Person und Moment eine passende Oberfläche zusammensetzen. > Die Revolution muss nicht darin liegen, dass der Bildschirm fremdartig wird. Vielleicht wird Spezifität einfach günstig. ## 02 — Struktur macht Leistung kontrollierbar Ruben bezeichnete deklarative UI als nützliche Balance zwischen Flexibilität und Konsistenz. Dieser Punkt ist weiterhin stark. Das breitere Muster zeigt sich überall in strukturierter Generierung: Schemata, begrenzte Komponenten, deklarative Beschreibungen, Validierung, Tool-Verträge und Aktionsgrenzen. Das Ziel ist nicht, das Modell schwach zu machen. Es soll einen präzise geformten Ort erhalten, an dem es handeln kann. ```text Modellfähigkeit + strukturierter Vertrag → begrenzte Aktion → prüfbares Ergebnis ``` Ein Modell kann beliebiges HTML erzeugen. Ein Produktionssystem profitiert aber oft davon, wenn es stattdessen eine begrenzte Darstellung erzeugt, die der Host rendert und validiert. ## 03 — Kontext zentralisieren, nicht Schnittstellen. Die Verbindung steuern. Das Rendering-Gespräch beginnt oft mit der Frage: „Wo läuft die UI?“ Davor liegt für mich eine andere: **Was sollte zentral sein, und was sollte an den Rändern bleiben?** **Schnittstelle** Verteilt und aufgabenspezifisch, je Werkzeug und Moment. **Modell** Reasoning und Rechenleistung; idealerweise austauschbar. **Kontext** Gesammeltes Wissen und Arbeitszustand ausserhalb eines einzelnen Modells. **Governance** Regeln dafür, welcher Kontext an welches Modell und welche Schnittstelle darf. Ich mag diese Architektur weiterhin. Einen Satz aus dem Entwurf von 2026 würde ich aber abschwächen: „Das Modell wird zum austauschbaren Utility“ ist ein Designziel, keine garantierte Eigenschaft. Anbieterspezifische Werkzeuge, Kontextsemantik und Modellverhalten können einen Wechsel teuer machen. Auch die Kontextportabilität über Werkzeuge und Modelle hinweg bleibt unvollständig und fragmentiert. Das ist die architektonische Richtung, keine Behauptung, dass die nötige Produktschicht bereits gelöst wäre. ## MCP Apps machen die Verbindung konkret [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview) bieten ein standardisiertes Muster, mit dem Server interaktive UI-Ressourcen deklarieren können. Unterstützende Hosts rendern sie in Sandbox-iFrames und vermitteln die bidirektionale Kommunikation. Das [offizielle Spezifikations- und SDK-Repository](https://github.com/modelcontextprotocol/ext-apps) kennzeichnet die Version 2026-01-26 als stabil. Damit entsteht ein realer Verbindungspunkt zwischen Werkzeug, UI und Gesprächskontext. Die Unterstützung unterscheidet sich weiterhin je nach Host. Die Erweiterung beseitigt Governance jedoch nicht. Sie macht sie konkreter: - Welcher Kontext erreicht das Werkzeug? - Welche Fragmente dürfen angezeigt oder weitergegeben werden? - Welche Aktionen darf die eingebettete UI auslösen? - Was protokolliert oder auditiert der Host? - Was geschieht, wenn ein Host die Erweiterung nicht unterstützt? ## Konversation als Canvas als Konversation Der Moment auf der Nutzerseite, der mir das zuerst verständlich machte, war viel einfacher. Ich bat ein LLM, ein BPMN-Diagramm für die Zubereitung einer Margherita-Pizza zu zeichnen. Interessant war nicht, dass es zeichnen konnte. Das Diagramm wurde im Gespräch zu einer temporären Arbeitsoberfläche: etwas, auf das ich zeigen, das ich verändern und mit dem ich denken konnte. ```text Konversation → aufgabenspezifische Oberfläche → menschliche Interaktion → nächster Modellschritt → veränderte Oberfläche ``` Wir sind heute deutlich näher daran, dass dieses Muster zu einem Standardbaustein von Produkten wird. ## Die Grenze von der Adoptionsseite aus Protokoll- und Rendering-Schichten werden real. Die ungelöste institutionelle Frage bleibt die Verbindung. In einer regulierten Organisation scheitert eine Demo selten daran, dass die erzeugte Karte nicht attraktiv genug ist. Sie scheitert, wenn niemand beantworten kann, wer welchen Kontext unter welcher Befugnis an welches Modell und Werkzeug geleitet hat – und mit welcher Auditspur. > Schnittstellen verteilen. Kontext portabel halten. **Die Verbindung steuern.** ## Quellen - [Ruben Casas — Beyond Components: Designing Generative UI for MCP Apps](https://www.youtube.com/watch?v=hCMrEfPG2Yg) - [Model Context Protocol — MCP Apps Überblick](https://modelcontextprotocol.io/extensions/apps/overview) - [Offizielles MCP Apps Spezifikations- und SDK-Repository](https://github.com/modelcontextprotocol/ext-apps)