Agent-Ready Websites: Wer von WebMCP profitiert

Wenn Agents browsen, antwortet Ihre Website

AI Agents schicken bereits zahlende Besucher auf kommerzielle Websites. Im US-Handel wuchs der von AI vermittelte Traffic in Q1 2026 um 393 % gegenüber dem Vorjahr, konvertierte 42 % besser als nicht-AI-Quellen und brachte 37 % mehr Umsatz pro Besuch. WebMCP lässt eine Website diesem Traffic mit strukturierten, benannten Tools begegnen. Ein Agent muss dafür nicht mehr aus rohem HTML raten.

Als W3C Draft Community Group Report veröffentlicht, zuletzt am 17. September 2026, stammt WebMCP von Editoren bei Microsoft und Google. Eine Seite registriert Tools, die ein im Browser laufender Agent finden und aufrufen kann: einen Namen, eine Beschreibung, ein Input Schema und eine Execute Function. Protokoll und Transport übernimmt der Browser. Das ist ein strukturiertes Manifest der Capabilities, die Agents entdecken und aufrufen können, ohne sie aus dem visuellen Layout der Seite ableiten zu müssen. Chrome betreibt einen offenen Origin Trial über die Versionen 149 bis 156; Edge führt seit Version 150 einen eigenen.

Der kommerzielle Zug hinter der Spec ist bereits sichtbar. Shopify und Cloudflare haben ausgeliefert. Expedia, Booking.com, Etsy, Instacart und Target sind im Origin Trial eingeschrieben, und das ist etwas anderes und Früheres. Search Engine Land benennt die Richtung klar: Tool Descriptions sind die neuen Meta Descriptions. Gartner sagt voraus, dass bis 2028 90 % der B2B-Einkäufe über Agents vermittelt werden.

Die Lücke, die WebMCP schließt, ist konkret: Die meisten Websites sind für menschliche Augen und Mausklicks gebaut. Ein Agent, der auf einer solchen Website landet, rät sich durch das Interface oder gibt auf. Vier Gruppen profitieren, wenn die Website anders gebaut ist.

Website Owner und Product Owner

Der unmittelbarste Nutzen ist transaktional. Ein Agent, der proceed_to_checkout aufrufen kann, muss keinen Button suchen und anklicken, dessen Position je nach Seite oder Viewport wandert. Die Aktion ist deterministisch und bricht nicht, wenn sich das Layout ändert.

Shopify hat das am 5. August 2026 konkret gemacht. WebMCP Tools laufen auf Liquid Storefronts und in der Hydrogen Developer Preview, standardmäßig aktiv, mit zehn benannten Tools für Katalogsuche, Cart Management, Order Tracking und Policy Lookup. Shopify formuliert es so: “Everything an agent does happens on the shopper’s live session. Cart tools call the same standard storefront actions that apps use.” Händler konfigurieren nichts und installieren nichts.

Cloudflare zog am 6. August 2026 nach, mit einem Schalter im Dashboard, der jeder Website ein WebMCP Interface ohne Code-Änderung gibt. Cloudflare injiziert ein Bridge Script am Edge, stellt Tool Packs aus vorhandenen Capabilities zusammen und registriert sie über die WebMCP API des Browsers. Die eigene Zusammenfassung: “the human stays in control and creators keep their traffic.”

Hinter beiden Schritten steht dieselbe kommerzielle Logik. Shopifys eigene Zahlen für Q1 2026 zeigen Sessions aus AI-Suche auf dem Achtfachen des Vorjahreswerts, Bestellungen aus diesen Sessions fast 13-mal so hoch und Conversion Rates knapp 50 % über der organischen Suche. Adobe hat über eine Billion Besuche auf US-Handelsseiten ausgewertet: Besucher, die von AI Assistants kommen, verbringen 48 % mehr Zeit auf der Seite und sehen sich 13 % mehr Seiten an. Dieser Traffic ist bereits da. Eine Website mit strukturierten Tools holt sich die Transaktion; eine Website ohne sie überlässt sie dem, was der Agent erraten kann.

