WebMCP ist eine vorgeschlagene Browser-API, die strukturierte Tools für einen KI-Agenten im Auftrag eines Nutzers erkennt, beschreibt und ausführt. Die Website deklariert, was eine Aktion tut und welche Eingaben sie akzeptiert; der Agent ruft dieses Tool auf, statt zu raten, welche Schaltfläche oder welches Feld anzuklicken ist. Das kann ein Formular, einen Buchungsablauf oder eine Diagnoseaufgabe schneller und zuverlässiger machen, ist aber kein universeller Ersatz für Browser-Automatisierung. die WebMCP-Dokumentation von Chrome
Die praktische Entscheidung ist architektonisch. WebMCP ist Kooperation auf der Serverseite: Der Site-Betreiber veröffentlicht einen Vertrag für Agenten. Browser-Automatisierung ist Beobachtung auf der Clientseite: Ein Agent bedient die Oberfläche, die bereits existiert, einschließlich einer autorisierten angemeldeten Sitzung. Nutze Ersteres, wenn du die Website kontrollierst und sichere Tools definieren kannst; nutze Letzteres, wenn du mit dem heutigen Web arbeiten musst. die Hinweise zu sicheren Tools
Was ist WebMCP?
WebMCP (Web Model Context Protocol) ist ein browserseitiger API-Vorschlag des Chrome-Teams und der WebMCP-Community. Chrones Dokumentation beschreibt es als Weg, strukturierte Tools für Agenten zu bauen und bereitzustellen, ohne die sichtbare Webanwendung und die Kontrolle der Nutzer aufzugeben. Eine Website kann ein Such-, Checkout-, Datumsauswahl-, Support- oder Diagnose-Tool als progressive Verbesserung veröffentlichen; ein Mensch kann dieselbe Seite weiter nutzen, wenn kein Agent anwesend ist. die Ankündigung des Origin Trial von Chrome
Wie funktioniert WebMCP?
Eine WebMCP-Seite registriert Tools beim Browser. Jedes Tool hat einen Namen, eine Beschreibung, ein Eingabe-Schema und eine Implementierung, die in der Seite läuft. Die imperative API nutzt JavaScript für eigene Aktionen; die deklarative API zeichnet gewöhnliche HTML-Formulare aus. Die Dokumentation von Chrome nennt drei Teile, die für einen Agenten zählen: Discovery, JSON-Schemas für Ein- und Ausgaben und Zustand, der beschreibt, was die aktuelle Seite leisten kann.
Das Ergebnis kann ein kürzerer Aktionspfad sein. Statt ein großes DOM zu lesen, aus einer Schaltfläche auf submit_application zu schließen und zu hoffen, dass ein Selektor ein Redesign übersteht, kann ein Agent das benannte Tool mit schema-beschriebenen Feldern aufrufen. Die Aktion läuft weiterhin sichtbar in der Website ab, sodass die Seite Fortschritt anzeigen und vor einem Kauf oder einer anderen zustandsändernden Operation Bestätigung verlangen kann.
Was hat unser WebMCP-Praxistest ergeben?
Am 11. September 2026 haben wir einen geführten Test auf der offiziellen Hotel-Chain-Demo von Chrome Labs durchgeführt, mit Google Chrome 152.0.7977.76 unter macOS und WebMCP Model Context Tool Inspector 1.9.15. Die bedienende Person nutzte synthetische Gästedaten, keinen Gemini-API-Schlüssel und keine echten Hotel-, Zahlungs- oder Kontozugangsdaten. Das war ein Verhaltensdurchlauf, kein Geschwindigkeits- oder Zuverlässigkeitsbenchmark.
- Der Inspector erkannte die Tools und Schemas der Seite. Wir riefen search_location für Paris, den 18. September, drei Nächte und eine erwachsene Person auf; die Seite zeigte zwei Unterkünfte.
- Wir riefen filter_search_results mit breakfast auf. Die sichtbare Trefferzahl änderte sich von zwei auf eins und es blieb Montmartre Suites übrig.
- Wir öffneten dieses Hotel, starteten den Buchungsablauf und gaben die synthetische Identität Alex Chen an. Das Tool bereitete das Formular vor, schloss die Reservierung aber nicht ab.
- Die Seite blieb bei Confirm Reservation stehen. Erst nachdem die bedienende Person diese Schaltfläche angeklickt hatte, zeigte die Demo Reservation Confirmed.
Eine Einschränkung des Werkzeugs war ebenfalls wichtig: Die Aktion Copy trace des Inspectors gab nach unserem manuellen Execute-Tool-Ablauf ein leeres JSON-Array zurück. Deshalb nutzen wir Screenshots und eine strukturierte Schrittaufzeichnung als Belege für diesen Durchlauf und verallgemeinern dieses Trace-Ergebnis nicht auf andere Modi des Inspectors.
Wie unterscheidet sich WebMCP von Browser-Automatisierung?
WebMCP und Browser-Automatisierung lösen unterschiedliche Fehlerarten. WebMCP beseitigt Mehrdeutigkeit, wenn die Website einen guten Vertrag veröffentlicht. Klassische Automatisierung, etwa Playwright, Selenium, browser-use oder ein Agent, der einen echten Browser steuert, bearbeitet Websites ohne Vertrag, indem sie die gerenderte Seite liest und mit ihr interagiert. WebMCP ergänzt Automatisierung daher: Ein Client kann ein Seiten-Tool aufrufen, wenn es verfügbar ist, und auf gewöhnliches Browsen zurückfallen, wenn nicht.
Am leichtesten prüft man den Unterschied als Fähigkeitsgrenze. Lies vor der Wahl eines Weges sowohl die positive als auch die negative Spalte.
| Ansatz | Was er kann | Was er nicht kann |
|---|---|---|
| WebMCP | Benannte, schema-beschriebene Tools aufrufen, die eine Seite bereitstellt | Seiten erreichen, die keine Tools registrieren, oder ein separates Browser-Login einbinden |
| DOM-basierte Automatisierung | Nahezu jede gerenderte Seite über Selektoren, Screenshots oder den Barrierefreiheitszustand bedienen | Die beabsichtigte Aktion der Website kennen, ohne die Oberfläche zu interpretieren |
| Wiederverwendung einer echten Browser-Sitzung | Einen ausdrücklich bereitgestellten, autorisierten angemeldeten Browserzustand nutzen | Zugang garantieren, CAPTCHA umgehen oder Website-Regeln außer Kraft setzen |
Ein praktischer Rollout beginnt mit einem nur lesenden Tool, einem unterstützten Browser und einem sichtbaren Bestätigungsschritt. Erweitere erst, wenn der Rückfallweg funktioniert.
Die Sitzungsgrenze ist ebenso wichtig. WebMCP läuft innerhalb der vom Client besuchten Seite; es überträgt die Chrome-Cookies eines Nutzers nicht in eine neue Cloud-Sitzung. Auf einer Website ohne WebMCP ist ego (lite) der lokale Chromium-Browser für KI-Agenten: Du stellst den Browserzustand ausdrücklich bereit, und ein kompatibler Agent bedient die Website über ego-browser in einem eigenen, sichtbaren Space. Der Space hält die Tabs und die Steuerung der Aufgabe von deiner aktiven Arbeit getrennt, ist aber weder eine Remote-VM noch eine Grenze zur Mandantenisolierung. Dieser Weg ändert das Browser-Ausführungsmodell, nicht den UI-Vertrag der Website. die Versionshinweise zu OpenClaw 2.0
Nutze diese Bewertungstabelle, um die Entscheidung ausdrücklich zu machen, statt WebMCP als universelles Upgrade zu behandeln.
| Bewertungsfrage | Wähle WebMCP, wenn ... | Wähle Browser-Automatisierung, wenn ... |
|---|---|---|
| Kontrollierst du die Website? | Ja; du kannst Seiten-Tools ausliefern und absichern | Nein; du arbeitest mit einer fremden Website |
| Braucht die Aufgabe ein bestehendes Login? | Die eigene authentifizierte Sitzung der Seite genügt | Der Agent muss eine separat bereitgestellte lokale Sitzung wiederverwenden |
| Was ist das Ziel des Einsatzes? | Ein stabiler, typisierter Vertrag für unterstützte Clients | Ein sofortiger Ablauf über mehrere Seiten, ohne Anpassungsaufwand |
Wann solltest du WebMCP einsetzen?
Wähle WebMCP, wenn dir die Anwendung gehört, du stabile Aufgabengrenzen definieren kannst und Agenten strukturierte Arbeit erledigen sollen, etwa Support-Formulare, Reisesuche, Checkout oder interne Diagnose. Besonders nützlich ist es bei komplexen Oberflächen, bei denen ein Mensch die beabsichtigte Aktion kennt, ein Agent aber sonst viele interpretierte Klicks bräuchte. Halte das Tool klein, typisiert und beobachtbar.
Wähle echte Browser-Automatisierung, wenn du die Website nicht kontrollierst, ein bestehendes autorisiertes Login brauchst, über viele unabhängige Websites hinweg arbeiten musst oder einen Ablauf heute brauchst statt nach der Anpassung der Website. Für feste CI-Skripte bleibt deterministische Automatisierung sinnvoll; für interaktive angemeldete Arbeit gibt ein sichtbarer lokaler Browser dem Agenten dasselbe Konto und denselben Seitenzustand, die ein Mensch prüfen kann.
Welche Sicherheitsgrenzen hat WebMCP?
WebMCP verleiht nicht von sich aus Befugnisse. Chrome steuert die APIs über Origin-Isolation und die Berechtigungsrichtlinie tools; Cross-Origin-iframes sind standardmäßig deaktiviert. Eine Website kann Tools nur für Origins bereitstellen, denen sie vertraut, und Chrones Sicherheitshinweise empfehlen readOnlyHint für nicht verändernde Tools und untrustedContentHint, wenn die Ausgabe nutzergenerierten oder externen Text enthält.
Prompt Injection bleibt möglich, weil ein Agent Anweisungen und Webinhalte gemeinsam verarbeitet. Halte Beschreibungen und Ausgaben knapp, validiere Eingaben auf dem Server, verlange bei folgenreichen Aktionen die Bestätigung durch die Nutzer und stelle nur die kleinste nötige Menge an Origins und Tools bereit. WebMCP ist eine klarere Schnittstelle, kein Grund, Authentifizierung, Autorisierung, Audit-Logs oder menschliche Prüfung zu überspringen.
Welche Herausforderungen und Grenzen hat WebMCP?
WebMCPs größte Einschränkung ist die Verbreitung: Ein Client muss eine kompatible Seite besuchen und der Browser muss die experimentelle API implementieren. Chrome merkt außerdem an, dass Headless-Szenarien nicht das primäre Designziel sind, komplexe Anwendungen eine Umstrukturierung ihres Zustands brauchen können und der Vorschlag sich weiter ändert.
Das ergibt auf absehbare Zeit einen gemischten Stack. Eine Website kann ein hervorragendes Checkout-Tool bereitstellen und die Kontoeinstellungen als gewöhnliche DOM-Steuerelemente belassen; ein Browser kann WebMCP im Test unterstützen, aber nicht in deiner Produktionsflotte. Behalte einen normalen Automatisierungs-Rückfallweg und miss Tool-Fehler, Bestätigungsquoten und Übergaben an Menschen über wiederholte Durchläufe hinweg.
Wie kannst du WebMCP heute ausprobieren?
Aktiviere für lokale Experimente chrome://flags/#enable-webmcp-testing in Chrome und starte neu. Für Live-Tests verweist Chrones Dokumentation Entwickler auf den Origin Trial ab Chrome 149. Nutze die offiziellen Demos und die Erweiterung Model Context Tool Inspector, um registrierte Tools zu sehen, sie manuell aufzurufen und sowohl gültige als auch ungültige Eingaben zu testen. Da der Vorschlag aktiv diskutiert wird, fixiere die Browserversion und rechne mit API-Änderungen. die OpenAI WebMCP Challenge
Wenn du Agenten nutzt und nicht Site-Betreiber bist, musst du nicht auf die Verbreitung von WebMCP warten. Starte /ego-browser in deinem unterstützten Coding-Agenten, beschreibe die begrenzte Aufgabe und halte Browser-Sitzung und Berechtigungen ausdrücklich. Beide Ansätze werden nebeneinander bestehen: WebMCP macht kooperierende Websites leichter bedienbar; echte Browser-Automatisierung erreicht den Rest.
Häufig gestellte Fragen
Ist WebMCP dasselbe wie ein MCP-Server?
Nein. Ein klassischer MCP-Server ist ein externer Prozess oder Dienst, der einem Client Tools bereitstellt. WebMCP stellt Tools aus der Webseite selbst für einen Agenten im Browser bereit, mit Grenzen aus Browser-Origin und Berechtigungsrichtlinie.
Kann WebMCP eine Website automatisieren, die kein WebMCP unterstützt?
Nein. Der Client muss eine Seite besuchen, die Tools registriert. Nutze gewöhnliche Browser-Automatisierung für eine Website, die WebMCP nicht eingeführt hat, und halte für menschliche Eingaben an, wenn Authentifizierung oder eine Herausforderung es verlangen.
Wer muss WebMCP implementieren?
Der Betreiber der Website implementiert die WebMCP-Tools; ein Agenten-Client und ein Browser müssen sie nutzen können. Ein Besucher kann einem fremden Website keine Tools hinzufügen.
Was sind die wichtigsten Vorteile von WebMCP?
WebMCP gibt Agenten benannte Aktionen, schema-beschriebene Eingaben und Seitenzustand, was auf kooperierenden Websites das Raten bei Selektoren und interpretierte Klicks reduziert. Die Anwendung muss trotzdem jede Nutzlast validieren.
Was sind die wichtigsten Einschränkungen von WebMCP?
WebMCP braucht die Einführung auf den Seiten und Unterstützung im Browser, bleibt in Chrome experimentell und löst weder Headless-Gleichstand noch Authentifizierungsrichtlinien noch Prompt Injection.
Können WebMCP-Tools ohne Menschen laufen?
Einige risikoarme Tools können automatisch laufen, aber sensible Aktionen sollten Interaktion und Bestätigung durch die Nutzer verlangen. Das Design von Chrome zielt auf lokale Browserabläufe mit einem Menschen im Ablauf.
Stellt WebMCP Tools für jedes iframe bereit?
Nein. Origin-Isolation und die Berechtigungsrichtlinie tools steuern die Registrierung; Cross-Origin-iframes brauchen ausdrückliche Erlaubnis und vertrauenswürdige Bereitstellung.
Wie lange bleibt die WebMCP-API stabil?
Es gibt noch keine Stabilitätsgarantie. Chrome bezeichnet WebMCP als vorgeschlagenen Standard in aktiver Diskussion, also fixiere Versionen und verfolge den Explainer und die Origin-Trial-Hinweise.
Kann ich WebMCP mit einem angemeldeten Konto nutzen?
Eine Seite kann Tools innerhalb ihrer eigenen authentifizierten Sitzung bereitstellen, aber WebMCP überträgt keine Cookies in einen anderen Browser. Halte Autorisierung und Bestätigung im Sicherheitsmodell der Website.
Was sollte ich nutzen, solange eine Website kein WebMCP hat?
Nutze gewöhnliche Browser-Automatisierung. Für eine autorisierte lokale Sitzung lässt ego (lite) einen unterstützten Agenten über /ego-browser einen separat bereitgestellten echten Browser bedienen.
Wo kann ich die Implementierungshinweise lesen?
Beginne mit der WebMCP-Dokumentation von Chrome, den Hinweisen zu sicheren Tools, der Origin-Trial-Seite und dem WebMCP-Explainer auf GitHub; die Links stehen in den Quellenhinweisen unten.