MCP Apps vs. einfache Tool-Ausgabe: Wann eine AI-Integration eine UI braucht

Bleiben Sie bei einfacher Tool-Ausgabe, wenn sich das Ergebnis als kompakter Text oder typisierte Daten zuverlässig lesen, zitieren oder an den nächsten Schritt übergeben lässt. Wählen Sie eine MCP App, wenn Nutzer mehrdimensionale Daten untersuchen, Formularzustand verwalten, Rich Media prüfen oder viele Objekte nacheinander bearbeiten müssen. Die offizielle Extension erlaubt einem Tool, eine interaktive UI Resource zu deklarieren, die ein kompatibler Host innerhalb der Unterhaltung rendert.

Eine MCP App macht ein Tool weder genauer noch verleiht sie zusätzliche Rechte. Sie ist eine eigene Presentation- und Interaction-Schicht über den Server-Capabilities. Wenn eine Tabelle mit zehn Zeilen und eine klare Empfehlung den Intent bereits erfüllen, erhöhen iframe, JavaScript Bundle, Event Protocol und eine zusätzliche Security Surface nur die Kosten. Starten Sie mit Task Analysis: Welche Handlung kann die Person über eine normale Antwort nicht bequem oder sicher abschließen?

• Kurze Antwort, Citation oder maschinenlesbarer Handoff → einfache Tool-Ausgabe.
• Filter, Drill-down, Canvas, Media Controls oder mehrstufiges Review → Kandidat für eine MCP App.
• Folgenreiche Aktion → serverseitige Policy und explizite Bestätigung unabhängig von der UI.
• Host unterstützt die Extension nicht → nützlicher Text- oder Structured-Fallback.
• Kein messbarer Interaktionsvorteil → keine App-Schicht hinzufügen.

Im Basismuster enthält die Tool Definition `_meta.ui.resourceUri` mit Verweis auf eine `ui://` Resource. Der Host lädt die HTML Resource, rendert sie typischerweise in einem sandboxed iframe und übergibt das Tool Result an die View. UI und Host kommunizieren per JSON-RPC über `postMessage`: Die App kann Ergebnisse empfangen, den Host um den Aufruf eines erlaubten Server Tools bitten oder Model Context aktualisieren. Tool und Schema bleiben der kanonische Execution Contract.

Trennen Sie drei Arten von State. Authoritative Domain State gehört in das System of Record; das Tool Result ist ein versionierter Snapshot oder Handle; Ephemeral View State enthält ausgewählten Tab, Filter oder ein unfertiges Feld. Verstecken Sie den einzigen Operations-Identifier nicht im Browser State. Nach Refresh, erneutem Rendern oder Fallback muss der Kontext über eine explizite Resource ID und eine serverseitig geprüfte Version wiederherstellbar sein.

Für einen einzelnen Fakt, eine Liste von Schlussfolgerungen oder wenige Records ist Plain Output leichter im Transcript zu bewahren, vom Modell zu prüfen und in mehr Clients nutzbar. Für die Exploration einer Cohort Heatmap, Karte, Timeline oder großen Tabelle kann eine UI mit lokalem Sortieren und Filtern wiederholte Model Calls reduzieren. Die App sollte nur bedeutsame Nutzerentscheidungen an das Modell senden, nicht jedes Hover- oder Scroll-Event.

Für einige fehlende Parameter reichen meist Host-native Elicitation oder der nächste Conversation Turn. Eine MCP App ist bei voneinander abhängigen Feldern, Live Preview oder mehrstufigem Review sinnvoll. Bei Writes bereitet die UI einen Exact-Action Proposal vor, der Server prüft aber Identity, Tenant, Object Version, Scope und Approval erneut. Ein Button mit der Aufschrift Approve beweist keine Authorization, und ein verborgenes Role-Feld ist kein Trusted Claim.

• Ein Ergebnis und bis zu fünf einfache Felder → zuerst Text, Structured Content oder Native Form.
• Großer Datensatz mit lokaler Exploration → App mit begrenztem Snapshot und Provenance.
• Abhängige Konfiguration mit Preview → App, Validation zusätzlich auf dem Server.
• Payment, Publish, Delete oder Production Change → Proposal, Policy Gate, Idempotency und Reconciliation.
• Unterschiedliche Client Capabilities → Progressive Enhancement statt zweier Business Logics.

