Stellen Sie keine JSON-Daten mehr zurück: Bieten Sie interaktive Benutzeroberflächen mit MCP-Apps an.

Während des größten Teils der Anfangsphase von MCP blieb der Interaktionszyklus eng gefasst: Agenten rufen Tools auf, die Tools führen aus, Server antworten mit Text oder strukturierten Datenpaketen, und Modelle paraphrasieren das Ergebnis für die Nutzer.

Viele Fragen passen immer noch in dieses Muster. Um die Anzahl der funktionierenden Implementierungen zu zählen, ist kein zusätzliches Werkzeug nötig: Rufen Sie einfach get_deployments() auf, lesen Sie ein kompaktes Objekt wie {"total": 12, "healthy": 10, "degraded": 2} und geben Sie die Antwort in einer Zeile wieder.

Die Situation ändert sich, wenn Nutzer mit dem Ergebnis interagieren möchten. Dashboards, Genehmigungsprozesse, filterbare Tabellen, Konfigurationsformulare, Diagramme, Implementierungspanels, mehrstufige Workflows sowie Mechanismen mit menschlicher Beteiligung erfordern alle mehr als nur einen JSON-Ausdruck. Lange Zeit bot MCP kein cross-host-basiertes Standard dafür – jetzt gibt es ihn unter dem Namen MCP Apps, und er erweitert das, was ein MCP-Server darstellen kann.

MCP-Server waren größtenteils Maschineninterfaces

Das erste mentale Modell war agentenorientiert. Server stellen Werkzeuge wie search_projects(), create_ticket(), restart_service() und get_customer() zur Verfügung. Die Modelle entdecken sie, rufen sie auf, erhalten Daten und die Menschen sehen nur das, was das Modell zur Anzeige wählt. Das ist vorteilhaft, da die Abläufe über ein einziges Protokoll ablaufen statt für jeden Agent eine eigene Integration erforderlich zu sein. Die Einschränkung besteht darin, dass die Funktionen für Maschinen konzipiert wurden, wodurch der Mensch einen Schritt vom Rohdatenergebnis entfernt bleibt.

Das ist in Ordnung, solange die Interaktion im Wesentlichen visuell ist. „Zeigen Sie mir alle Produktionsdienste“ kann zwar einen korrekten JSON-String mit Statusinformationen, CPU- und Speicherdaten zurückgeben, doch ein kompaktes Dashboard mit Fortschrittsbalken, Statussymbolen sowie Steuerelementen für Protokolle, Neustarts und Skalierung ist weitaus nützlicher. MCP-Apps zielen darauf ab, diese Lücke zu schließen.

Was sind MCP Apps genau?

MCP Apps erweitert das Model Context Protocol, sodass Server interaktive Benutzeroberflächen zusammen mit ihren Tools bereitstellen können – keine Screenshote, kein Markdown, das als UI getarnt ist, sondern echte HTML/JavaScript-Anwendungen, die innerhalb eines MCP-Hosts dargestellt werden. In den Dokumentationen wird beschrieben, wie Tools ui://-Ressourcen anbieten, Hosts diese Ressourcen in isolierten Iframes darstellen und wie derselbe Host sowohl Tool-Payloads in die Ansicht einfügt als auch ermöglicht, dass die Ansicht nur über diesen Host wieder auf Tools zugreifen kann.

MCP App = MCP Tool + UI Resource + Host/View protocol

Ein Tool ruft weiterhin APIs auf, durchsucht Datenbanken, führt Geschäftslogik aus und gibt strukturierte Daten zurück. Zusätzlich kann es eine Benutzeroberfläche zur Anzeige dieser Ergebnisse bereitstellen. Die Benutzeroberfläche ist eine MCP-Ressource wie ui://services/dashboard und kann ein vollständiges Frontend enthalten – HTML, CSS, JavaScript, React, Diagramme, Formulare, Schaltflächen. Somit verfügt eine Operation sowohl über eine für Maschinen zugängliche Funktionalität als auch über eine für Menschen zugängliche Schnittstelle, die auf allen Hosts standardisiert ist.

Woher stammen MCP-Apps?

Die Erweiterung ist neu. Entwickler, die bis 2025 MCP-Server bereitgestellt haben, haben keine geheime Funktion verpasst; der offizielle Standard existierte damals noch nicht.

