Letzten Monat hat unser r/mcp Post, der MCP, REST und WebMCP verglichen hat, in 24 Stunden 18.000 Aufrufe bekommen. Hunderte von Devs haben in den Kommentaren die gleiche Frage gestellt: Wann kann mein Agent tatsächlich ein WebMCP-Tool auf einer echten Website aufrufen? Ich habe nachgeschaut. Wir haben außerdem unsere eigenen Implementierungen geprüft, die wir auf Kunden-Hotel-Sites, Immobilien-Pages und im AI-Ready WP Pro Plugin ausliefern. Die Antwort ist interessanter als "bald."
Hier ist, wo WebMCP im Mai 2026 wirklich steht, wer es nutzt, und was die Massenadoption aufhält. Plus eine ehrliche Notiz zu dem, was wir im eigenen Code gefunden haben.
Wo der Spec wirklich steht
WebMCP ist ein W3C Community Group Draft Report, zuletzt veröffentlicht am 23. April 2026. Der Spec wird von der Web Machine Learning Community Group gehostet, mit drei Editoren: Brandon Walderman von Microsoft, sowie Khushal Sagar und Dominic Farolino von Google. Der erste Satz auf der Spec-Page ist es wert, ihn sorgfältig zu lesen:
"It is not a W3C Standard nor is it on the W3C Standards Track."
Community Group bedeutet "interessierte Parteien haben sich getroffen, um etwas aufzuschreiben." Standards Track bedeutet "wir werden das Teil der Web-Plattform machen." Heute ist WebMCP ersteres, nicht letzteres. Es gibt einen Weg vom einen zum anderen, aber er ist nicht automatisch.
Die API-Oberfläche ist navigator.modelContext.registerTool(tool, options) und unregisterTool(). Erwähnenswert, weil das ältere Muster, window.agent, seit August 2025 als veraltet gilt. Wer noch Code mit window.agent hat, liest aus einem abgelösten Spec. Das Discovery-Modell ist außerdem ungewöhnlich: Es gibt keinen .well-known-Endpoint, keine Manifest-Datei. Tools werden zur Laufzeit per JavaScript registriert, wenn die Seite lädt. Der Browser, nicht die Seite oder das Netzwerk, aggregiert sie und stellt sie Agents zur Verfügung.
Ein Detail, das viele übersehen: Anthropic ist kein Editor. Microsoft und Google sind es. Das ist für den nächsten Abschnitt relevant.
Wo die Browser stehen
Chrome 146 wurde am 10. März 2026 auf Stable ausgeliefert. WebMCP ist dabei, aber hinter dem Flag enable-webmcp-testing. Das bedeutet: Wer Chrome 146 heute installiert, hat eine WebMCP-Implementierung im Browser, aber sie ist standardmäßig deaktiviert. Man muss den Schalter in chrome://flags umlegen. Produktionsnutzer haben diesen Schalter nicht umgelegt und werden es nicht tun, bis Chrome es standardmäßig aktiviert ausliefert.
Edge wird Chrome fast sicher folgen. Microsoft ist Co-Editor des Specs, und Edge teilt die Chromium-Engine. Es gibt kein offizielles Lieferdatum. Firefox ist in der Working Group engagiert ohne öffentlichen Zeitplan. Safari/WebKit hat einen WebKit-Bug-Tracker-Eintrag, aber kein Commitment.
Analyst-Blogs projizieren Ende 2026 als Zeitpunkt, an dem Chrome Stable WebMCP standardmäßig aktiviert. Das ist plausibel, aber eine Projektion, keine Roadmap. Das Chrome-Team hat sich nicht öffentlich auf ein Datum festgelegt.
Wo die Agents stehen
Das ist der Abschnitt, der mich überrascht hat, als ich anfing nachzufragen.
Im Mai 2026 ruft keiner der gängigen KI-Agents navigator.modelContext-Tools direkt auf Websites auf. Nicht Claude Desktop, nicht Claude Code, nicht ChatGPT Operator (umgelabelt als ChatGPT Agent), nicht Gemini, nicht Perplexity. Alle nutzen noch einen von zwei Ansätzen: DOM-Scraping (HTML lesen, Buttons finden, anklicken) oder Computer Use (Screenshot machen, Pixel identifizieren, Cursorbewegungen simulieren).
Die Verifikation dazu kommt aus mehreren Quellen. truthifi.com's State of MCP 2026 Piece, discoveredlabs Adoption Timeline und mehrere weitere Mai-2026-Analysen kommen zum gleichen Schluss. Die Anthropic Web Search Synthese, die ich durchgeführt habe, brachte es direkt auf den Punkt: "mainstream AI agents continue to rely primarily on DOM scraping and computer use for web interactions."
Das bedeutet nicht, dass Agents gerade schwach sind. Computer Use ist beeindruckend, und ChatGPT Agent ist gut darin, Formulare per virtuellem Browser auszufüllen. Aber das ursprüngliche WebMCP-Versprechen war, dass Websites typisierte, strukturierte Tools bereitstellen und Agents sie wie API-Endpoints aufrufen. Dieses Versprechen ist bei keinem größeren Client gerade aktiv.
Hier gibt es einen separaten Thread, den man leicht verwechselt. MCP selbst, das serverseitige Protokoll, ist überall. Anthropic, OpenAI, Microsoft, Amazon, Google's Gemini CLI unterstützen alle remote MCP-Server. Das MCP SDK ist von 100.000 monatlichen Downloads Ende 2024 auf 97 Millionen Ende 2025 gestiegen. Aber das sind MCP-Server, die irgendwo auf einem Backend laufen und sich über JSON-RPC mit Agents verbinden. Das ist eine komplett andere Form als WebMCP, das im Browser-Tab lebt und Session-Cookies nutzt.
Die zwei Brücken, die es heute gibt
Wenn WebMCP für Agents ruht, wie ziehen Early Adopters gerade überhaupt Nutzen daraus?
Zwei Wege. Der erste ist die MCP-B Browser-Extension. Ein User installiert sie, öffnet Tabs auf WebMCP-fähigen Sites, und die Extension aggregiert alle registrierten Tools und leitet sie per stdio an Claude Desktop oder einen anderen lokalen MCP-Client weiter. Es funktioniert. Es ist aber auch opt-in, nischig, und erfordert die Installation einer Chrome-Extension. Das ist die Art Setup, die 5.000 Power-User vorgenommen haben, nicht die Art Sache, die der durchschnittliche Lead bei einem B2B-SaaS hat.
Der zweite Weg ist älter und breiter: Computer Use und virtuelle Browser. Anthropics Computer Use lässt Claude den Bildschirm sehen, die Maus bewegen, in Felder tippen und Aktionssequenzen ausführen. ChatGPT Agent nutzt einen ähnlichen virtuellen Browser-Ansatz. Keiner davon braucht WebMCP. Beide funktionieren auf jeder Site, strukturiert oder unstrukturiert. Der Kompromiss ist Zuverlässigkeit: Wenn sich ein Seitenlayout ändert, wenn sich ein Klassenname verschiebt, wenn ein Checkout-Flow auf Mobile anders rendert, verschlechtert sich die Automatisierung. Strukturierte WebMCP-Tools wären, im Prinzip, zuverlässiger. Aber dieses "im Prinzip" macht gerade viel Arbeit.
Einen dritten Punkt lohnt es zu erwähnen: Anthropic hat eine eigene claude-in-chrome Browser-Extension. Die ist getrennt von MCP-B und getrennt vom WebMCP-Spec. Sie ist Anthropics Weg zur Browser-Integration. Die Tatsache, dass sie das parallel bauen statt auf WebMCP zu setzen, ist interessant.
Warum Publisher sich nicht bewegen
Der Adoptionsflaschenhals für WebMCP ist nicht der Browser. Chrome 146 ist ausgeliefert, die API funktioniert hinter einem Flag, der Spec ist stabil genug zum Bauen. Der Flaschenhals ist die Publisher-Seite.
Websites müssen sich opt-in entscheiden. Sie müssen JavaScript hinzufügen, das navigator.modelContext.registerTool() aufruft und ihre Formulare, ihre Suche, ihre Buchungsflows als typisierte Tools bereitstellt. Das ist Arbeit, und es gibt noch keinen Business Case, weil die Agents, die diese Tools konsumieren würden, nicht danach fragen.
Das klarste Signal dafür ist, was gut finanzierte KI-Agent-Unternehmen tun. 11x.ai, Artisan, Monaco sind KI-Agent-Produkte im Bewertungsbereich von 25 bis 350 Millionen Dollar, alle theoretisch natürliche Konsumenten von WebMCP-bereitgestellten Tools. Keiner von ihnen ist heute WebMCP-native. Sie bauen noch auf DOM-Scraping und Computer Use. Öffentliche Analyst-Zeitlinien setzen Mitte 2027 als realistischen Massenadoptions-Zielwert an, wenn sowohl der Browser als auch genug Publisher sich bewegt haben werden.
Das ist eine 12-bis-15-Monatslücke ab jetzt.
Anthropics stille Position zu WebMCP
Wer die Anthropic 2026 MCP Roadmap sorgfältig liest, dem fällt auf, was nicht darin steht. Es gibt viel zu serverseitigen Verbesserungen: OAuth-Flows, SSO-Integration (Cross-App-Auth), referenzbasierte Ergebnisse zur Reduzierung von Context-Bloat, besseres Streaming. Es gibt kein explizites WebMCP-Commitment.
Das macht im Kontext Sinn. Anthropic ist das Unternehmen, das MCP entwickelt hat, und sie konzentrieren sich darauf, MCP dort großartig zu machen, wo die Nachfrage ist, nämlich bei serverseitigen Enterprise-Integrationen. Microsoft und Google sind die, die in den Browser-Pfad investieren. Die Aufteilung spiegelt die breitere Landschaft wider: Anthropic optimiert für den Entwickler, der eine Claude-API mit internen Systemen verbindet. Google optimiert für die Browser-Oberfläche, die sie besitzen. Microsoft optimiert für den Edge- und Copilot-Stack, den sie aufbauen.
Es gab auch den Januar-2026-Vorfall, bei dem Anthropic serverseitige Checks eingeführt hat, um zu blockieren, dass Drittanbieter-Tools sich per OAuth bei Claude Pro- und Max-Abonnements authentifizieren. Das ist nicht direkt über WebMCP, zeigt aber, dass Anthropics Roadmap-Prioritäten unabhängig sind. Sie treffen Entscheidungen, die ihrem eigenen Geschäftsmodell nützen, auch wenn diese Entscheidungen gegen das breitere MCP-Ökosystem laufen.
Für Website-Betreiber bedeutet das: Nicht erwarten, dass Anthropic nächstes Quartal ein WebMCP-aufrufendes Claude-Desktop-Update ausliefert. Microsoft Edge mit Copilot-Integration ist der wahrscheinlichere First-Mover. Google Chrome mit Gemini-Integration ist die andere Option.
Was wir im eigenen Code gefunden haben
Das ist der Teil, in dem ich ehrlich über unsere eigene Implementierung sein werde, weil er für jeden relevant ist, der 2024 und 2025 auf WebMCP aufgesprungen ist.
Wir liefern WebMCP-ähnliche Oberflächen seit über einem Jahr. Auf den Immobilien-Pages, die wir für Immobilienkunden generieren, auf dem AI-Ready WP Pro WordPress-Plugin, auf Kunden-Hotel-Sites, die über unsere Provisioning-Pipeline gebaut wurden. Die Marketing-Geschichte war immer: "Wir stellen Tools bereit, damit Agents sie direkt aufrufen können."
Letzte Woche habe ich einen Code-Audit auf dem SM-Repo durchgeführt. Die Ergebnisse waren unbequem auf eine nützliche Art.
Die gute Nachricht: Es gibt kein window.agent irgendwo. Wir haben nie das veraltete 2025er-Muster übernommen. Die neuere navigator.modelContext-API wird in unseren Blog-Posts und der Dokumentation erwähnt, und die Immobilien-Tests prüfen beide Muster nebeneinander.
Die gemischte Nachricht: Der eigentliche Generator, der Kunden-Hotel-Sites baut, lib/provisioning/hotel/generators/ai-discovery.ts, produziert immer noch ein WebMCP-Registrierungsskript, das unsere ältere eigene Form nutzt, window.mcp.tools.push(...). Das war die Konvention, die wir 2024 gebaut haben, bevor sich der Spec stabilisiert hat. Für uns hat es zu der Zeit funktioniert, weil wir gleichzeitig eine eigene MCP-B-ähnliche Brücke gebaut haben, um diese Tools zu lesen. Es stimmt nicht mit der aktuellen navigator.modelContext.registerTool()-API überein, die Browser tatsächlich suchen werden.
Die Migration steht auf unserer Liste. Sie ist nicht dringend, weil, wie oben etabliert, kein Produktionsbrowser diese Tools heute aufruft. Aber sie muss vor Ende 2026 passieren, wenn Chrome WebMCP plausiblerweise standardmäßig aktiviert ausliefert und Agents anfangen, danach zu suchen. Bis dahin lautet die Marketing-Geschichte "wir haben die Oberflächen, bereit für die Migration zum aktuellen Spec", nicht "wir sind heute 100% Spec-konform."
Jedes Team, das 2024-2025 WebMCP-ähnliche Oberflächen gebaut hat, wird diesen gleichen Moment erleben. Der Spec hat sich bewegt, und die Implementierung muss aufholen. Das ist der Preis dafür, früh dabei gewesen zu sein.
Trotzdem bauen
Nach einer Woche tief in dieser Recherche, ist das mein Fazit.
WebMCP wird wichtig sein. Der Browser-Pfad für KI-Agents ist real, der Spec ist technisch sauber, und die Unternehmen, die ihn brauchen (Microsoft, Google), finanzieren ihn. Die Zeitlücke ist auch real. Wir sind 12 bis 18 Monate zu früh dran bei der Adoption durch Produktions-Agents. Alles was man heute baut, ist eine Forward-Compat-Investition, kein heutiger Umsatz.
Wer ein SaaS oder eine Agentur-Site baut, sollte jetzt WebMCP-Oberflächen hinzufügen, mit der aktuellen navigator.modelContext.registerTool()-API. Kein window.agent. Keine eigenen Ad-hoc-Formen wie unser altes window.mcp. Am Spec bleiben. Wenn Chrome es standardmäßig aktiviert ausliefert und die großen Agents anfangen, es aufzurufen, wird die eigene Site bereits die erste in der Kategorie sein, mit der ein Agent sprechen kann.
Wer ein KI-Agent-Produkt baut, sieht das Bild anders. Nicht auf WebMCP setzen für Mai 2026. Auf Computer Use und virtuelle Browser-Ansätze bauen für jetzt, und die Chrome- und Edge-Release-Notes im Auge behalten auf den Moment, wenn WebMCP standardmäßig aktiviert wird. Das ist der Auslöser für die zweite Phase der Agent-Web-Automatisierung.
Wer Publisher ist (ein Hotel, ein Immobilienbüro, ein B2B-Dienstleister), hat die einfachere Frage. WebMCP-Oberflächen hinzuzufügen ist günstiger, meist mechanischer Aufwand. Das Downside ist null. Das Upside ist, 12 Monate vor den Wettbewerbern bereit zu sein, wenn Agents anfangen, strukturierte Tools aufzurufen statt sich durch den Buchungsflow zu klicken. Wir empfehlen es jedem Kunden bei der Einführung, mit einem klaren Hinweis auf die Zeitlücke.
Jetzt bauen. Den Zeitversatz kennen. Den Spec einhalten.
FAQ
Was ist WebMCP in einem Satz?
WebMCP ist ein W3C Community Group Draft für eine Browser-API (navigator.modelContext.registerTool), die es Websites erlaubt, typisierte, aufrufbare Tools für KI-Agents bereitzustellen, die im Browser laufen.
Kann mein KI-Agent heute die Tools einer WebMCP-fähigen Website aufrufen? Nicht über Claude Desktop, ChatGPT Operator, Gemini oder Perplexity. Keiner von ihnen ruft im Mai 2026 WebMCP-Tools auf Websites auf. Die einzige funktionierende Brücke ist die MCP-B Browser-Extension, die WebMCP-Tools aus offenen Tabs aggregiert und sie an einen lokalen MCP-Client weiterleitet. Das ist ein Opt-in-Setup, kein Standardverhalten eines gängigen Agents.
Funktioniert WebMCP in Produktions-Browsern?
Chrome 146 Stable wurde am 10. März 2026 ausgeliefert und hat eine WebMCP-Implementierung. Sie steckt hinter dem Flag enable-webmcp-testing, ist also standardmäßig deaktiviert. Edge wird folgen. Firefox und Safari sind in der Working Group ohne Zeitplan. Ende 2026 ist der projizierte Zielwert, an dem Chrome es standardmäßig aktiviert ausliefert.
Soll ich WebMCP jetzt auf meiner Site implementieren?
Ja, wenn das Engineering-Budget da ist. Die Kosten sind gering, das Downside ist null, und das Upside ist, 12 Monate vor den Wettbewerbern bereit zu sein, wenn Agents typisierte Tools aufzurufen beginnen. Die aktuelle navigator.modelContext.registerTool()-API nutzen. Das veraltete window.agent-Muster vermeiden.
Wie unterscheidet sich WebMCP von MCP? MCP (Model Context Protocol) ist serverseitig. Ein MCP-Server läuft auf einem Backend, stellt Tools bereit und verbindet sich mit einem KI-Client über JSON-RPC. WebMCP ist browser-nativ. Die Webseite selbst ist die Tool-Quelle. Es nutzt kein JSON-RPC, erfordert keinen separaten OAuth-Flow und erbt die bestehenden Session-Cookies des Nutzers. Gleiches konzeptionelles Modell (typisierte Tools), komplett anderer Transport.
Wann werden gängige Agents WebMCP nutzen? Beste Schätzung ist Mitte 2027 für Massenadoption. Der Flaschenhals ist das Opt-in der Publisher plus die Implementierung des Aufruf-Pfads durch die gängigen Agent-Clients. Chrome, das WebMCP Ende 2026 standardmäßig aktiviert ausliefert, ist wahrscheinlich das Auslöserereignis, aber Agents müssen noch die Aufruflogik ausliefern und Publisher müssen noch Tools registrieren. Mit einer 12-bis-18-Monatsverzögerung vom stabilen Spec zur breiten Praxisadoption rechnen.
Weiterführende Lektüre auf StudioMeyer:
- Was ist WebMCP - die ursprüngliche Erklärung
- MCP vs REST vs WebMCP - der April-Protokollvergleich
- WebMCP W3C Standard - der Spec-fokussierte Beitrag
- Website KI-Agent-ready machen - Service-Page zu Integrations-Arbeit
Wer Hilfe bei der Implementierung von WebMCP-Oberflächen auf der eigenen Site braucht, ist das, was unsere Integrations-Praxis macht. Wir gleichen die aktuelle navigator.modelContext.registerTool()-API ab und dokumentieren den Migrationspfad für den Moment, wenn die Browser-Schicht ausreift.
