WebMCP erklärt: Browser-Standard für KI-Agenten

Ein Agent, der sich durch eine Website klickt, weil er nichts anderes kann, ist wie ein Kollege, der jede Software nur über Screenshots bedient. WebMCP gibt ihm stattdessen echte Knöpfe in die Hand.

Ich beschäftige mich seit einiger Zeit intensiv mit Skills für KI-Agenten und mit Standards, die Websites für Agenten lesbar machen, etwa DESIGN.md für Design Tokens. Beim Schreiben meines Artikels über llms.txt bin ich auf eine Bemerkung von Googles John Mueller gestoßen, die mich nicht mehr losgelassen hat: Er bevorzuge Ansätze, bei denen Agenten klare Ziele und Prozesse angeboten werden, gegenüber einer statischen Datei wie llms.txt. Genau das ist die Grundidee von WebMCP – und ich halte sie für den bisher interessantesten Vorschlag, wie Websites und KI-Agenten künftig zusammenarbeiten könnten.

Was WebMCP ist

WebMCP ist eine vorgeschlagene Browser-Schnittstelle: eine neue navigator.modelContext-API, über die eine Website JavaScript-Funktionen als "Werkzeuge" registriert, die ein Agent im Browser entdecken und aufrufen kann.

Die Geschichte dahinter ist noch jung. Der Entwickler Alex Nahas baute Anfang 2025, damals bei Amazon, einen Prototyp namens MCP-B ("browser"), um ein konkretes Problem des klassischen Model Context Protocol zu lösen: die aufwendige OAuth-2.1-Authentifizierung gegenüber einem separaten MCP-Server. Parallel arbeiteten die Chrome- und Edge-Teams an ähnlichen Ideen für "Skript-Werkzeuge". Im August 2025 reichten Google und Microsoft gemeinsam einen Vorschlag beim W3C ein, im September 2025 nahm die W3C Web Machine Learning Community Group das Thema offiziell zur Inkubation an. Im Februar 2026 folgte ein erster Draft Community Group Report.

Der Stand im September 2026: Chrome 146 Canary unterstützt eine erste Version hinter einem Flag, ein breiterer Origin Trial ist für Chrome 149 angekündigt, Angular hat bereits experimentelle Unterstützung. Volle Unterstützung in stabilen Browsern wird für die zweite Jahreshälfte 2026 anvisiert. Chrome selbst bezeichnet den aktuellen Stand ausdrücklich als frühe Vorschau, die sich vor einem finalen Release noch deutlich ändern kann.

Der Unterschied zum klassischen MCP

Das "normale" Model Context Protocol, wie es Anthropic für Claude entworfen hat, ist ein Backend-Protokoll: Ein Client spricht per JSON-RPC mit einem eigens gehosteten MCP-Server, inklusive OAuth-2.1-Authentifizierung. Das braucht eigene Infrastruktur.

WebMCP dreht dieses Modell um: Die Website selbst wird zum Server. Sobald ein Agent auf einer Seite landet, kann diese ihre Werkzeuge direkt im Browser bereitstellen – über eine imperative API (navigator.modelContext.registerTool(), dazu provideContext(), unregisterTool(), clearContext()) oder deklarativ über annotierte HTML-Formulare. Jedes Werkzeug bekommt einen Namen, eine Beschreibung in natürlicher Sprache, ein JSON-Schema für die Eingabe und eine ausführbare Funktion.

Der entscheidende praktische Vorteil: Die Werkzeuge laufen mit der bestehenden Session des Nutzers, inklusive Cookies und Rechten. Kein separater Auth-Handshake, kein zweiter Login für den Agenten. Und der Agent ruft eine klar definierte Funktion auf, statt das DOM zu interpretieren oder Klicks zu simulieren.

Warum mich das wirklich interessiert

Der Kern des Problems, das WebMCP lösen soll, kennt jeder, der schon mal Browser-Automatisierung gebaut oder benutzt hat: Sie ist brüchig. Ein Agent, der sich per Screenshot durch eine Oberfläche tastet, braucht nach den zitierten ersten Vergleichswerten 5 bis 10 Sekunden pro Aktion bei einer Fehlerquote von 15 bis 20 %. Ruft er stattdessen ein registriertes Werkzeug direkt auf, sind es 1 bis 2 Sekunden bei nahezu keinen Fehlern. Andere Quellen sprechen von rund 89 % weniger Tokenverbrauch gegenüber screenshot-basierten Ansätzen. Ich behandle diese Zahlen mit Vorsicht, sie stammen aus Anbieter- und Community-Blogposts, nicht aus unabhängigen Studien – aber die Richtung leuchtet mir sofort ein.

Typische Beispiele aus der bisherigen Diskussion:

