WebMCP beschreibt Browseraktionen, nicht noch eine Backend-Integration
WebMCP ist ein vorgeschlagener Webstandard, mit dem sich Aktionen auf einer Seite als strukturierte Tools für KI-Agenten beschreiben lassen. Statt sich durch Buttons, Labels und wechselnde Layouts zu raten, kann ein Agent eine definierte Aktion, ihre erwarteten Eingaben und ein kontrolliertes Ergebnis erhalten. Das ist für Kundenportale mit komplexen Formularen, geführten Support-Anfragen oder Account-Workflows interessant.
Wichtig ist die Abgrenzung zu einer serverseitigen Model-Context-Protocol-Integration. Ein Backend-MCP-Server gibt einem Agenten über einen kontrollierten Dienst Zugriff auf Systeme und Daten. WebMCP lebt im Browser-Tab des Nutzers und ist für Interaktionen gedacht, bei denen der Nutzer anwesend ist. Beides kann sich ergänzen, braucht aber unterschiedliche Berechtigungs-, Test- und Support-Modelle.
Mit einer sichtbaren Portalaufgabe mit niedrigem Risiko beginnen
Der erste WebMCP-Kandidat sollte ein Workflow sein, der bei korrektem Ausfüllen einen klaren Nutzen hat, schnell von einer Person geprüft werden kann und bei Abbruch keinen Schaden verursacht. Eine Support-Anfrage, Produktsuche, ein Entwurf für eine Terminbuchung oder ein vorausgefüllter Antrag ist meist ein besserer Pilot als das Ändern von Rechnungsdaten, das Akzeptieren rechtlicher Bedingungen oder der Abschluss einer Zahlung.
Die richtige Frage lautet nicht, ob ein Agent durch die bestehende Oberfläche klicken kann. Entscheidend ist, ob das Portal eine echte Nutzerabsicht als kompakten, verständlichen Vertrag ausdrücken kann. Kann das Team Eingaben, Validierungsregeln, Ergebnis und Verantwortliche eines Workflows nicht klar beschreiben, ist er noch nicht bereit, als Tool angeboten zu werden.
- Einen Nutzerweg mit klaren Eingaben, Validierung und beobachtbarem Ergebnis wählen.
- Die normale Portaloberfläche ohne Agenten vollständig nutzbar halten.
- Den vom Agenten ausgefüllten Zustand sichtbar machen, damit Nutzer ihn prüfen können.
- Bei sensiblen oder folgenreichen Übermittlungen eine menschliche Prüfung verlangen.
- Vor der finalen Übermittlung Korrektur, Abbruch und einen klaren Support-Weg anbieten.
Formulare und Schemas nutzen, um Mehrdeutigkeit zu reduzieren – nicht Nutzerkontrolle
Die deklarative Richtung von WebMCP baut auf normalen HTML-Formularen auf: Die Seite kann Tool-Name, Beschreibung und die Bedeutung einzelner Eingaben bereitstellen, damit der Browser ein strukturiertes Schema ableiten kann. Das hilft, weil ein für Menschen gelabeltes Feld einem Agenten nicht zwingend verrät, ob es eine Vertragsnummer, ein Wunschdatum oder eine freie Beschreibung erwartet.
Ein Schema verbessert die Form einer Anfrage, nicht automatisch die Sicherheit einer Aktion. Teams sollten jeden Wert serverseitig validieren, dieselben Berechtigungsprüfungen wie in der menschlichen UI verwenden und die ausstehenden Daten im Portal anzeigen, bevor eine Übermittlung Folgen hat. Bei sensiblen Aktionen gehört die Bestätigung in den Produktflow und darf nicht allein aus dem Tool-Aufruf abgeleitet werden.
Berechtigungen, Daten und Tool-Ausgaben als Sicherheitsgrenzen behandeln
Ein Browser-Agent arbeitet im eingeloggten Nutzerkontext. Daher darf eine angebotene Aktion niemals eine Abkürzung um die normalen Produktkontrollen herum schaffen. Jedes Tool sollte eng begrenzt sein, Zugriff aus der aktiven Session ableiten und verhindern, dass Agenten Felder setzen, die die menschliche UI nicht erlauben würde. Bei eingebetteten Portalmodulen sollten iframe-Berechtigungen bewusst geprüft werden, statt Cross-Origin-Zugriff standardmäßig zu aktivieren.
Tool-Beschreibungen, Seiteninhalte und zurückgegebene Daten können ein KI-System beeinflussen. Unvertrauenswürdiger Text darf deshalb nicht als Anweisung behandelt werden, und ein Tool sollte nur Daten zurückgeben, die für die aktuelle Aufgabe notwendig sind. Audit-Logs sollten Tool-Name, Anfragenden, sichtbare Bestätigung, Ergebnis und Fehlerzustand erfassen, ohne einen zusätzlichen Speicher für unnötige sensible Prompts zu schaffen.
- Dieselben serverseitigen Berechtigungen und Validierungen wie für die normale Portalroute verwenden.
- Die kleinste sinnvolle Aktion anbieten statt einer universellen Admin-Operation.
- Read-only-Erkundung und zustandsverändernde Aktionen trennen.
- Zurückgegebene Daten auf die aktuelle Aufgabe begrenzen und Secrets aus Tool-Ausgaben fernhalten.
- Absicht, Bestätigung und Ergebnis protokollieren, damit Support fehlerhafte Abläufe nachvollziehen kann.
WebMCP als Progressive Enhancement planen
WebMCP befindet sich noch in aktiver Standardisierung und Browser-Erprobung. Chrome dokumentiert einen Origin Trial und einen lokalen Testweg, während Diskussionen anderer Browser-Engines Fragen zu Portabilität, Semantik, Datenschutz und Sicherheit aufwerfen. Ein Portal muss deshalb ohne WebMCP vollständig und barrierearm funktionieren – mit Feature Detection und einem sauberen No-Agent-Fallback.
Ein sinnvoller Rollout beginnt in einer Testumgebung mit einem read-only oder nur Entwürfe erzeugenden Nutzerweg. Zuerst wird der normale Nutzerweg getestet, danach Tool-Registrierung, ungültige Eingaben, Abbruch, Session-Ablauf, Berechtigungsgrenzen und der Bestätigungszustand. Qualität der Abschlüsse und Support-Aufwand sollten gemessen werden, bevor der Umfang wächst. Ändern sich Browser-Support oder Vorschlag, bleibt das Portal nützlich, weil Formular und Server-Workflow die eigentliche Produktinvestition waren.
Entscheidungscheckliste für Produktteams
Für EDS-Labs-Projekte ist WebMCP aktuell ein Discovery- und Pilot-Thema, keine Standardanforderung an eine Plattform. Sinnvoll kann es sein, wenn ein Kundenportal wiederholbare Aufgaben mit anwesenden Nutzern hat, die Agenten über die sichtbare Oberfläche allein nicht zuverlässig erledigen können. Es ist kein Grund, die gesamte Produkt-API doppelt anzubieten oder ein bestehendes Freigabemodell aufzuweichen.
Das stärkste Ergebnis bleibt bewusst überschaubar und prüfbar: ein gut strukturierter Portal-Workflow, der für Menschen, assistive Technologien und klassische Automatisierung funktioniert, ergänzt um eine optionale Agentenschicht nur dort, wo sie echte Mehrdeutigkeit reduziert. So bleibt das Produkt lernfähig für das entstehende Browser-Ökosystem, ohne den Kernweg auf einen unfertigen Standard zu setzen.