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, aus einer Basis, die weiterhin unter 0,2 % des E-Commerce-Traffic liegt. WebMCP lässt eine Website diesem Traffic mit strukturierten, benannten Tools begegnen, statt einen Agent aus rohem HTML raten zu lassen.

Am 19. August 2026 als W3C Draft Community Group Report veröffentlicht, 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. Google nennt das einen “tool contract”, ein strukturiertes Manifest der Capabilities, die Agents entdecken und aufrufen können, statt sie aus dem visuellen Layout der Seite abzuleiten. Chrome betreibt einen offenen Origin Trial über die Versionen 149 bis 156; Edge liefert experimentelle Unterstützung hinter einem Flag.

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 jetzt auf jedem Liquid Storefront 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. Wenn eine Website deklariert, was jedes Bedienelement tut, statt es aus Position oder Farbe ableiten zu lassen, dient diese Deklaration jeder Maschine, die die Seite liest.

Die WebMCP Spezifikation stellt selbst fest, dass sie nicht für die Verarbeitung durch Accessibility-Technologie ausgelegt ist, 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, statt 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 statt zu einem Dokument, das ein Agent entschlüsseln muss.

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, statt 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 Entscheidung lautet nicht, ob WebMCP zu Ihrem Stack passt, sondern 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 sechs Tools, die ein einziges Script registriert. 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. find_capabilities durchsucht den Capability-Katalog, und get_capability liefert den vollständigen Datensatz einer Capability über den Slug. apply_capability_filter ist das einzige, das schreibt: Es steuert den Filter auf der Capabilities-Liste, die der Leser gerade vor sich hat, setzt das Suchfeld, aktiviert einen Group Chip und liefert zurück, was gepasst hat.

Fünf 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. Zwei Schalter aktivieren es.

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, und verlangt Chromium 146.0.7672.0 oder neuer; wir haben das auf Chrome 151 geprüft. Sekundäre Berichte, nach denen Edge 147 WebMCP nativ mitbringt, bestätigen Microsofts eigene Edge Release Notes nicht. Nehmen Sie dort also das Flag als den verlässlichen Weg.

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.

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 der Capability-Liste und führen Sie apply_capability_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.