Endnutzer

Die Person vor dem Browser gewinnt auf eine weniger offensichtliche Weise. Ein Agent, der über deklarierte Tools handelt, erledigt Aufgaben schneller und mit weniger Fehlern als einer, der die Absicht aus visuellem Markup rekonstruiert. Ein manage_orders Tool liefert strukturierte Daten zurück, mit denen der Agent arbeiten kann; dasselbe Verhalten aus dem Parsen einer Seite hängt an Markup, das sich zwischen zwei Seitenaufrufen oder zwischen Bildschirmgrößen unterscheiden kann.

Zuverlässigkeit zählt so viel wie Geschwindigkeit. Ein Agent, der ein Formular durch simulierte Klicks ausfüllt, hängt davon ab, dass die Struktur dieses Formulars stabil bleibt. Ein Tool Call ist ein expliziter Vertrag: Der Agent weiß, wonach er gefragt hat, und die Website weiß, was aufgerufen wurde.

Die Logik dahinter reicht weiter. Grigsby bringt es bei Cloud Four genau auf den Punkt: Verbesserungen für AI gehören “in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit.” Die semantische Lücke, die eine Website für einen Agent schwer navigierbar macht, macht sie aus demselben Grund schwer für einen Screen Reader. Deklariert eine Website, was jedes Bedienelement tut, dient das jeder Maschine, die die Seite liest, ohne dass diese es aus Position oder Farbe ableiten muss.

Die WebMCP Spezifikation führt Accessibility-Technologie inzwischen selbst als eine der Zielgruppen ihrer Tools an, und keine Website hat bisher eine gemessene Accessibility-Verbesserung durch WebMCP veröffentlicht. Der Punkt ist enger: Was Agents dient, dient meist auch der Accessibility, und umgekehrt. Beides zahlt sich aus derselben Investition aus.

Entwickler und Engineering Teams

Wo die darunterliegende API bereits sauber ist, besteht die Arbeit darin, zu benennen, was sie tut, ohne ein zweites System daneben zu bauen.

Eine auf arXiv veröffentlichte Arbeit (2508.09171) hat den Ansatz mit strukturierten Tools über 1.890 echte API Calls aus Shopping-, Authentifizierungs- und Content-Management-Workflows gemessen. Das Ergebnis: 67,6 % weniger Verarbeitungsaufwand gegenüber der Übergabe des vollständigen HTML an ein Modell, Task Success Rates von 97,9 % gegenüber 98,8 % in der Baseline und Kostensenkungen im Bereich von 34 bis 63 %. Diese Zahlen gelten für das Muster der strukturierten Tools; das Paper beschreibt den eigenen Vorschlag des Autors, der dasselbe Modell teilt, aber nicht die W3C API ist.

Der praktische Punkt ist das, was die Zahlen zeigen: Benannte Tools für einen Agent zu deklarieren ist effizienter, als ihn die Seite parsen zu lassen. Alex Nahas, der bei Amazon das Protokoll gebaut hat, aus dem WebMCP wurde, sagt es direkt: Eine Website wird zum Tool Server. Ein Agent ruft sie auf und muss sie nicht mehr als Dokument entschlüsseln.

Websites ohne eigenes Entwicklerteam bekommen über Cloudflares Injection am Edge und Shopifys eingebautes Tooling einen Weg, der gar keinen Code verlangt. Wo es ein Team gibt, besteht die Arbeit darin, zu deklarieren, was die API ohnehin schon tut, ohne ein separates System für Agents von Grund auf zu bauen.

Unternehmen mit internen Tools

Hinter einem Login verhält sich WebMCP anders als in seiner öffentlichen Form. Eine öffentliche Seite ist anonym, weil die Seite anonym ist. Ein Firmen-Intranet, ein Reporting Dashboard oder eine Auftragsverwaltung hinter dem Firmen-Login ist es nicht.