Der Release-Kandidat von Juli 2026 verbesserte die Erweiterungen im Allgemeinen – stabile Identifikatoren, Fähigkeitsverhandlungen, getrennte Repositorien, unabhängiges Versionieren sowie ein Extensions Track, der Apps auflistet. Zudem wurde betont, dass buttongesteuerte Aufrufe weiterhin über den JSON-RPC-Pfad des Hosts laufen, wodurch Agent → Tool sowie Human → Button → Tool unter einem einzigen Steuerungsplan bleiben. Der Beitrag zum Release-Kandidat von Juli 2026 auf dem MCP-Blog behandelt den Extensions Track.

Im September 2026 zeigte ein Beitrag zu AWS Bedrock AgentCore ein konkretes Hosting-Muster, ohne Apps ausschließlich auf AWS zu beschränken: host → gateway → runtime → MCP-Server (Tools + UI-Ressourcen) → Lambda/DynamoDB. In der Demo wurde ChatGPT verwendet, und es wurde darauf hingewiesen, dass Claude sowie andere App-Hosts auf dieselbe Weise funktionieren. Für eine Schritt-für-Schritt-Anleitung siehe den Blogbeitrag von AWS Machine Learning zu interaktiven MCP-Apps mit Bedrock AgentCore.

Wer unterstützt eigentlich MCP-Apps?

Die Unterstützung von MCP ist nicht dasselbe wie die Unterstützung von MCP-Apps. Ein Client kann normale Tools und Ressourcen verarbeiten, ohne die Apps-Erweiterung zu implementieren. In der Ankündigung vom Januar 2026 wurden ChatGPT, Claude, Goose und VS Code genannt; die aktuellen Dokumente beschreiben die inline-Bereitstellung in Claude, ChatGPT und anderen kompatiblen Clients und weisen darauf hin, dass die Host-Unterstützung variiert. Planen Sie entsprechend: Nehmen Sie nicht an, jeder Client versteht Apps. Die nützliche Gleichung lautet Server unterstützt MCP-Apps + Host unterstützt MCP-Apps = Interaktive Benutzeroberfläche, und ein sorgfältig konzipierter Server sollte auf Text oder strukturierte Inhalte zurückgreifen, wenn der Host die App nicht darstellen kann.

Die einzige Frage, die wirklich zählt

Falls die UI-Ressource statisches HTML ist, wie gelangen dann Änderungen an den Tool-Daten dorthin? Der CPU-Anteil kann jetzt 21 % betragen und zehn Sekunden später bereits 87 %; es wäre unsinnig, bei jedem Tool-Aufruf die gesamte Frontend-Struktur neu zu generieren. Die Lösung liegt in der Trennung: UI und Daten sind unterschiedliche Komponenten. Betrachten Sie das Tool als Datenproduzent, die Ressource als Präsentationsoberfläche und den Host als Verbindungsmechanismus. Das Tool liefert dynamische Daten; die Ressource gibt eine Anwendung zurück, die weiß, wie diese Daten dargestellt werden sollen; der Host verbindet sie zur Laufzeit miteinander.

Wie MCP-Apps tatsächlich funktionieren

Betrachten Sie get_servers(), das Server-Objekte mit id, Name, Status, CPU-Auslastung und Speicherverbrauch zurückgibt, wobei die Metadaten auf ui://servers/dashboard verweisen. Der Lebenszyklus:

Das Modell ruft get_servers() auf. Der Server führt seine Logik aus – Datenbank, Cloud-API, Kubernetes, interne Dienste – und gibt strukturierte Daten zurück. Der Host erhält die UI-Metadaten für ui://servers/dashboard und sendet einen resources/read-Anfragen. Der Server liefert das Frontend-Bundle (React, Vue oder reines JavaScript). Die aktuellen Serverdaten sind nicht in dieses HTML eingebettet; die Benutzeroberfläche kennt lediglich den erwarteten Vertrag (servers[].id, servers[].status usw.).

Der Host rendernt die Anwendung in einem sandboxierten iframe, sodass der UI-Code eines MCP-Servers nicht frei auf den Host-DOM, die Sitzung oder Anmeldeinformationen zugreifen kann. Anschließend übermittelt der Host das Ergebnis der Tool-Anwendung in die laufende Ansicht, typischerweise über JSON-RPC mittels postMessage zwischen Host und dem sandboxierten View.

