WebMCP lässt KI-Agenten deine Website benutzen, nicht nur lesen

Am 21. August 2026 hat Shopify WebMCP-Tools über jedem Liquid-Storefront scharf geschaltet. Zwölf Tools pro Shop: search_catalog, browse_store, get_product, get_cart, update_cart, proceed_to_checkout, manage_orders und eine Handvoll mehr. Kein Händler hat etwas installiert. Kein Händler hat etwas freigegeben. Eines Morgens hat ihr Shop einfach angefangen, KI-Agenten einen Satz Knöpfe zum Drücken anzubieten.

Vier Tage später, am 25. August, hat OpenAI die andere Seite dieses Handschlags im eingebauten Browser der ChatGPT-Desktop-App eingeschaltet und einen zehntägigen Hackathon mit Chrome, Cloudflare, Shopify, Vercel, Render und Netlify gefahren, damit Entwickler dagegen bauen.

Wir sind also in etwa achtzehn Monaten von "KI liest deine Website" zu "KI bedient deine Website" gekommen. Das ist der Teil, der Aufmerksamkeit verdient. Fast alles andere, was gerade über WebMCP geschrieben wird, ist ein Zukunftssicherungs-Panikpitch, und ich bin ehrlich zu dir: Ich habe das für keinen Kunden ausgeliefert. Ich habe die Spezifikation gelesen, den Inspector laufen lassen und mir eine Meinung darüber gebildet, wen es angeht. Diese Meinung lautet größtenteils "dich nicht, noch nicht, und hier ist die eine Sache, die du trotzdem tun solltest".

Was WebMCP tatsächlich ist

WebMCP ist eine vorgeschlagene Browser-API, mit der eine Webseite aufrufbare Tools direkt aus JavaScript registriert, sodass ein KI-Agent im Browser eine Funktion auf deiner Seite aufrufen kann, statt zu raten, welchen Knopf er drücken muss.

Die aktuelle Form sieht so aus. Du rufst document.modelContext.registerTool() auf und übergibst einen Namen, eine Beschreibung in normalem Deutsch oder Englisch, ein JSON-Schema für die Eingaben und eine execute-Funktion, die die Sache tatsächlich tut. Der Agent fragt die Seite, welche Tools es gibt, liest deine Beschreibungen und ruft das auf, das zur Nutzeranfrage passt. Es gibt auch eine deklarative Variante, die normale HTML-Formulare annotiert, aber sie ist dünner und schlechter unterstützt.

Der Status zählt mehr als die Syntax. Stand 4. September 2026 ist die Spezifikation ein Draft Community Group Report der W3C Web Machine Learning Community Group. Das ist kein W3C-Standard. Es ist nicht mal auf dem Standards Track. Eine Community Group ist näher an einem öffentlichen Workshop als an einem Normungsgremium: Jeder kann beitreten, das Ergebnis trägt keine formale Billigung, und nichts bindet irgendjemanden.

Die Autoren sind Ingenieure von Microsoft und Google, was dir sagt, dass die Browserhersteller interessiert sind. Es sagt dir nicht, dass die Sache fertig ist.

Wenn du einen Beitrag liest, der WebMCP "den neuen W3C-Standard" nennt, ist dieser Beitrag falsch, und er ist in die Richtung falsch, die dir Dienstleistungen verkauft.

Wie es sich von MCP, llms.txt und Schema-Markup unterscheidet

Die Ein-Satz-Version: Bei llms.txt geht es darum, gelesen zu werden, bei Schema-Markup darum, verstanden zu werden, und bei WebMCP darum, benutzt zu werden.

Ich habe über Model Context Protocol geschrieben, als es das Neue war, und MCP ist hier wirklich der Elternteil. Aber MCP ist ein Serverprotokoll. Du stellst einen MCP-Server hin, ein Agent verbindet sich über einen Transport, und das Ding läuft irgendwo mit eigener Authentifizierung, eigenem Hosting, eigenem Deploy. WebMCP verschiebt diese Idee in die Seite selbst. Die Tools laufen in Client-seitigem Skript, in der bereits authentifizierten Browsersitzung des Nutzers, auf deinem Origin. Die Spezifikation selbst formuliert es so, dass man sich eine WebMCP-Seite als MCP-Server vorstellen kann, dessen Tools in der Seite statt auf einem Backend implementiert sind.