Das offizielle Modell isoliert die App vom Parent DOM, von Host Cookies und Local Storage und führt Kommunikation über einen kontrollierten Channel. Resource Metadata kann Content-Security-Policy-Origins und angeforderte Permissions deklarieren. Der Host entscheidet, welche Capabilities er gewährt. Daher sollte die App minimale Connect-, Resource- und Permission-Allowlists verwenden; Microphone, Camera, Clipboard oder External Navigation sollten nicht vorsorglich angefordert werden.

Behandeln Sie HTML- oder JavaScript-Resource, Tool Result und Daten anderer Tools als getrennte untrusted Inputs. Der Host prüft Resource URI, Extension Negotiation, Message Origin, Method Allowlist, Payload Size und Correlation ID. Der Server verlässt sich nie auf einen disabled Button oder clientseitige Validation. Secrets und Bearer Tokens gelangen weder in Model Context noch View Bundle; die App ruft das Server Tool über den Host auf, während die Credential Boundary außerhalb des iframe bleibt.

MCP Apps sind eine opt-in Extension, deren Unterstützung von Host und Version abhängt. Ein Tool sollte auch ohne gerenderte UI ein nützliches semantisches Resultat liefern: eine knappe Content Summary für die Person, `structuredContent` für Client oder Modell und stabile Identifier für den nächsten Call. Geben Sie nicht nur die Anweisung zurück, das Widget zu öffnen, sonst wird ein Negotiation- oder Render-Fehler zum Funktionsverlust.

Progressive Enhancement bedeutet eine serverseitige Business Operation mit mehreren Presentation Paths. Die App darf keinen versteckten privilegierten Endpoint erhalten, der im normalen Client Flow nicht existiert. Wenn Rich Interaction grundsätzlich nicht portierbar ist, definieren Sie einen minimalen Fallback wie Read-only Summary, Downloadable Artifact oder sicheren Link zum Standalone Product. Analytics sollte App-, Fallback- und Unsupported-Host-Outcomes getrennt erfassen, ohne Rendern als abgeschlossene Business Action zu zählen.

Die Contract Suite prüft Tool Metadata, `ui://` Resource, MIME Profile, Initialization, Tool-Result Delivery, Message Validation und saubere Degradation ohne Extension. Browser Tests decken Sandbox, CSP Denial, langsames Bundle, Refresh, Duplicate Event, Stale Snapshot, Offline State und zwei gleichzeitige Views ab. Security Tests versuchen ein nicht deklariertes Tool aufzurufen, Object IDs auszutauschen, einen externen Origin einzuschleusen und einen consequential Request zu wiederholen.

Interaction Quality wird mit Keyboard-only Navigation, Focus Order, Labels, Error Announcement, Color Contrast, Zoom und schmalem Viewport geprüft. Ein Model Eval bewertet getrennt, ob der Assistant das richtige Tool wählt, die App erklärt und nur relevante User Selections nutzt. Wichtige Product Signals sind Task Completion, Correction Rate, Zeit bis zum verifizierten Outcome und Fallback Success; Click Count oder Render Count allein beweisen keinen Nutzen.

Wählen Sie einen read-heavy Use Case mit offensichtlichem UI-Vorteil, etwa Expense Exploration mit Filtern und Drill-down. Halten Sie den Plain-Output-Baseline-Flow fest, implementieren Sie die App als Progressive Enhancement und replayen Sie beide auf identischen Snapshots. Begrenzen Sie den Canary auf Test-Tenants und Read-only Tools; öffnen Sie Writes erst nach Negative Tests, Accessibility Review, Policy Evidence und idempotenter Reconciliation.

Ein Feature Flag sollte die App Resource separat abschalten können, ohne das Basis-Tool zu deaktivieren. Rollback stoppt neue Renders, stellt die Plain Response wieder her, invalidiert die problematische Asset Version und reconciled unfertige Operations. Audit verbindet Server, Tool, Resource Version, Host Capability, View Session, User Action, Policy Verdict und Authoritative Outcome, ohne sensitive Form Fields zu speichern. Entfernen Sie die App nach dem Rollout, wenn sie den definierten Outcome nicht verbessert oder unvertretbaren Operator Burden erzeugt.