KI-Agenten können heute bereits Reisen recherchieren, Formulare ausfüllen oder Produkte vergleichen. Doch in vielen Fällen arbeiten sie dabei wie ein sehr schneller Mensch: Sie lesen sichtbare Texte, suchen Buttons und versuchen, die Benutzeroberfläche richtig zu interpretieren. Das funktioniert, bleibt aber empfindlich. Ein geänderter Buttontext, ein neues Layout oder ein unerwartetes Dialogfenster kann einen Ablauf unterbrechen.
WebMCP verfolgt einen anderen Ansatz. Websites sollen Browser-Agenten ihre wichtigen Funktionen als klar beschriebene, strukturierte Werkzeuge anbieten können. Statt „Finde den richtigen Button und klicke darauf“ erhält der Agent beispielsweise ein Werkzeug namens search_products mit definierten Eingaben wie Suchbegriff, Preisspanne und Kategorie. Die Website behält dabei ihre normale Oberfläche für Menschen. Zusätzlich entsteht eine maschinenlesbare Ebene für Agenten.
Was ist WebMCP?
WebMCP ist ein vorgeschlagener Webstandard, an dem derzeit öffentlich gearbeitet wird. Die Schnittstelle ermöglicht es einer Website, Werkzeuge im Kontext eines geöffneten Browser-Tabs bereitzustellen. Ein Werkzeug besitzt einen Namen, eine Beschreibung, ein Eingabeschema und eine Ausführungsfunktion. Der Agent kann verfügbare Werkzeuge entdecken, passende Parameter erzeugen und die Funktion ausführen lassen.
Der entscheidende Unterschied zu klassischer Browserautomatisierung liegt in der Absicht. Ein Button verrät einem Agenten oft nur, dass er anklickbar ist. Ein WebMCP-Werkzeug kann dagegen ausdrücklich beschreiben, welche Aufgabe es erfüllt, welche Angaben benötigt werden und welches Ergebnis zu erwarten ist. JSON Schema macht die Eingaben überprüfbar, bevor die eigentliche Aktion beginnt.
WebMCP ist im August 2026 noch experimentell. Chrome führt seit Version 149 einen Origin Trial durch. Für lokale Tests gibt es außerdem eine Browser-Option. Das ist ein wichtiger Hinweis für die Planung: Unternehmen können heute Prototypen erstellen und Erfahrungen sammeln, sollten WebMCP aber noch nicht als überall verfügbare Produktionsschnittstelle behandeln.
Zwei Wege: Formulare erweitern oder Werkzeuge programmieren
Die vorgeschlagene API unterstützt einen deklarativen und einen imperativen Ansatz.
Beim deklarativen Ansatz wird ein bestehendes HTML-Formular mit zusätzlichen Attributen beschrieben. toolname und tooldescription erklären die Aufgabe, toolparamdescription erläutert einzelne Felder. Der Browser kann daraus automatisch ein strukturiertes Werkzeug und dessen Eingabeschema ableiten. Das ist besonders interessant für Suchmasken, Terminabfragen, Rechner oder Kontaktformulare. Die sichtbare Bedienoberfläche bleibt die Grundlage und erhält eine zusätzliche semantische Ebene.
Der imperative Ansatz eignet sich für komplexere Anwendungen. Ein Werkzeug wird mit JavaScript registriert und kann bestehende Geschäftslogik, Zustände der Seite und asynchrone Prozesse nutzen. Die aktuelle API verwendet document.modelContext; ältere Beispiele mit navigator.modelContext sind inzwischen überholt.
document.modelContext.registerTool({
name: "check_availability",
description: "Prüft verfügbare Termine für eine Leistung.",
inputSchema: {
type: "object",
properties: {
date: { type: "string", format: "date" }
},
required: ["date"]
},
execute: async ({ date }) => checkAvailability(date)
});
Werkzeuge können registriert, aktualisiert und wieder entfernt werden. Sie können außerdem auf ein Abbruchsignal reagieren, wenn der Nutzer eine Aufgabe stoppt. Weil sie im geöffneten Dokument leben, können sie den aktuellen Zustand der Seite berücksichtigen – etwa eine ausgewählte Filiale, einen Warenkorb oder bereits eingegebene Daten.
WebMCP und MCP lösen unterschiedliche Aufgaben
Der ähnliche Name führt leicht zu einem Missverständnis: WebMCP ersetzt das Model Context Protocol nicht und ist auch nicht einfach dessen Browservariante.
MCP verbindet KI-Anwendungen typischerweise mit serverseitigen Diensten, Datenquellen oder dauerhaft verfügbaren Werkzeugen. Ein angebundener Dienst kann unabhängig davon arbeiten, ob eine bestimmte Website geöffnet ist. WebMCP ist dagegen an den Kontext eines Browser-Tabs gebunden. Seine Werkzeuge sind temporär, kennen die aktuelle Seite und ergänzen eine Bedienoberfläche, die auch Menschen nutzen.
Beide Ansätze können sich sinnvoll ergänzen. Ein Reiseanbieter könnte über MCP einen globalen Zugriff auf Buchungsdaten bereitstellen, während WebMCP im geöffneten Tab die gerade ausgewählte Reise, lokale Formularvalidierung und eine sichtbare Bestätigung einbezieht. Die Wahl hängt davon ab, ob eine Fähigkeit global und serverseitig oder unmittelbar im Nutzerkontext der Website verfügbar sein soll.
Praktische Einsatzmöglichkeiten
Besonders wertvoll ist WebMCP für Aufgaben, bei denen Agenten heute mehrere fragile Klickschritte ausführen müssen:
- Ein Onlineshop kann Produktsuche, Variantenprüfung und Warenkorbaktionen strukturiert anbieten.
- Ein Terminportal kann freie Zeiten abfragen und eine Buchung bis zum Bestätigungsschritt vorbereiten.
- Ein Versicherungsrechner kann Eingaben validieren und nachvollziehbare Ergebnisse zurückgeben.
- Ein SaaS-Dashboard kann Berichte filtern, Exporte vorbereiten oder Einstellungen ändern.
- Ein Supportportal kann passende Hilfetexte suchen und ein Ticket mit den erforderlichen Feldern anlegen.
Der Nutzen liegt nicht nur in höherer Zuverlässigkeit. Strukturierte Werkzeuge reduzieren auch den Interpretationsaufwand. Der Agent muss weniger Seiteninhalt analysieren und erhält klarere Fehlermeldungen. Gleichzeitig kann die Website festlegen, welche Funktionen überhaupt angeboten werden und welche Parameter zulässig sind.
Sicherheit ist Teil des Werkzeugdesigns
Eine gut beschriebene Funktion ist nicht automatisch eine sichere Funktion. Prompt Injection bleibt ein zentrales Risiko: Inhalte auf einer Seite oder Daten aus externen Quellen können versuchen, das Verhalten eines Agenten zu manipulieren. Die derzeitige Sicherheitsanleitung weist ausdrücklich darauf hin, dass solche Angriffe nicht grundsätzlich ausgeschlossen werden können.
Deshalb sollten Werkzeuge nach dem Prinzip der geringsten Berechtigung entworfen werden. Lesende und schreibende Aktionen müssen klar getrennt sein. Metadaten wie readOnlyHint und untrustedContentHint helfen einem Agenten, Risiken besser einzuschätzen. Für sensible Schritte – zum Beispiel eine Bestellung, eine Zahlung, eine Kündigung oder das Versenden von Daten – sollte eine verständliche Bestätigung durch den Menschen vorgesehen werden.
Auch die Herkunft zählt. Werkzeuge werden standardmäßig innerhalb ihres Ursprungs isoliert. Eine Freigabe an andere Origins muss bewusst und eng begrenzt erfolgen. Cross-Origin-Iframes erhalten nicht automatisch Zugriff. Entwickler sollten außerdem nur sichere HTTPS-Kontexte verwenden, Eingaben serverseitig erneut validieren und keine vertraulichen Informationen in Werkzeugbeschreibungen ablegen.
So können Website-Teams heute starten
Ein sinnvoller Einstieg beginnt nicht mit der größten Transaktion, sondern mit einer klaren, risikoarmen Aufgabe.
- Identifizieren Sie einen häufigen Ablauf mit stabilen Ein- und Ausgaben, etwa eine Suche oder Verfügbarkeitsprüfung.
- Beschreiben Sie das Ziel aus Nutzersicht und wählen Sie einen eindeutigen Werkzeugnamen.
- Definieren Sie ein enges JSON Schema und lehnen Sie unbekannte oder ungültige Parameter ab.
- Nutzen Sie bestehende Anwendungslogik, statt Geschäftsregeln ein zweites Mal im Browser nachzubauen.
- Geben Sie strukturierte Ergebnisse und konkrete Fehler zurück.
- Testen Sie normale Abläufe, Abbrüche, fehlende Angaben und manipulierte Inhalte.
- Führen Sie für folgenreiche Aktionen einen sichtbaren Bestätigungsschritt ein.
- Behalten Sie eine funktionierende menschliche Oberfläche und eine robuste Alternative bei.
Für einfache Formulare kann die deklarative Erweiterung der schnellste Prototyp sein. Bei dynamischen Webanwendungen lohnt sich eine kleine imperative Werkzeugschicht. In beiden Fällen sollten Telemetrie und Tests getrennt erfassen, ob ein Fehler im Agenten, in der Werkzeugdefinition oder in der zugrunde liegenden Fachlogik entsteht.
Fazit
WebMCP verschiebt Browserautomatisierung von der visuellen Vermutung zur erklärten Funktion. Websites können Agenten mitteilen, was sie können, welche Eingaben sie benötigen und wie eine Aufgabe zuverlässig ausgeführt wird. Das verspricht weniger fragile Klickfolgen und eine bessere Zusammenarbeit zwischen Website, Agent und Nutzer.
Noch ist der Standard experimentell und die API kann sich verändern. Genau deshalb ist jetzt ein guter Zeitpunkt für begrenzte Prototypen: Teams können passende Anwendungsfälle finden, Sicherheitsgrenzen definieren und ihre Webanwendungen so strukturieren, dass Menschen und Agenten dieselbe verlässliche Geschäftslogik nutzen. Wer früh lernt, Werkzeuge klar zu beschreiben und sensible Entscheidungen beim Nutzer zu belassen, ist auf ein zunehmend agentisches Web gut vorbereitet.