Die Frontend-Plattform erhält die Daten auf dieselbe Weise wie jede SPA und rendernt entsprechend. Ein Server liefert eine Karte; fünfzig Server liefern fünfzig Karten. Die Anwendung bleibt unverändert; nur die Daten ändern sich.

Verglichen mit einer klassischen Webanwendung – bei der React GET /api/servers aufruft – löst in MCP Apps der Agent tools/call aus, das Tool gibt JSON zurück, und der Host injiziert dieses JSON in eine React-Anwendung innerhalb eines Iframes. Die Benutzeroberfläche holt sich nicht immer selbst Daten; der Host kann die Ergebnisse stattdessen bereitstellen.

Aber MCP Apps sind nicht nur schönere Tool-Ergebnisse

Eine tiefere Eigenschaft ist, dass die Anwendung ebenfalls Tools aufrufen kann. Schaltflächen, Formulare und Diagramme dienen nicht nur der Dekoration; sie können über den Host dieselben MCP-Tools aufrufen wie der Agent.

MCP App → call tool → Host → tools/call → MCP Server → restart_server()

Zum Beispiel kann eine Neustart-Schaltfläche im Dashboard über den Host restart_server aufrufen, anstatt einen eigenen Nebenkanal zu erstellen:

async function restartServer(serverId) {
  return app.callServerTool({
    name: "restart_server",
    arguments: { server_id: serverId }
  });
}

Der Host bleibt der Kontrolleur für Berechtigungen, Protokollierung und Richtlinien.

Eine Funktionalität, zwei Schnittstellen

Dieselbe Backend-Operation kann daher zwei Formen annehmen: ein Tool, das vom Modell im Dialog aufgerufen wird, sowie eine App, die von einem Menschen visuell bedient wird. Keines ersetzt das andere. Agenten bleiben bei offenen Problemlösungen stark; Apps überzeugen, wenn Struktur, Dichte oder wiederholte Aktionen entscheidend sind.

Ein Produktivbeispiel: menschliche Freigabe innerhalb eines Agenten-Arbeitsablaufs

Stellen Sie sich vor, ein Agent erstellt eine Benutzergeschichte, die vor der Einreichung genehmigt werden muss. Ohne Apps kopiert das Modell den Entwurf in die Chat-Unterhaltung und hofft, dass der Mensch „genehmigen“ oder „mit Gründen ablehnen“ eingibt. Mit Apps kann ein Tool wie present_user_story_for_approval den Entwurf zusammen mit einer Benutzeroberflächen-Ressource zurückgeben, die Schaltflächen für „Akzeptieren“, „Änderungen anfordern“ und „Ablehnen“ zeigt. Bei Klicken auf „Ablehnen“ öffnet sich ein Feld für die Angabe von Gründen; durch Absenden wird ein Tool aufgerufen, das die Entscheidung speichert und gegebenenfalls den Modellkontext aktualisiert, sodass der nächste Schritt bereits weiß, warum Version 1 fehlgeschlagen ist.

Dieses Muster beinhaltet einen Menschen im Prozess mit einer echten Steuerungsfläche – es handelt sich dabei nicht um ein brüchiges Ritual in natürlicher Sprache.

Nicht jede Schaltfläche muss ein von dem Modell sichtbares Tool sein

Einige Tools sollten nur für Agenten zugänglich sein, andere nur für Apps, wieder andere gemeinsam genutzt werden können. Die Paginierung innerhalb eines Dashboards sollte nur von der Ansicht aus aufrufbar sein, damit das Modell nicht mit zahlreichen Tools zur Seitenwechselung überflutet wird. Der Server kann verschiedene Sichtbarkeitsstufen angeben, wodurch eine echte Zugriffsregelung entsteht statt lediglich einer Namenskonvention.

Auch die Kommunikation kann in Richtung App → Modellkontext fließen (wenn der Host es zulässt): Ein in der Benutzeroberfläche eingegebener Ablehnungsgrund kann den Kontext aktualisieren, sodass die nächste Verarbeitung im Modell das Entwurfswerk verbessert, ohne dass der Benutzer die Kritik erneut im Chat eingeben muss.

MCP Apps ist keine neue Kernprimitivität

Trotz des Namens stellt Apps keine vierte Kategorie neben Tools/Ressourcen/Prompts dar. Es handelt sich um eine Erweiterung, die eine Beziehung zwischen einem Tool und einer UI-Ressource sowie ein Host-/Ansichtsprotokoll standardisiert. Da Tools und Ressourcen bereits bekannt sind, stellt Apps eine interaktive Schicht um sie dar – nicht ein zusätzliches, separat angehängtes Protokoll.