Genau dieser Unterschied ist der springende Punkt. Wenn ein Kunde in seinem Browser in deinem Buchungssystem eingeloggt ist, kann ein Tool in der Seite ihm mit der Sitzung, die er schon hat, einen Termin buchen. Keine API-Schlüssel, kein OAuth-Tanz, kein separater Dienst zu betreiben. Das ist ein echter Vorteil gegenüber "bau doch einfach eine gute API", und deswegen existiert dieser Vorschlag, statt dass alle REST-Endpunkte ausliefern.

Strukturierte Daten nach Schema.org und llms.txt tun etwas kategorial anderes. Sie beschreiben. Sie sagen: "Diese Seite ist eine Zahnarztpraxis in Augsburg mit diesen Öffnungszeiten." Sie können nichts buchen. Wenn dein Ziel ist, in KI-Antworten genannt zu werden, ist das weiterhin das Zitierspiel, das ich nach der Studie über 1,4 Millionen Prompts aufgeschlüsselt habe, und es hat nichts mit WebMCP zu tun. Anderes Problem, andere Lösung, und sich klar zu sein, welches man löst, spart viel verschwendetes Budget.

Wer es heute tatsächlich unterstützt

Chrome hat WebMCP von einem Canary-Flag in einen öffentlichen Origin Trial in Chrome 149 überführt, angekündigt am 9. Juni 2026. Origin Trial heißt: Du registrierst ein Token, lieferst es im Produktivbetrieb aus, und Google sammelt Rückmeldungen mit der ausdrücklichen Erwartung, dass sich die API ändert. Lokal kannst du es über chrome://flags/#enable-webmcp-testing einschalten. Edge hat in Version 147 im März 2026 eine flag-gesteuerte Vorschau ergänzt. Es gibt eine Model-Context-Tool-Inspector-Erweiterung, um deine Tools von Hand gegen Gemini zu testen.

Auf der Agentenseite ist das Bild dünner, als die Schlagzeilen vermuten lassen. ChatGPT unterstützt Site-Tools in seinem Desktop-Browser für ChatGPT Work und Codex, auf bestimmten Modellen, und nicht in Enterprise- oder Edu-Workspaces. Deklarative Formular-Tools werden nicht unterstützt. Tools in iframes werden nicht gefunden. Nur ein Teil der API funktioniert.

Claude in Chrome konsumiert keine WebMCP-Tools. Es gibt einen offenen Feature Request dafür. Anthropic hat MCP erfunden und sich öffentlich nicht zu WebMCP geäußert. Gemini und Perplexity lesen Seiten weiter auf die alte Art, über das DOM und Screenshots.

Also: zwei Browser hinter Flags oder Trials, ein Agentenprodukt mit einer Liste von Vorbehalten und eine sehr große Commerce-Plattform, die Tools an Millionen Storefronts ausgeliefert hat, die bisher fast nichts aufruft. Shopifys eigene Doku sagt es klar: Die Tools sind live, die Agentenunterstützung ist auf Chromium-Browser beschränkt. Alle bauen die Steckdose, bevor es den Stecker gibt.

Die API hat sich unter allen umbenannt

Hier ist mein Lieblingsdetail, denn es ist das, was entscheidet, ob du einen Sprint darauf verwenden solltest.

Ein früherer Entwurf hatte eine provideContext()-Methode. Sie wurde im März 2026 entfernt. Die API wandert außerdem von navigator.modelContext zu document.modelContext. Keine Deprecation mit Polyfill und achtzehn Monaten Vorlauf. Eine Umbenennung, in einem Entwurf, weil die Form beim ersten Mal falsch war.