Ist ein Nutzer an einer Seite authentifiziert, erbt ein WebMCP Tool in dieser Seite die Session automatisch. Kein Token Exchange, kein separater OAuth Flow, kein zusätzliches Credential Management. Die interne Anwendung, die das Team ohnehin betreibt, wird über dieselben Berechtigungen, die sie bereits durchsetzt, für Agents aufrufbar.

Genau diese Einsicht steht am Ursprung der Spezifikation. Alex Nahas hat MCP bei Amazon im Browser gebaut, um genau das Authentifizierungsproblem zu lösen: Tools im Browser erben die bestehende Session des Nutzers ohne zusätzliche Integration. Dieselbe Logik gilt für jedes Unternehmen, das interne Tools im Web betreibt.

Procurement Tools, Projektmanagement-Dashboards, HR-Self-Service-Portale: Jedes davon ist eine Web-Oberfläche, durch die heute ein Mensch Schritt für Schritt navigieren muss, und jedes weiß bereits, wer dieser Mensch ist. Der Tool Call kommt innerhalb dieser Session an und unter den Berechtigungen, die sie ohnehin trägt. Es gibt also nichts Neues auszustellen, zu rotieren oder zu widerrufen.

Was Sie zuerst bauen

integrations.at liefert beides aus: einen Remote MCP Server und einen WebMCP Layer in der Seite, beide aus einem Browser Agent aufrufbar.

Die vier Gruppen hier sind keine Auswahlliste. Ein Shopify-Händler hat die Tools bereits laufen. Ein Unternehmen mit einer internen Anwendung hinter dem Login hat den direktesten Weg zu einer funktionierenden, authentifizierten Agent-Oberfläche. Ein Entwicklerteam mit einer sauberen API hat die kleinste Lücke bis zur Implementierung. Die einzige Entscheidung ist, welche Oberfläche Sie zuerst aufrufbar machen.

So bringen Sie es zum Laufen

Wir betreiben diesen Layer auf integrations.at, also hier das Ganze: eine JSON-Datei, die zur Build-Zeit aus den eigenen Inhalten der Website entsteht, die REST API, die ohnehin schon da war, und zwanzig Tools, die ein einziges Script registriert. list_offerings liefert die vier Bereiche mit ihren Seiten und den Flyern; get_offering liefert einen Eintrag über den Slug; search_offerings durchsucht alle zusammen. list_downloads liefert die Flyer-PDFs. list_services liefert die vier Servicebereiche zurück, jeweils mit Hub-URL und jeder Card darauf. list_articles liefert die Beiträge unter /ai-trends/, die neuesten zuerst. list_classes liefert die Trainings. search_knowledge_catalogue durchsucht den Knowledge Catalogue, und get_knowledge_catalogue_entry liefert den vollständigen Datensatz eines Eintrags über den Slug. apply_knowledge_catalogue_filter ist das einzige, das schreibt: Es steuert den Filter auf dem Knowledge Catalogue, den der Leser gerade vor sich hat, setzt das Suchfeld, aktiviert einen Group Chip und liefert zurück, was gepasst hat. Dazu kommen die Tools über das Haus selbst. get_about_profile liefert das Profil des Gründers, list_certifications jede einzelne Microsoft-Zertifizierung aus dem Learn Transcript, list_talks die Vorträge. get_pricing_and_terms nennt für beide Angebote den Satz, die Einheit und die Zahlungsbedingungen. list_faqs gibt die Fragen und Antworten von den Leistungsseiten zurück, get_contact sagt, wie man uns erreicht. Vier weitere liefern die Rechtstexte: get_impressum, get_privacy_policy, get_terms und get_meeting_privacy.

Neunzehn Tools beantworten Fragen, eines bedient die Seite. Genau diese Trennung ist der Punkt, und deshalb registriert sich das letzte nur auf Seiten, die den Filter tragen.

document.modelContext existiert standardmäßig nicht, also registriert eine korrekt verdrahtete Website nichts und sagt auch nichts dazu. Unser Script fragt zuerst document.modelContext ab und fällt auf navigator.modelContext zurück, weil Chrome den Einstieg während des Origin Trial verschoben hat: Chrome 149 kannte nur navigator, 150 und 151 beide, ab 152 nur noch document. Ein Script ohne diesen Fallback registriert in den älteren Versionen gar nichts. Zwei Schalter aktivieren die Schnittstelle.