Was ändert sich, wenn man die Chat-App besitzt

Teams, die ihre eigene Agentenplattform entwickeln, werden zum MCP-Host. Dieser Host muss UI-Metadaten erkennen, Ressourcen lesen, die App in einer Sandbox ausführen, Tool-I/O an die Ansicht übergeben, erlaubte Tool-Aufrufe zum Server weiterleiten, Funktionalitäten verhandeln und Berechtigungen durchsetzen. Das stellt eine echte architektonische Herausforderung dar.

Es gibt drei Teilnehmer – den MCP-Server, den MCP-Host und die MCP-App-Ansicht – und das offizielle SDK trennt Entwickler der Ansicht, Entwickler des Hosts sowie Serverautoren voneinander. Die Hilfspakete befinden sich in TypeScript unter @modelcontextprotocol/ext-apps, wodurch die Geschäftslogik nicht in Node gezwungen wird. Wire-Level MCP verwendet weiterhin Tool-Metadaten, Ressourcen, strukturierte Inhalte sowie MCP-Anfragen, sodass ein Python/FastMCP-Server funktioniert, sofern er das bereitstellt, was von hosts mit Apps-Funktionalität erwartet wird. Die Ansicht basiert auf Web-Technologien; bestehende Backends können unverändert bleiben.

Sicherheit darf nicht erst an letzter Stelle berücksichtigt werden

Ausführbare Benutzeroberflächen erhöhen das Risiko. Sandboxing von Iframes sowie hostbasierte Aufrufe helfen zwar, doch jede App sollte als unzuverlässige Benutzeroberfläche behandelt werden – insbesondere dann, wenn sie Funktionen wie restart_service(), delete_resource(), approve_payment() oder deploy_to_production() auslösen kann. Bestätigungsdialoge sind nützlich, aber unzureichend. Authentifizierung, Autorisierung, Validierung, Richtlinien, Audit-Logs, Idempotenz, Versionsprüfungen sowie Rate Limits gehören weiterhin zum Backend. Die Benutzeroberfläche ist nicht die Grenze des Vertrauens.

Wo MCP-Apps tatsächlich sinnvoll sind

Nicht jedes Tool muss in eine App eingebettet werden. Um 42 oder einen Versionsstring zurückzugeben, ist React nicht notwendig. Apps lohnen sich, wenn die Interaktion eine Struktur aufweist:

Operations-Dashboards – Dienste, Bereitstellungen, Infrastruktur, Logs, Metriken, Aufgaben, Warteschlangen: Überprüfen und anschließend handeln.

Genehmigungsworkflows – Genehmigen/Ablehnen, Änderungen annehmen/beantragen, bereitstellen/stornieren, veröffentlichen/Entwurf beibehalten. Oft die beste Lösung für Unternehmen.

RAG und Unternehmenswissenssuche – Filter, Kontrollkästchen sowie „Ausgewählte vergleichen“ liefern bessere Ergebnisse als zwanzig Treffer im reinen Textformat, während der Agent weiterhin die Logik verarbeitet.

Agentenverwaltung – Die natürliche Sprache zeigt an, wer auf die Produktumgebung von Salesforce zugreifen kann; ein Registerbild ist besser geeignet, um Änderungen an Berechtigungen zu überprüfen und zu genehmigen.

Formulare und Konfiguration – Das Sagen von „CPU 2, Speicher 4GB, Region us-east-1, Replicas 3“ ist unpraktischer als ein Formular, das der Agent bei Bedarf aufruft.

Bauen Sie nicht eine App pro Tool

Vermeiden Sie eine Ausbreitung von tool_1 → app_1. Wählen Sie lieber Domain-Apps. Eine „Deployment Management“-App kann Abfragen, Protokollierungen, Neustarts, Skalierungs- und Rollback-Vorgänge als zusammenhängende Gruppe abwickeln. Ein Eingabefenster zeigt die App an; danach kann die Ansicht die entsprechenden Operationen direkt aufrufen. Die Benutzeroberfläche bleibt kohärent und die MCP-Oberfläche bleibt übersichtlicher.

Der größere architektonische Wandel

Die interessante Veränderung liegt nicht im iframe selbst. Operationen, die ursprünglich für Agenten konzipiert waren, können nun eine standardisierte Benutzeroberfläche für Menschen bereitstellen:

OPERATION → Machine Interface (MCP Tool) + Human Interface (MCP App)

Falls Funktionen als Agent-Plugins verpackt werden, kann ein Salesforce-Paket Anweisungen, Tools (search_accounts, create_opportunity, update_lead), Berechtigungen, Bewertungen sowie Apps (Konten-Explorer, Opportunity-Formular, Pipeline-Dashboard) zusammen liefern. Dadurch entsteht eine vollständige Interaktionsoberfläche sowohl für Agenten als auch für Menschen.

Der Agent muss nicht wissen, dass React oder Iframes existieren. Er ruft get_services(...) oder present_user_story_for_approval(...) auf; Metadaten informieren den Host darüber, dass eine Schnittstelle vorhanden ist. Die Benutzeroberfläche bleibt im UI-Schicht, die Logik zur Kommunikation mit dem Agenten befindet sich im Backend.

Wie ich dies in ein bestehendes System einführen würde

Auf einer Plattform, die bereits eine benutzerdefinierte Chat-Funktion, Agenten sowie einen FastMCP-Server besitzt, sollte man ein Neudesign vermeiden. Beginnen Sie mit einer nur zum Lesen geeigneten Funktion wie get_agents() zusammen mit dem kleinstmöglichen Anzeigefenster (ui://agents/list), das Namen, Status und Anzahl der Tools anzeigt – ohne Schaltflächen. Beweisen Sie den Ablauf: Der Agent ruft ein Tool auf, der Host erkennt die Benutzeroberfläche, liest die Ressource, rendernt das Iframe und das Ergebnis des Tools wird angezeigt.

Dann wird „Erneuern“ hinzugefügt, anschließend eine echte Aktion wie „Agent deaktivieren“, danach Autorisierungs- und Audit-Logging-Funktionen sowie leistungsstärkere Apps. Die Adoption erfolgt schrittweise, ohne dass die Logik des Agents neu geschrieben werden muss.

Teams, die eine Adoption prüfen, sollten auch Mittel für Verhandlungen bezüglich der Host-Fähigkeiten einplanen. Ein appsbewusster Server, der stets UI-Metadaten mitliefert, kann weiterhin auf älteren Clients korrekt funktionieren, sofern der Host unbekannte Felder einfach ignoriert und der strukturierte Inhalt des Tools selbstständig vollständig bleibt. Umgekehrt muss ein Host, der eine Apps-Unterstützung behauptet, vor dem Aktivieren des Feature-Flags für Endbenutzer Sandboxing, Ressourcenabrufe sowie Proxys für Toolaufrufe implementieren; halbimplementierte Hosts erzeugen fehlerhafte Iframes, die das Vertrauen schneller untergraben als reines JSON jemals könnte.

Die Beobachtbarkeit gehört zum selben Rollout-Plan. Protokollieren Sie, welche Tools UI-Ressourcen enthalten, auf welchen Hosts sie gerendert wurden, welche durch Klicks auf Schaltflächen ausgelösten Toolaufrufe erfolgreich waren und welche auf Text umgestiegen sind. Diese Metriken zeigen an, ob die Apps tatsächlich interaktive Inhalte liefern oder ob die Nutzer weiterhin das Eingeben in den Chat bevorzugen. Ohne diese Telemetriedaten ist es einfach, Dashboards zu veröffentlichen, die niemand aufruft.

Zuletzt sollten Schema-Verträge versioniert werden. Die App und das Tool müssen sich auf Feldnamen und -typen einigen. Wenn servers[].cpu in verschachtelte Objekte aufgeteilt wird, ohne den UI-Vertrag anzupassen, werden leere Widgets angezeigt, obwohl der Agent weiterhin korrektes JSON erhält. Behandeln Sie die vom App erwartete Payload als eine öffentliche API, die demselben Team gehört, das auch das Tool entwickelt hat.

Beim Messen des Erfolgs nach dem Launch sollte man zwischen „App wurde angezeigt“ und „App wurde verwendet“ unterscheiden. Ein iframe, das nur einmal dargestellt wird und nie einen Klick erhält, ist eine Kuriosität; eine App, die Neustarts, Genehmigungen oder Konfigurationsänderungen auslöst, trägt echten Produktwert. Kombinieren Sie Produktanalysen mit MCP-Audit-Protokollen, damit Sie erkennen können, welche menschlichen Aktionen aus Apps stammen und welche aus Chats, sowie ob diese Aktionen die Zeit bis zur Lösung der bereits bearbeiteten Tickets verkürzen.

Zusammenfassung

MCP beantwortet die Frage, wie Agenten über ein einziges Protokoll mit externen Systemen kommunizieren. MCP Apps fragen, wie Menschen dieselben Funktionen nutzen können, ohne den Dialog zu verlassen.

Gestern ging es um Agenten, Tools, JSON und anschließend um Prosa. Heute kann eine einzige Funktionalität sich verzweigen: Modelle rufen während des Gesprächs weiterhin Tools auf, während Menschen eine visuelle App bedienen – beide Verzweigungen enden schließlich bei denselben Domänendiensten. Das Reasoning bleibt beim Agenten, die Ausführung bei den Tools, und wenn eine Aufgabe Struktur benötigt, kann das Protokoll Dashboards, Formulare, Genehmigungsverfahren, Diagramme, Konfigurationspaneele sowie menschliche Kontrollpunkte direkt im Chat anzeigen – ohne die MCP-Schicht aufzugeben, von der die Agenten bereits abhängen.

Deshalb sind MCP-Apps mehr als nur schönere Antworten: Server entwickeln sich von maschinenorientierten Endpunkten zu portablen Interaktionsschichten für sowohl Agenten als auch Menschen.

Erwähnen Sie ausdrücklich die Fallback-Möglichkeiten in der README-Datei Ihres Servers: Welche Tools deklarieren die UI-Ressourcen, welche Hosts sind bekanntermaßen in der Lage, sie anzuzeigen, und wie das textbasierte bzw. strukturierte Fallback aussehen soll, wenn die Apps nicht verfügbar sind. Diese Dokumentation verhindert Support-Anfragen im Stil von „MCP funktioniert nicht“, wenn das eigentliche Problem darin besteht, dass ein Host die Erweiterung nicht aktiviert hat.

Weitere Literatur

Die primäre Dokumentation zur Apps-Erweiterung ist unter apps.extensions.modelcontextprotocol.io veröffentlicht (Überblick und API-Bereiche). Zeitlinienbeschreibungen finden sich auf blog.modelcontextprotocol.io zur Vorschlagsphase 2025, zur Veröffentlichungsankündigung 2026 sowie zum Extensions Track für Release-Kandidaten. Der AWS Machine Learning-Blog zeigte später ein Hosting-Muster für Bedrock AgentCore, das weiterhin host-unabhängig bleibt.

Falls Sie derzeit mehrere MCP-Server betreiben, widerstehen Sie dem Drang, für jedes Team ein eigenes privates Mini-Framework zu entwickeln. Wählen Sie stattdessen gemeinsam genutzte Host-Hilfsfunktionen für den Lebenszyklus von Iframes, gemeinsam genutzte TypeScript-Typen für die von den Apps verwendeten Tool-Payloads sowie eine kurze Checkliste für Design-Überprüfungen: Benötigt dieses Tool eine Benutzeroberfläche? Gibt es bereits eine App im selben Bereich, die es übernehmen könnte? Was ist der Ersatzplan, falls der Host die Apps nicht darstellen kann? Wer ist für die Autorisierung von per Button ausgelösten Aufrufen verantwortlich? Diese vier Fragen beheben den größten Teil des vorzeitigen Ausbreitungsproblems bei Apps.

Ausbildung ist ebenfalls wichtig. Agenten, die plötzlich weniger Tools sehen, weil einige Operationen hinter einer App-einschränkten Sichtbarkeit verschoben wurden, verhalten sich anders. Aktualisieren Sie die Systemanweisungen sowie die Bewertungssätze, wenn Sie Zugriffsstufen einrichten, und führen Sie einen „Golden Path“-Test durch, bei dem eine App geöffnet wird, eine sichere Aktion ausgeführt wird und überprüft wird, ob die entsprechende Auditerfassung im Backend angezeigt wird. Ohne diesen Test bleiben Regressionen im iframe verborgen, bis ein Kunde einen nicht funktionierenden Button meldet.

Sobald all diese Elemente vorhanden sind, wirken MCP-Apps nicht mehr wie eine Neuheit, sondern erscheinen als gewöhnliche Produktfunktionen für Agentenplattformen. Dadurch wird der Adoptionsprozess durch klare Rückfallmöglichkeiten und messbaren Einsatz abgeschlossen.