Jedes Tutorial, das vor dem Frühjahr 2026 geschrieben wurde, lehrt jetzt Code, der nicht läuft. Jede Agentur, die im ersten Quartal ein "WebMCP-fertig"-Paket ausgeliefert hat, darf es noch mal machen. Für einen Community-Group-Entwurf ist das völlig normal. Es ist auch genau der Grund, warum "sicher deine Seite jetzt mit WebMCP für die Zukunft ab" ein verkehrter Rat ist: Es gibt noch keine Zukunft, gegen die man absichern könnte, nur einen Entwurf, der sich weiter bewegt. Wenn du doch dagegen baust, mach Feature Detection, halt es in einem isolierten Modul und geh davon aus, dass du es neu schreibst.

Die Sicherheitsfragen sind der ernste Teil

Der Abschnitt der Spezifikation zu Sicherheit und Datenschutz ist ehrlicher als der meiste Marketingtext dazu, und dort würde ich anfangen, wenn ein Kunde mich um eine Umsetzung bäte.

Er benennt drei Injektionsvektoren. Metadaten-Vergiftung, bei der bösartige Anweisungen in der Beschreibung eines Tools stecken und das Denken des Agenten lenken. Output-Injection, bei der das, was dein Tool zurückgibt, Anweisungen enthält, die beeinflussen, was der Agent als Nächstes tut. Und das Angreifen der Tool-Implementierung, bei dem wertvolle Funktionalität offenzulegen sie schlicht zu einem größeren Ziel macht. Die Spezifikation räumt außerdem eine Vertrauenslücke ein, die sie nicht schließen kann: Es gibt keine Garantie, dass die deklarierte Absicht eines Tools seinem tatsächlichen Verhalten entspricht. Der Agent liest deinen englischen Satz und entscheidet. Prüfen kann er es nicht.

Dann gibt es Over-Parameterization, das stille Problem. Ein schlampiges Eingabeschema an deinem Buchungstool wird zum Exfiltrationskanal für alles andere, was der Agent über den Nutzer weiß, inklusive Browserkontext und persönlicher Daten. Du hast ein Formularfeld geschrieben. Ausgeliefert hast du eine Datenleitung.

Die Zugriffskontrolle ist so weit vernünftig. Tools sind über eine tools-Permissions-Policy mit Standardwert self abgesichert, Origin-Isolation ist Pflicht, und Cross-Origin-Freigabe braucht eine ausdrückliche Opt-in-Liste. Aber bei der Frage, die alle wirklich interessiert, nämlich ob der Nutzer zugestimmt hat, bevor ein Agent sein Geld ausgibt, hat die Spezifikation keinen normativen Mechanismus. Es gibt eine consequentialHint-Annotation, die du setzen kannst, und das ist ein Vorschlag, kein Tor. OpenAI legt bei jedem Aufruf eine eigene Sicherheitsprüfung darüber. Das ist eine Anbieterrichtlinie, keine Garantie, und sie unterscheidet sich je Anbieter.

Nichts davon ist theoretisch. Brave hat indirekte Prompt Injection gegen Perplexitys Comet dokumentiert, inklusive eines Angriffs, der über eine Kalendereinladung den Browser gegen seinen eigenen Nutzer handeln ließ, und einer Variante, die einen Passwortmanager übernahm, in dem der Nutzer bereits angemeldet war. Eine Studie der University of Washington vom Juni 2026 fand, dass vier von sieben populären agentischen Browsern eine bösartige Seite die Same-Origin-Policy umgehen ließen, mit einem funktionierenden Datendiebstahl-Proof-of-Concept gegen ChatGPT Atlas. Der wiederkehrende Befund lautet, dass Prompt Injection nicht vollständig patchbar ist, weil die Eigenschaft, die diese Browser nützlich macht, dieselbe ist, die sie ausnutzbar macht.

Das ist dasselbe Versagensmuster, über das ich bei KI-Coding-Assistenten geschrieben habe, die Pakete installieren, die sie nicht prüfen können. Ein System, das Anweisungen aus nicht vertrauenswürdigen Inhalten liest und dann real handelt, kann Eingabe und Befehl nicht zuverlässig unterscheiden. WebMCP behebt das nicht. Es gibt dem Agenten sauberere, mächtigere Verben, sobald ihn etwas gekapert hat.

Braucht die 20-Seiten-Website eines Dienstleisters das?

Nein. Dieses Jahr nicht, und ich würde lügen, wenn ich dir etwas anderes sagte, um dir eine Umsetzung zu verkaufen.