Für die Entwicklung aktivieren Sie chrome://flags/#enable-webmcp-testing, in Edge edge://flags/#enable-webmcp-testing, und starten den Browser neu. Das Flag gilt für jede Origin in diesem Browser-Profil, localhost eingeschlossen. Wir haben das auf Chrome 151 geprüft; die Oberfläche ist seither auf document.modelContext gewandert, der Weg über das Flag ist derselbe geblieben. Microsoft führt für WebMCP einen eigenen Origin Trial, gelistet in den Edge Release Notes ab Version 150 und registrierbar auf developer.microsoft.com. Auf localhost bleibt es auch in Edge beim Flag, weil Edge Origin Trial Tokens nur auf SSL-Domains auswertet.

Für die Production registrieren Sie ein Origin Trial Token auf developer.chrome.com/origintrials . Der WebMCP Trial läuft von Chrome 149 bis 156 und endet am 17. November 2026, und für die Registrierung brauchen Sie ein Google-Konto. Eine Origin besteht aus Scheme, Host und Port, example.com und www.example.com sind also getrennte Registrierungen; “match all subdomains” deckt Staging mit einem einzigen Token ab.

Eine Falle sollten Sie kennen, bevor Sie hineinlaufen. Wenn Sie “third-party matching” ankreuzen, liefert nur eine externe JavaScript-Datei, die den Meta Tag injiziert, das Token aus; in einem statischen Meta Tag oder in einem HTTP Header scheitert es still, ohne Fehler in der Console. Dekodieren Sie den base64 Payload des Tokens und lesen Sie isThirdParty, bevor Sie den eigenen Code verdächtigen.

Zum Testen brauchen Sie gar keinen AI Agent. Öffnen Sie die DevTools, gehen Sie auf den Application Tab und wählen Sie links WebMCP. Available Tools in der unteren Hälfte listet alles auf, was die Seite registriert hat, samt Beschreibung je Tool, und ist damit auch die schnellste Prüfung, ob ein Tool überhaupt registriert wurde. Wählen Sie eines aus, öffnet rechts Details: Name, Beschreibung, das Frame, zu dem es gehört, und ein Origin-Link direkt auf die Zeile Quellcode, die es registriert hat. Der Button Run tool sitzt rechts unten in diesem Bereich. Der Tab Input nimmt die Argumente des Tools als JSON entgegen ({} für ein Tool ohne Argumente), und Output zeigt das Ergebnis als aufklappbaren Baum, genau das, was auch ein Agent bekommt. Jeder Lauf landet oben in Tool Activity, mit seinem Status und einem laufenden Zähler über Gesamt-, Fehl- und Abbruchaufrufe. Wer lieber die Console nimmt, kommt dort genauso weit: await document.modelContext.getTools() listet die Tools, document.modelContext.executeTool(tool, '{}') führt eines aus, wobei Chrome diesen Input als JSON String nimmt, obwohl das Draft IDL Object sagt.

Chrome nennt in der eigenen Dokumentation einen zweiten Weg. Die Extension „Model Context Tool Inspector“ listet die Tools der geöffneten Seite, zeigt ihr Input Schema und führt sie mit einem JSON-Input aus, ohne dass Sie die DevTools öffnen.

Mit gesetztem Flag können Sie das hier direkt testen. Öffnen Sie eine Seite auf integrations.at, öffnen Sie das WebMCP Panel und führen Sie list_services mit {} aus: Die vier Bereiche und ihre Cards kommen als Daten zurück. Öffnen Sie dann eine Seite mit dem Knowledge Catalogue und führen Sie apply_knowledge_catalogue_filter mit einer Suchanfrage aus. Die Liste am Bildschirm engt sich ein, während dasselbe Ergebnis an den Aufrufer zurückgeht: lesen und handeln, auf der Website, die Sie ohnehin gerade lesen.