WebMCP: Wenn Websites KI-Agenten Werkzeuge im Browser anbieten

Die Spezifikation definiert eine Schnittstelle am Dokument, über die eine Seite mit registerTool() Werkzeuge anmeldet. Jedes Tool hat einen eindeutigen Namen, eine Beschreibung, optional ein Eingabe- und Ausgabeschema im JSON-Schema-Format und eine Funktion, die beim Aufruf ausgeführt wird. Ein Agent kann die registrierten Tools abfragen, eines auswählen und mit passenden Argumenten aufrufen. Das Ergebnis geht als Text an den Agenten zurück.

Chrome beschreibt zwei Wege. Die imperative API nutzt normales JavaScript und eignet sich für Navigation, Filter oder Zustandswechsel in einer Anwendung. Die deklarative API ergänzt vorhandene HTML-Formulare um Annotationen, sodass ein Formular ohne zusätzlichen Code als Tool erscheint. Beide Wege sind über die Permissions Policy „tools“ abgesichert: Standardmäßig dürfen nur die Seite selbst und gleichartige Ursprünge Tools registrieren, eingebettete fremde Frames nur nach ausdrücklicher Freigabe.

Zusätzlich sieht die Spezifikation Annotationen vor. Ein Tool kann als nur lesend markiert werden, als Quelle nicht vertrauenswürdiger Inhalte oder als folgenreich – etwa wenn es eine Buchung auslöst oder Geld bewegt. Diese Hinweise helfen dem Agenten, vor solchen Aktionen eine Bestätigung einzuholen.

Die aktuelle Fassung ist ein Draft Community Group Report vom 2. November 2026, veröffentlicht von der Web Machine Learning Community Group. Als Editoren sind Personen von Microsoft und Google genannt. Der Statusabschnitt hält fest, dass das Dokument weder ein W3C-Standard ist noch sich auf dem Standardisierungspfad befindet. Inhalte und Schnittstellennamen können sich also noch deutlich ändern.

Laut der Übersicht zum Implementierungsstand im offiziellen Repository läuft in Chrome 149 ein Origin Trial, also ein zeitlich begrenztes Testprogramm für experimentelle Funktionen auf echten Websites. Edge bietet einen Origin Trial ab Version 150 an. ChatGPT Desktop wird als unterstützender Agent geführt, Brave hat experimentelle Unterstützung in seinem Assistenten. Für Firefox und Safari sind bislang nur Stellungnahme-Verfahren der Browserhersteller verlinkt.

Für die lokale Entwicklung lässt sich WebMCP in Chrome über ein Flag aktivieren. Chrome nennt außerdem experimentelle Unterstützung in React, Angular und Vue sowie Werkzeuge in den DevTools, um Tools und Schemata zu prüfen.

Ein klassischer MCP-Server ist eine Backend-Integration: Die KI-Plattform spricht direkt mit dem Server des Anbieters, an der Weboberfläche vorbei. Das Repository der Spezifikation nennt die Nachteile für interaktive Anwendungen: Der Nutzerkontext geht verloren, Zustand und Anmeldung müssen auf einem separaten Server nachgebaut werden, und es entsteht zusätzlicher Entwicklungsaufwand. WebMCP verlagert das Tool in die bereits geöffnete und angemeldete Seite.

Browser-Automation – von Chrome als Actuation bezeichnet – simuliert Klicks und Eingaben, als wäre der Agent ein Mensch. Jeder Schritt ist dabei offen für Fehlinterpretation, und Änderungen am Layout können Abläufe brechen. Mit WebMCP erklärt die Website selbst, wofür ein Element gedacht ist, und stellt eine Funktion mit festen Parametern bereit. Die Website wird damit vom passiven Ziel zum aktiven Partner des Agenten.

Der Sicherheitsabschnitt der Spezifikation ist ausführlich und benennt Grenzen offen. Prompt Injection kann über Tool-Beschreibungen, Eingaben oder Ausgaben erfolgen; manipulierte Beschreibungen werden als Tool Poisoning geführt. Hinzu kommen Fehldarstellung von Absichten, wenn ein Tool etwas anderes tut, als sein Name verspricht, und Datenabfluss, wenn ein Tool mehr persönliche Parameter abfragt als nötig.

Entscheidend ist ein Satz aus dem Dokument: Eine bösartige Website kann die Annotationen weglassen oder falsch setzen. Der Schutz des Nutzers liegt daher vor allem im Sicherheitsmodell des Agenten. Für Unternehmen als Website-Betreiber heißt das umgekehrt: Wer Tools anbietet, sollte sie ehrlich annotieren, Eingaben begrenzen und folgenreiche Aktionen immer über eine sichtbare Bestätigung auf der eigenen Seite laufen lassen.

Für mittelständische Unternehmen ist WebMCP vor allem dort interessant, wo die Website Arbeit erledigt: Konfiguratoren, Angebotsanfragen, Terminbuchung, Händlersuche, Kundenportale mit Bestellhistorie. Hier entscheidet sich, ob ein Agent im Auftrag eines Einkäufers die Aufgabe zuverlässig abschließt oder an einem verschachtelten Formular scheitert. Eine reine Informationsseite profitiert dagegen kaum; dort zählen weiter gut strukturierte Inhalte.

Chrome nennt auch Grenzen: Die Schnittstelle ist für lokale Browserabläufe mit einem Menschen im Prozess gedacht, nicht für Headless-Betrieb. Agenten müssen eine Seite besuchen, um ihre Tools zu entdecken. Komplexe Anwendungen brauchen gegebenenfalls Umbauten, damit Zustand sauber verwaltet wird. Ein sinnvoller Weg ist daher ein begrenzter Test mit einem einzelnen Formular als progressive Erweiterung, die ohne WebMCP-fähigen Browser einfach nicht greift.