Denk zuerst darüber nach, wer von WebMCP profitiert. Du brauchst echte transaktionale Fläche, genug Traffic, dass ein Bruchteil agentengetriebener Sitzungen etwas bedeutet, und Abläufe, die mühsam genug sind, dass ein Mensch sie gerne delegiert. Warenkataloge mit Tausenden Artikeln. Buchungssysteme mit komplexer Verfügbarkeit. SaaS-Dashboards, bei denen die mühsame mehrstufige Aufgabe das Produkt ist. Deswegen hat Shopify es am ersten Tag über fünf Komma sechs Millionen Storefronts ausgeliefert, und deswegen hat es niemand für einen Klempner in Ohio ausgeliefert.

Eine Zwanzig-Seiten-Dienstleisterseite hat eine bedeutsame Handlung: Kontakt aufnehmen. Ein Agent kann das schon. Er liest die Seite, findet das Formular, füllt es aus. WebMCP würde das etwas zuverlässiger machen und ein paar Token sparen. Das ist ein realer Gewinn von ungefähr nichts, gegen eine Entwurfsspezifikation, die du neu schreiben musst.

Dieses Argument habe ich in anderer Form schon gemacht. Die Websites, die gewinnen, sind nicht die, die alles Neue am schnellsten übernommen haben, sondern die, die konkret genug geblieben sind, um nicht wie alle anderen auszusehen. Einem Community-Group-Entwurf hinterherzujagen ist eine Art, beschäftigt zu sein, keine Art, anders zu sein.

Die kleine Sache, die sich heute lohnt

Hier ist, was tatsächlich übertragbar ist, egal ob WebMCP so kommt wie geschrieben, umbenannt kommt oder still im Gremium stirbt.

Jeder Agent, der je versucht hat, eine Website zu benutzen, vom rohesten DOM-Scraper bis zu dem, was als Nächstes kommt, scheitert an denselben Dingen. Formulare ohne Labels. Buttons, die divs sind. Mehrstufige Abläufe, die von Hover-Zuständen abhängen. Bestätigungsseiten, auf denen "Danke" steht, ohne zu sagen, was passiert ist. Fehlermeldungen als roter Text, der nirgends in der Nähe des Feldes steht. Verfügbarkeit, Preise und Lagerbestand, die nur in einem JavaScript-Rendering existieren, das nie zur Ruhe kommt.

Das zu beheben ist keine Agentenoptimierung. Es ist Barrierefreiheit und klares Formulardesign, das du deinen menschlichen Nutzern ohnehin geschuldet hast, und jede Stunde dort zahlt sich aus, egal welches Protokoll gewinnt. Ein Screenreader und ein KI-Agent scheitern an fast exakt derselben Seite. Diese Überschneidung ist kein Zufall, und sie ist die einzige WebMCP-Vorbereitung, die ich derzeit jemandem in Rechnung stellen würde.

Und dann setz dir eine Erinnerung auf das Frühjahr 2027. Die beobachtenswerten Punkte sind eng: Verlässt die Spezifikation den Community-Group-Status und geht in eine echte Working Group, liefert Chrome sie nach dem Origin Trial ohne Flag aus, konsumiert ein zweiter Agentenanbieter außer OpenAI Tools, und löst irgendwer das Einwilligungsproblem auf eine Art, die nicht "vertrau unserer Anbieterrichtlinie" heißt. Wenn drei von diesen vier eintreten, ist es Zeit zu bauen. Wenn nicht, hast du ein Quartal gespart.

Ich kann mich beim Timing irren. Dass Shopify an einem Nachmittag fünf Komma sechs Millionen Storefronts bewegt, ist nicht nichts, und Defaults haben eine Art, zu Standards zu werden, ganz egal was die Spezifikation sagt. Aber früh bei einem Entwurf zu sein, der vor sechs Monaten seine Kernmethode umbenannt hat, ist keine Strategie, sondern eine Wette. Sei dir sicher, dass du weißt, dass du eine platzierst.

Wenn du dieses Budget lieber in eine Seite steckst, die für Menschen und Maschinen ordentlich funktioniert: das ist die Arbeit, die ich mache.