Warum braucht das Web ein eigenes Protokoll für KI-Agenten? Yoav Weiss hat in den vergangenen Monaten die WebMCP-Werkzeuge für Shopifys Storefront produktionsreif gemacht und ausgeliefert. Am 12. Oktober hat er in seinem Blog aufgeschrieben, warum er sich dafür entschieden hat. Der Text ist das Plädoyer eines Beteiligten: Weiss arbeitet inzwischen auch am Standardvorschlag mit und betont, dass er seine persönliche Meinung wiedergibt. Rückenwind sieht er durchaus – OpenAI hat WebMCP in ChatGPT Desktop eingebaut, Cloudflare unterstützt es –, zugleich läuft beim W3C noch die Prüfung durch die Technical Architecture Group, und WebKit lehnt den Ansatz ab. Was WebMCP technisch leistet, warum es laut Weiss über die Zukunft des Co-Browsings entscheidet und welche Fragen offen sind, schauen wir uns an.
Drei Wege, wie KI-Agenten mit Webdiensten interagieren
Weiss unterscheidet drei Muster. Das erste nennt er direkte Backend-Kommunikation: Der Agent ruft selbst die nötigen Schnittstellen auf, um ein Ziel zu erreichen; klassische MCP-Server von Webdiensten sind das bekannteste Beispiel. Beim zweiten Muster, dem Embedding, bettet der Agent Teile der Web-Erfahrung in seinen Chat ein und zeigt sie dem Nutzer – MCP Apps fallen in diese Kategorie. Das dritte Muster ist die direkte Interaktion im Browser, also Co-Browsing: Der Agent arbeitet parallel zu einer Browsersitzung, versteht die Seite über DOM- und Accessibility-Analyse sowie Screenshots und versucht, sie durch Klicks auf Buttons und Links zu automatisieren.
Diese Einteilung hat praktische Folgen. Weiss argumentiert, dass Co-Browsing das einzige Modell ist, in dem Entwickler und Nutzer die Kontrolle über die Erfahrung behalten und der Nutzer jederzeit vom Agenten übernehmen kann. Nur hier bleibe das Web auch tatsächlich das Web. Verlagert man dagegen alles in MCP-Server und eingebettete Widgets, wandert die Gestaltung der Erfahrung vom Website-Betreiber zum Agentenhersteller – ein Kontrollverlust, den Weiss nicht hinnehmen will.
Warum Co-Browsing gewinnen muss – und was WebMCP dafür tut
Zwischen Anspruch und Praxis liegt eine Lücke, und Weiss benennt sie offen. Keine der frühen Co-Browsing-Demos, die er gesehen hat und die auf DOM- oder Screenshot-Interaktion setzten, bot eine gute Nutzererfahrung. Sie wirkten langsam, führten dem Nutzer vor, wie der Agent sich durch die Seite tastete, und lieferten keine optimalen Ergebnisse. Man kann sich das wie einen Baumarkt vorstellen: Wer weiß, in welchem Gang die Schrauben liegen, ist in zwei Minuten fertig. Ein Helfer ohne Beschilderung läuft dagegen jede Reihe ab, öffnet Kartons und hält am Ende das falsche Gewinde in der Hand.
WebMCP setzt hier an. Die Website kann dem Agenten direkte JavaScript-Werkzeuge registrieren, die er aufrufen darf, um eine Aufgabe zu erledigen. Jedes Tool bringt ein explizites Eingabeschema mit, bald auch ein Ausgabeschema, dazu eine Beschreibung dessen, was es tut und wann es sinnvoll aufzurufen ist. Der Agent wählt dann gezielt das passende Werkzeug, statt sich wie ein Mensch durch Formulare und Klickstrecken zu arbeiten. So umgeht der Agent das langsame Tasten, das die frühen Demos so unangenehm machte; die direkte Interaktion wird laut Weiss deutlich schneller, besser und billiger.
Weiss beschreibt die Grundidee als einfach, das dahinterliegende Primitiv aber als mächtig. „WebMCP ist Web Performance für KI-Agenten im Web“, schreibt er. Nicht der Agent wird schlauer, sondern die Website wird für ihn schneller bedienbar. Nach Weiss’ Überzeugung würde das deutlich bessere Co-Browsing-Erlebnisse ermöglichen.
Was die ersten Messungen zeigen
Zahlen nennt Weiss aus zwei Quellen. Das Team von nekuda.ai hat gemessen, dass WebMCP zwischen 2,5- und 7,5-mal schneller und bis zu 47-mal günstiger arbeitet als andere Methoden der direkten Interaktion. Der Vergleich bezieht sich also nicht auf Menschen, sondern auf Agenten, die eine Seite selbst bedienen müssen. Wie die Messung aufgebaut war, beschreibt der Beitrag nicht.
Shopifys Checkout-Team, also ein Team von Weiss’ eigenem Arbeitgeber, führte ein ähnliches Experiment durch und kam auf 2,7-mal schnellere Abläufe bei 58 Prozent geringeren Kosten. Den WebMCP-Checkout-Support hatten Kollegen ergänzt, nachdem die Storefront-Werkzeuge standen. Auffällig ist die Erfolgsquote: 60 von 60 Versuchen gelangen über WebMCP, mit Browser-Automatisierung waren es 56 von 60.
Beide Zahlen stammen von Beteiligten, die WebMCP voranbringen wollen, und Versuchsaufbau, Aufgaben und Kostenrechnung sind im Beitrag nicht dokumentiert. Als allgemeingültig sollte man sie deshalb nicht lesen. Plausibel ist die Richtung trotzdem: Ein Tool-Aufruf liefert dem Agenten strukturierte Ergebnisse, während er bei der Browser-Automatisierung Screenshots und DOM-Ausschnitte deuten muss, die jeweils Rechenzeit und Token kosten.
Berechtigungen, Monitoring und Testbarkeit: die offenen Baustellen
So einfach die Grundidee ist, so viele Detailfragen hängen daran. Wer darf eigentlich Tools für eine Website registrieren? Bei dieser Frage hat sich nach Angaben von Weiss ein Permissions-Policy-Modell durchgesetzt, mit dem die Seite selbst entscheidet, welche Iframes Werkzeuge beisteuern dürfen. Außerdem sollen Tools für Agenten im Browser, für Erweiterungen und für Agenten innerhalb der Seite funktionieren – letztere potenziell aus einem Iframe einer fremden Domain. Jede dieser Varianten bringt eigene Sicherheitsfragen mit.
Offen ist auch, wie sich die Nutzererfahrung überhaupt überwachen lässt. Weiss nennt mehrere ungelöste Punkte: Welche Arten von Agenten sollen unterstützt werden? Wie bekommt man ein eindeutiges Signal vom Menschen? Wie testet man das Zusammenspiel über viele Browser und Agenten hinweg? Und wie schützt man Nutzer vor bösartigen Tools, die sich als hilfreich ausgeben? Diese Fragen werden nicht auf einmal beantwortet, sondern eine nach der anderen abgearbeitet.
Ein besonders praktisches Problem ist die Testbarkeit. Entwickler können ihre WebMCP-Implementierung heute mit dem webmcp-evals-Framework gegen einfache Modelle prüfen. Was fehlt, ist ein Weg, dieselben Tests gegen echte, repräsentative Agenten laufen zu lassen – also gegen Systeme, die einen eigenen Harness, einen Systemprompt und diverse Sicherheitsprüfungen mitbringen. Erst dann ließe sich verlässlich sagen, ob eine Website im Alltag wirklich gut funktioniert.
Bessere Websites statt Agenten?
Ein naheliegender Einwand lautet: Ist ein Agent, der durch die Seite navigiert, nicht bloß eine Krücke für schlechtes UX-Design? Würde eine bessere Produktsuche mit präziseren Kriterien nicht genügen, damit niemand durch 87 fast gleiche Produkte scrollen muss? Weiss gibt dem Einwand teilweise recht. Viele Händlerseiten lassen sich nicht nach jeder Eigenschaft filtern, die einem wichtig ist. Wer etwas sehr Bestimmtes sucht, etwa Trailrunning-Schuhe mit höchstens 5 Millimetern Sprengung oder leichte Ski zwischen 175 und 177 Zentimetern mit 80 bis 85 Millimetern Mittelbreite, scrollt ohne Agenten durch Produkte, liest Datenblätter und hofft, dass die Angabe überhaupt dasteht.
Damit ist für ihn aber nicht alles gesagt. Bei Heimwerkerprojekten lassen sich Material und Werkzeug meist online kaufen, und trotzdem hilft der Gang in den Laden, weil ein erfahrener Verkäufer den Überblick über das ganze Vorhaben gibt: was man für jeden Schritt braucht und wo man es bekommt. Agenten können ähnlich helfen, ein Projekt durchzudenken. WebMCP erlaubt Onlineshops nach Weiss, das Gegenstück zu diesem erfahrenen Verkäufer anzubieten.
WebMCP vs. HTML-Semantik: der Einwand von WebKit
Der grundsätzlichste Einwand kommt aus der Standardisierung selbst. In der laufenden Prüfung durch das W3C TAG und in der Ablehnung durch WebKit geht es um die Frage, ob JavaScript-Tools überhaupt nötig sind oder ob HTML-Semantik ausreicht. Die Sorge: Inhalte im Web könnten sich in „menschliche“ und „agentische“ Varianten aufspalten. WebKit betrachtet KI-Agenten als assistive Technologie und erwartet deshalb, dass sie für die Website unsichtbar bleiben; zusätzlich werden Missbrauchsrisiken genannt.
Weiss teilt diese Sorge teilweise, zerlegt sie aber in zwei verschiedene Risiken. Das erste ist Diskriminierung: Weil WebMCP-Aufrufe verraten, dass ein Agent beteiligt ist, könnten Websites agentische Nutzer benachteiligen. Dagegen hält er, dass Bot-Erkennung längst existiert und Websites solche Nutzer ohnehin aussperren könnten, wenn sie das wollten. Seine eigene Sorge liegt woanders: Ohne ein explizites Signal für „hier ist ein Mensch mit einem vertrauenswürdigen Agenten unterwegs“ werden agentische Nutzer fälschlich als Bots einsortiert, blockiert oder in schlechtere Varianten der Seite umgeleitet. Er hofft auf Web Bot Auth als Lösung für diesen Teil des Problems.
Das zweite Risiko ist semantische Divergenz, also unterschiedliche Fähigkeiten für agentische und nicht-agentische Besucher. Auch hier widerspricht Weiss: Solche Unterschiede gebe es bereits, etwa zwischen Nutzern mit und ohne JavaScript oder zwischen sehenden Nutzern und denen, die auf ARIA-Semantik angewiesen sind. Seiner Einschätzung nach entstehen diese Lücken aus Vernachlässigung, nicht aus Absicht. Entwickler hätten kein Interesse daran, komplett verschiedene Websites auszuliefern. Der Agent erspare einem Nutzer lediglich ein paar Umwege, das Ziel bleibe für alle dasselbe.
Aus dieser Argumentation folgt die Haltung zum Declarative WebMCP, das Formularsemantik wiederverwendet und erweitert. Weiss begrüßt den Vorschlag, sieht ihn aber als Ergänzung, nicht als Ersatz für imperative Tools. Nur Semantik für Agenten zu fordern, sei ungefähr so, als würde man JavaScript für überflüssig erklären, weil HTML ja alle Funktionen abbilden könne. Deklarative Aufrufe passen für einmalige Aktionen, doch viele Tools sind einzelne Schritte in einer längeren Aufgabe oder liefern dem Agenten nur Kontext – etwa eine Antwort aus den FAQ. Wer nach leichten Skiern mit 85 Millimetern Mittelbreite sucht, will das Ergebnis sehen und nicht dabei zuschauen, wie der Agent Kandidat für Kandidat durchblättert.
Was das für Shops bedeutet
Der Beitrag hat einen konkreten Hintergrund: Die Storefront-Werkzeuge von Shopify sind ausgeliefert, der Checkout-Support folgte. OpenAI hat WebMCP in ChatGPT Desktop integriert und die WebMCP Challenge ausgerichtet, Cloudflare unterstützt die Technik in Kitesurf und für seine Kunden, und Weiss’ eigener Vortrag auf dem W3C/GS1-Workshop zu Agentic Commerce kam nach seinen Worten sehr gut an. Beim Ausliefern stieß sein Team auf Lücken im Standardvorschlag, an deren Schließung er nun mitarbeitet. Wie WebMCP mit Zahlungen zusammenspielt, zeigt der Ansatz für Stripe-Zahlungen im Browser.
Für Händler ist ein Argument praktisch relevant. Ein Shop könnte einen eigenen Agenten ausliefern, das ist laut Weiss aber deutlich aufwendiger, und manche Nutzer wollen ohnehin lieber ihren vertrauten Agenten einsetzen als den eines Fremden. Mit WebMCP kann sich der Händler auf den Agenten des Kunden verlassen, der die Seite bedient, ohne die Intelligenz selbst liefern zu müssen. Zurück zum Baumarkt: Der Shop stellt keinen eigenen Helfer ein, er hängt eine Beschilderung auf, an der sich der Begleiter des Kunden orientiert.
Nüchtern betrachtet ist WebMCP kein fertiger Standard, sondern ein Vorschlag mit vielen offenen Fragen und einem gewichtigen Gegner in WebKit. Weiss’ Schluss ist entsprechend eine Überzeugung, keine Prognose: Er will, dass das Web als weitreichendste Computerplattform der Welt auch im Zeitalter der Agenten besteht. Dafür müsse Co-Browsing gewinnen, und WebMCP passe genau zu diesem Ziel – deshalb steckt er seine Energie hinein. Für Shopbetreiber heißt das vorerst: die Diskussion verfolgen und prüfen, welche Aufgaben ihres Shops sich als Werkzeug beschreiben ließen.
Quelle: blog.yoav.ws