Ein Shop registriert ein Werkzeug addToCart(productId, quantity, size, color). Statt Produktseite zu öffnen, Größe anzuklicken, Button zu treffen, ruft der Agent die Funktion direkt auf.
Eine Reiseseite bietet searchFlights, findHotels und makeReservation an, sodass eine Anfrage wie "finde mir einen Flug nach Istanbul" direkt die passende Funktion aufruft, statt ein Formular visuell auszufüllen.

Für mich ist das die konsequente Weiterentwicklung dessen, was ich schon bei DESIGN.md und Skills spannend finde: Websites und Anwendungen hören auf, ausschließlich für menschliche Augen gebaut zu sein, und beginnen, sich zusätzlich als maschinenlesbare, handlungsfähige Schnittstelle zu verstehen.

Wer daran beteiligt ist

Co-Autoren des Vorschlags sind die Chrome- und Edge-Teams, inkubiert wird er in der W3C Web Machine Learning Community Group, Spezifikation und Explainer liegen offen auf GitHub. Anthropic ist bislang nicht als Spec-Mitautor gelistet, Claude wird in der Dokumentation aber ausdrücklich als eine der Zielplattformen genannt, neben ChatGPT, Gemini und Copilot. Im GitHub-Repo von Claude Code existiert bereits ein offener Feature-Request für WebMCP-Unterstützung in der Chrome-Extension – umgesetzt ist er noch nicht.

Was noch ungelöst ist

Ich würde WebMCP aktuell als vielversprechend, aber ausdrücklich nicht produktionsreif einordnen. Die W3C-eigenen technischen Notizen benennen offene Punkte, die ich ernst nehmen würde:

Keine sichtbare Erlaubnisabfrage. Anders als bei Kamera, Standort oder Mikrofon gibt es bislang keinen Hinweis für Nutzer, wenn eine Seite Werkzeuge registriert.
Prompt Injection über Werkzeugdefinitionen. Eine bösartige oder kompromittierte Seite könnte über ihre Werkzeugbeschreibungen versuchen, einen Agenten zu manipulieren.
Spezifische Angriffsmuster. Aktuelle Forschung beschreibt WebMCP-eigene Angriffe wie "Tool Squatting", "Tool Substitution" und Angriffe über AbortSignal, die gezielt die Werkzeugliste manipulieren, die ein Agent sieht.
Die "lethal trifecta" bleibt bestehen. Eine bösartige Seite in einem anderen Tab könnte einen Agenten weiterhin dazu bringen, Daten abzugreifen oder Aktionen außerhalb des eigentlichen Kontexts auszulösen. WebMCP verkleinert dieses Risiko, weil Agenten auf deklarierte Funktionen beschränkt sind statt auf vollen DOM-Zugriff, beseitigt es aber nicht.
Namensverwirrung. WebMCP teilt das Grundkonzept mit dem eigentlichen MCP, ist aber kein JSON-RPC und verzichtet auf Konzepte wie "Prompts" oder "Resources". Das sorgt aktuell für einiges an Verwechslung.

Dazu kommt eine strukturelle Spannung, die ich für die eigentlich unbequeme Frage halte: Agentenfreundlichkeit und Umsatzmodell stehen sich teilweise entgegen. Eine Seite, die Kaufabschlüsse für Agenten möglichst reibungslos macht, verzichtet damit auch auf Werbeflächen, Upsells und die Reibung, die menschliche Besucher heute noch monetarisiert. Diese Frage löst der Standard nicht, das ist auch nicht seine Aufgabe – aber wer WebMCP für die eigene Seite plant, sollte sie sich stellen, bevor der erste Agent tatsächlich einkauft.

Mein Fazit

WebMCP ist genau die Art von Standard, bei der ich lieber früh mitdenke als spät reagiere. Der Ansatz löst ein reales, spürbares Problem: brüchige Browser-Automatisierung durch echte, deklarierte Funktionen ersetzen, ohne dass ein Agent sich extra einloggen muss. Gleichzeitig ist der aktuelle Stand ausdrücklich eine frühe Vorschau ohne fertiges Sicherheitsmodell, ohne Browser-Konsens und ohne produktionsreife Implementierung.

Meine praktische Einordnung für alle, die selbst Websites bauen: Beobachten, verstehen, bei Gelegenheit an unkritischer Stelle experimentieren – aber noch keine Geschäftslogik darauf aufbauen, die auf einen stabilen Sicherheitsrahmen angewiesen ist, der schlicht noch nicht existiert. Genau das ist der Unterschied zu llms.txt: Dort ist die Enttäuschung, dass ein einfacher Standard fast nichts bewirkt. Bei WebMCP ist das Risiko das gegenteilige – ein Standard, der tatsächlich etwas verändern könnte, bevor die Fragen rund um Sicherheit und Vertrauen sauber beantwortet sind.

WebMCP erklärt: Wenn Websites selbst zum Werkzeug für KI-Agenten werden