WebMCP ist ein experimentelles Browser-Protokoll von Chrome, mit dem eine Website eigene Tools registrieren kann, damit KI-Agenten die Formulare und Funktionen der Seite direkt entdecken und aufrufen können. Statt eine Seite visuell zu interpretieren und Klicks zu simulieren, ruft ein Agent über WebMCP definierte Funktionen strukturiert auf. Die Registrierung erfolgt entweder deklarativ im HTML oder imperativ in JavaScript. Zum Testen brauchst Du Chrome 150 oder neuer und musst Dich für den WebMCP-Origin-Trial registrieren.
Was WebMCP ist und wofür es gedacht ist
WebMCP adressiert ein grundlegendes Problem der agentischen Web-Nutzung: Wenn ein KI-Agent im Auftrag eines Nutzers eine Aufgabe auf einer Website erledigen soll, muss er heute meist die Oberfläche interpretieren, Elemente erkennen und Klicks sowie Tastatureingaben simulieren. Das ist fehleranfällig, langsam und bricht, sobald sich das Layout ändert. WebMCP dreht diesen Ansatz um. Die Website beschreibt selbst, welche Tools, also welche Funktionen und Formulare, sie anbietet, und stellt diese maschinenlesbar bereit. Der Agent muss dann nicht mehr raten, wo der „Absenden“-Button liegt, sondern ruft das passende registrierte Tool direkt auf.
Der Name verweist auf das Model Context Protocol (MCP), das als Schnittstelle zwischen KI-Modellen und externen Werkzeugen bekannt geworden ist. WebMCP überträgt diese Idee auf den Browser: Die Website wird selbst zum Anbieter von Tools, die ein im Browser laufender Agent nutzen kann. Damit verschiebt sich die Integrationsarbeit vom Agenten zur Seite. Du als Betreiber entscheidest, welche Funktionen Du für Agenten freigibst und wie sie aufgerufen werden.
WebMCP ist ausdrücklich experimentell. Es ist ein „proposed“ Standard, der sich im Origin-Trial-Stadium befindet, und die Spezifikation kann sich noch ändern. Wer heute damit arbeitet, sollte das als frühen Test verstehen, nicht als produktionsreife, dauerhaft stabile Schnittstelle.
Deklarative und imperative Registrierung
WebMCP kennt zwei Wege, über die eine Seite ihre Tools registriert. Beide haben unterschiedliche Stärken:
- Deklarativ im HTML: Hier beschreibst Du Tools direkt in der Auszeichnung der Seite. Das eignet sich gut für Formulare und klar abgegrenzte Aktionen, die ohnehin im Markup vorliegen. Der Vorteil ist die Nähe zum bestehenden HTML und die geringe zusätzliche Logik.
- Imperativ in JavaScript: Hier registrierst Du Tools programmatisch zur Laufzeit. Das ist flexibler und erlaubt es, Tools dynamisch je nach Zustand der Anwendung bereitzustellen, etwa wenn ein Nutzer eingeloggt ist oder bestimmte Daten geladen sind.
Welcher Weg passt, hängt von der Architektur Deiner Seite ab. Eine weitgehend statische Seite mit klaren Formularen kommt oft mit der deklarativen Variante aus, während eine dynamische Single-Page-Application häufiger die imperative Registrierung nutzen wird.
Wie WebMCP mit Agentic Browsing zusammenhängt
WebMCP ist einer der vier Signalbereiche, die Google Lighthouse in der Kategorie Agentic Browsing prüft. Seit Lighthouse 13.3.0 vom 7. Mai 2026 läuft diese Kategorie standardmäßig mit, und auch PageSpeed Insights hat sie übernommen. Lighthouse prüft dabei, ob eine Seite über WebMCP Tools registriert. Neben WebMCP zählen zu den vier Signalbereichen das Vorhandensein einer llms.txt im Domain-Root, die Integrität des Accessibility-Trees sowie der Cumulative Layout Shift (CLS).
Anders als ein klassischer Score von 0 bis 100 liefert Agentic Browsing eine Pass-/Fail-Checkliste mit anteiliger Bestehensquote. Die WebMCP-Registrierung ist damit ein einzelner Prüfpunkt auf dieser Liste: Entweder Deine Seite registriert Tools nachweisbar, oder der Punkt fällt durch. Wichtig ist die Einordnung: Agentic Browsing und damit auch das WebMCP-Signal sind kein Ranking-Faktor. Google sammelt Daten und gibt Signale, beeinflusst damit aber nicht direkt Deine Position in den klassischen Suchergebnissen.
| Aspekt | Ohne WebMCP | Mit WebMCP |
|---|---|---|
| Wie der Agent handelt | Oberfläche interpretieren, Klicks simulieren | Registrierte Tools direkt aufrufen |
| Stabilität bei Layoutänderung | Bricht leicht | Bleibt stabil, solange Tool definiert ist |
| Kontrolle des Betreibers | Gering, Agent rät | Betreiber gibt Funktionen gezielt frei |
| Reifegrad | Etabliert, aber fehleranfällig | Experimentell, Origin Trial |
Ein konkretes Beispiel und die Testvoraussetzungen
Stell Dir ein Kontaktformular auf Deiner Website vor. Ohne WebMCP muss ein KI-Agent das Formular visuell erkennen, die Felder zuordnen und die Eingaben simulieren. Mit WebMCP registrierst Du das Formular als Tool, etwa „Nachricht senden“ mit den Parametern Name, E-Mail und Nachricht. Der Agent ruft dieses Tool dann strukturiert auf, übergibt die Werte und erhält ein definiertes Ergebnis zurück. Das ist robuster und vorhersehbarer als das Nachbilden von Klicks.
Um WebMCP praktisch zu testen, brauchst Du zwei Dinge: Chrome in Version 150 oder neuer und eine Registrierung für den WebMCP-Origin-Trial. Origin Trials sind das Standardverfahren, mit dem Chrome experimentelle Features für ausgewählte Domains freischaltet, ohne sie schon für alle Nutzer global zu aktivieren. Die offizielle Dokumentation beschreibt die Registrierung und die API: WebMCP bei Chrome for Developers. Weil es sich um einen experimentellen Standard handelt, kann sich die Schnittstelle ändern, und der Origin Trial ist zeitlich begrenzt.
Was Du heute sinnvoll tun kannst
Weil WebMCP experimentell ist, ergibt ein produktiver Vollausbau heute selten Sinn. Realistisch sind folgende Schritte:
- Verstehe, welche Deiner Funktionen für Agenten überhaupt relevant wären, etwa Suche, Warenkorb, Terminbuchung oder Kontakt.
- Sorge zuerst für eine saubere semantische Basis: ein intakter Accessibility-Tree und ein niedriger CLS helfen Agenten auch ohne WebMCP und sind weitere Signalbereiche der Agentic-Browsing-Kategorie.
- Lege gegebenenfalls eine
llms.txtim Domain-Root an, um den weiteren Signalbereich abzudecken. - Teste WebMCP in einer abgegrenzten Umgebung über den Origin Trial, bevor Du es breiter ausrollst.
WebMCP, llms.txt und der Accessibility-Tree im Zusammenspiel
WebMCP steht nicht für sich allein, sondern ergänzt zwei andere Mechanismen, die ebenfalls darauf zielen, eine Website für Maschinen verständlich zu machen. Es lohnt sich, die Rollen klar zu trennen, weil sie unterschiedliche Fragen beantworten. Die llms.txt im Domain-Root ist ein Wegweiser: Sie sagt einem Large Language Model, welche Inhalte und Einstiegspunkte einer Seite relevant sind, ist also eher beschreibend. Der Accessibility-Tree liefert die semantische Struktur einer einzelnen Seite, also Namen, Rollen und Sichtbarkeit der Elemente, und ist damit die Grundlage für das Verstehen der Oberfläche. WebMCP geht einen Schritt weiter und ermöglicht das Handeln: Es stellt aufrufbare Tools bereit, über die ein Agent Funktionen direkt ausführt.
In der Praxis greifen die drei Ebenen ineinander. Ein Agent kann über die llms.txt herausfinden, wo die für seine Aufgabe relevanten Bereiche liegen, über den Accessibility-Tree die konkrete Seite verstehen und über WebMCP die nötige Aktion ausführen. Fehlt eine dieser Ebenen, muss der Agent die Lücke durch Interpretation und Simulation überbrücken, was wieder fehleranfälliger wird. Genau deshalb prüft Lighthouse in der Kategorie Agentic Browsing alle drei zusammen mit dem Cumulative Layout Shift als vierten Signalbereich.
Typische Anwendungsfälle für WebMCP
WebMCP entfaltet seinen Nutzen vor allem dort, wo eine Seite klar abgegrenzte, wiederkehrende Aktionen anbietet, die ein Agent im Auftrag eines Nutzers ausführen könnte. Beispiele für solche Funktionen sind:
- Suche: Ein als Tool registrierter Suchvorgang erlaubt es einem Agenten, gezielt nach einem Produkt oder Inhalt zu suchen, statt das Suchfeld visuell finden und befüllen zu müssen.
- Warenkorb-Aktionen: Das Hinzufügen eines Produkts in den Warenkorb lässt sich als Tool definieren, sodass ein Agent es zuverlässig aufrufen kann, ohne den Button per Bild zu erkennen.
- Terminbuchung: Ein Buchungsformular mit definierten Parametern wie Datum und Uhrzeit wird über ein Tool aufrufbar und damit robuster gegen Layoutänderungen.
- Kontakt- und Anfrageformulare: Standardisierte Formulare eignen sich gut für die deklarative Registrierung, weil ihre Felder ohnehin im Markup vorliegen.
Gemeinsam ist diesen Fällen, dass die Aktion einen klaren Eingang, definierte Parameter und ein vorhersehbares Ergebnis hat. Genau das macht den Unterschied zur klassischen agentischen Nutzung aus, bei der der Agent die Absicht aus der Oberfläche ableiten muss.
Sicherheits- und Kontrollaspekte
Ein häufig übersehener Punkt bei WebMCP ist die Kontrolle darüber, was ein Agent überhaupt tun darf. Weil Du als Betreiber die Tools selbst registrierst, entscheidest Du explizit, welche Funktionen für Agenten zugänglich sind und welche nicht. Das ist ein Vorteil gegenüber der klassischen Simulation von Klicks, bei der ein Agent prinzipiell alles ansteuern kann, was sichtbar ist. Mit WebMCP definierst Du eine bewusste Schnittstelle statt einer offenen Oberfläche.
Gleichzeitig entstehen daraus neue Verantwortlichkeiten. Tools, die zustandsändernde Aktionen auslösen, etwa eine Bestellung absenden oder Daten ändern, brauchen dieselbe Sorgfalt wie jede andere öffentliche Schnittstelle: saubere Validierung der Eingaben, Schutz vor Missbrauch und eine klare Vorstellung davon, welche Aktionen ohne menschliche Bestätigung ablaufen dürfen. Weil WebMCP experimentell ist und sich im Origin-Trial-Stadium befindet, solltest Du sensible Funktionen besonders zurückhaltend freigeben und zunächst in einer abgegrenzten Umgebung testen, bevor Du sie breiter ausrollst.
WebMCP, MCP und der Origin Trial einordnen
Der Bezug zum Model Context Protocol hilft, WebMCP einzuordnen. MCP hat sich als Schnittstelle etabliert, über die KI-Modelle externe Werkzeuge und Datenquellen anbinden, etwa Datenbanken, Dateisysteme oder Dienste. WebMCP überträgt dieses Tool-Konzept auf die Ebene des Browsers und der einzelnen Website: Nicht ein Server stellt Tools für ein Modell bereit, sondern die Website selbst stellt Tools für einen im Browser laufenden Agenten bereit. Der gedankliche Kern bleibt gleich, nämlich klar definierte, aufrufbare Funktionen statt freier Interpretation, nur der Ort der Bereitstellung verschiebt sich.
Der Origin Trial ist dabei das Verfahren, mit dem Chrome dieses experimentelle Feature kontrolliert ausrollt. Statt WebMCP sofort für alle Seiten weltweit zu aktivieren, registrieren sich einzelne Domains für den Trial und schalten das Feature damit gezielt für ihre Origin frei. Das gibt Browser-Herstellern und Entwicklern die Möglichkeit, ein Feature unter realen Bedingungen zu testen und Rückmeldungen zu sammeln, bevor es zum festen Bestandteil des Browsers wird oder gegebenenfalls wieder verworfen wird. Für Dich bedeutet das zweierlei: Erstens kannst Du WebMCP heute schon ausprobieren, zweitens solltest Du Dich nicht darauf verlassen, dass die Schnittstelle in ihrer heutigen Form dauerhaft bestehen bleibt.
Praktisch heißt das auch, dass der Zugang an konkrete Voraussetzungen geknüpft ist. Du brauchst Chrome 150 oder neuer, eine Registrierung für den WebMCP-Origin-Trial und ein Verständnis dafür, ob Du Tools deklarativ im HTML oder imperativ in JavaScript bereitstellen willst. Die offizielle Dokumentation bei Chrome for Developers ist der maßgebliche Bezugspunkt, weil sich Details eines experimentellen Standards dort am verlässlichsten nachverfolgen lassen.
FAQ zu WebMCP
Was ist WebMCP in einem Satz?
Ein experimentelles Chrome-Browser-Protokoll, über das eine Website Tools registriert, damit KI-Agenten ihre Formulare und Funktionen direkt entdecken und aufrufen können.
Wie registriere ich Tools?
Entweder deklarativ direkt im HTML oder imperativ über JavaScript zur Laufzeit. Welcher Weg passt, hängt von der Architektur Deiner Seite ab.
Was brauche ich zum Testen?
Chrome 150 oder neuer und eine Registrierung für den WebMCP-Origin-Trial.
Hängt WebMCP mit Lighthouse zusammen?
Ja. Die WebMCP-Tool-Registrierung ist einer der vier Signalbereiche, die die Lighthouse-Kategorie Agentic Browsing prüft, neben llms.txt, Accessibility-Tree und CLS.
Ist WebMCP produktionsreif?
Nein. Es ist ein experimenteller, als „proposed“ gekennzeichneter Standard im Origin-Trial-Stadium, dessen Spezifikation sich noch ändern kann.