WebMCP – Werkzeuge direkt im Browser statt geratenem Klickpfad

Das Problem, das WebMCP löst

Ein Agent, der auf einer Website etwas erledigen soll, hat bisher zwei Wege. Entweder er bedient die Oberfläche wie ein Mensch – er liest das DOM, sucht nach etwas, das aussieht wie ein Suchfeld, klickt und hofft. Oder der Betreiber stellt eine API bereit und gibt einen Schlüssel heraus. Der erste Weg ist unzuverlässig und bricht bei jedem Relaunch. Der zweite verlagert die Frage der Berechtigung aus der Nutzersitzung heraus in ein separates Zugangsgeheimnis.

WebMCP setzt an einer dritten Stelle an: Die Seite meldet ihre eigenen Fähigkeiten an. Der Agent bekommt eine Liste von Werkzeugen mit Namen, Beschreibung und JSON-Schema für die Eingaben – und ruft sie auf, statt eine Oberfläche zu interpretieren. Ausgeführt wird die hinterlegte JavaScript-Funktion, in der Sitzung, in der der Nutzer ohnehin angemeldet ist.

Wie eine Seite ein Werkzeug anmeldet

Der Einstiegspunkt ist document.modelContext. Die Registrierung erwartet dieselben vier Angaben, die auch ein MCP-Tool ausmachen – Name, Beschreibung, Eingabeschema und die auszuführende Funktion:

const controller = new AbortController();

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return {
      content: [{ type: "text", text: `Added todo item: "${text}" successfully.` }]
    };
  }
}, { signal: controller.signal });

Zwei Details lohnen den Blick. Das AbortSignal bindet die Registrierung an einen Lebenszyklus – verlässt der Nutzer die Ansicht, verschwindet das Werkzeug wieder; ein toolchange-Ereignis meldet solche Änderungen an den Agenten. Und die description ist auch hier kein Kommentar, sondern der Text, anhand dessen das Modell entscheidet, ob dieses Werkzeug zur Anfrage passt.

Neben dieser imperativen Form beschreibt die Spezifikation eine deklarative: Ein bestehendes <form> wird annotiert und daraus ein Werkzeug abgeleitet. Das ist der bequemere Weg – und zugleich der am wenigsten gefestigte Teil der Spezifikation. Wer heute anfängt, fährt mit der imperativen API sicherer.

Stand der Dinge: Spezifikation und Browser

WebMCP ist kein verabschiedeter Standard. Der Text ist ein Draft Community Group Report der W3C Web Machine Learning Community Group, zuletzt aktualisiert am 26. August 2026, herausgegeben von Ingenieuren bei Microsoft und Google. Das Explainer-Repository wurde am 13. August 2025 erstmals veröffentlicht. Eine Community Group ist kein Standardisierungsgremium mit Verabschiedungsverfahren; die API kann sich noch ändern.

Quelle: Implementation Status des Spezifikations-Repositorys und die Chrome-Dokumentation. Die Praxisdokumentation auf webmcp-tool.com weist zusätzlich darauf hin, dass die API im Juli 2026 von navigator.modelContext nach document.modelContext verschoben wurde und der Origin Trial die alte Position übergangsweise weiter bedient. Für eigenen Code heißt das: beide Orte prüfen.

WebMCP, MCP, API oder Automation – wer hält das Zugangsgeheimnis?

Die vier Wege, einem Agenten Zugriff zu geben, unterscheiden sich weniger in der Technik als in der Frage, in wessen Namen er handelt. Das ist die Achse, an der man entscheidet:

Für regulierte Umgebungen ist der sitzungsgebundene Zugriff leichter zu verteidigen als ein herausgegebener API-Schlüssel: Es gibt kein Geheimnis, das kopiert werden kann, und die Rechte enden mit der Sitzung. Ein vollständiges Bedrohungsmodell ist das aber nicht – die Spezifikation sagt das selbst.

Was die Spezifikation an Risiken benennt

Der Abschnitt zu Sicherheit und Datenschutz ist ungewöhnlich offen für ein Dokument dieser Art. Vier Punkte sind für Händler unmittelbar relevant:

• Prompt Injection über Beschreibungen. Tool-Namen und -Beschreibungen landen im Kontext des Modells. Werden sie aus Nutzerinhalten gespeist – Bewertungen, Fragen zum Produkt –, ist das ein Einfallstor.
• Prompt Injection über Rückgabewerte. Derselbe Mechanismus, eine Ebene später: Was ein Werkzeug zurückgibt, wird vom Modell gelesen. Die Spezifikation empfiehlt, Antworten als untrusted zu kennzeichnen, damit der Agent sie einordnen kann.
• Abweichung zwischen beschriebenem und tatsächlichem Verhalten. Ein Werkzeug, das „Warenkorb anzeigen“ heißt und bestellt, nutzt die Rechte einer angemeldeten Sitzung. Aus Nutzersicht ist das der teuerste Fehler des Modells.
• Datenabfluss über zu weite Parameter. Ein Eingabeschema, das mehr abfragt als die Operation braucht, wird zum Ausleitungskanal. Die Empfehlung lautet, Eingabelängen zu begrenzen und Parameter eng zu schneiden.

Technisch ist WebMCP auf origin-isolierte Dokumente beschränkt, und beide APIs stehen unter der Permissions Policy tools, die standardmäßig auf self steht. In einem fremden iframe ist WebMCP also nur mit ausdrücklichem allow="tools" erreichbar; sonst antwortet der Aufruf mit NotAllowedError. Werkzeuge lassen sich über exposedTo gezielt für andere Origins freigeben.

Was das für Händler heißt

Der praktisch wichtigste Vorgang ist bereits passiert, ohne dass die meisten Händler etwas getan hätten: Shopify hat am 5. August 2026 WebMCP-Werkzeuge auf jeder Liquid-Storefront und in der Hydrogen-Developer-Preview aktiviert – ohne Installation, ohne Konfiguration. Agenten können dort Katalog durchsuchen (search_catalog, get_product), den Warenkorb ändern (update_cart) und den Checkout anstoßen (proceed_to_checkout). Wer eine Shopify-Storefront betreibt, ist in diesem Kanal bereits sichtbar und sollte wissen, was dort in seinem Namen aufrufbar ist.

Für alle anderen gilt dieselbe Reihenfolge wie beim MCP: Zuerst die Datenbasis und Auffindbarkeit, dann der Kanal. WebMCP wirkt erst, wenn ein Agent die Seite überhaupt geöffnet hat – es ist ein Werkzeug für den Vorgang auf der Seite, kein Auffindbarkeits-Mechanismus. Es ersetzt damit weder strukturierte Produktdaten noch die Zahlungsschicht aus ACP oder AP2.

Grenzen – was WebMCP nicht löst

WebMCP macht eine geöffnete Seite bedienbar, sonst nichts. Es sorgt nicht dafür, dass ein Agent Sie findet; dafür braucht es strukturierte, auffindbare Daten im offenen Web. Es enthält keine Zahlungslogik. Es funktioniert heute nur in Chromium-Browsern und in einer Handvoll Agenten-Anwendungen. Und es hebt keine Datenqualität: Ein Werkzeug über einem lückenhaften Katalog liefert lückenhafte Antworten, nur schneller und in einer Form, der das Modell mehr vertraut.

Diese Seite registriert selbst ein Werkzeug

Was hier beschrieben wird, ist auf dieser Site umgesetzt: Jede Seite meldet über document.modelContext das Werkzeug search_agentic_commerce an, das eine deterministische Auskunft aus den gepflegten Begriffs- und Seitendaten liefert – dieselbe Antwort, die auch der Endpunkt /ask ausgibt. In einem Browser mit aktiviertem Origin Trial kann ein Agent es aufrufen, ohne diese Seite zu lesen. Die deklarative Form ist ebenfalls im Einsatz: Das Formular des Readiness-Checks trägt toolname und tooldescription und ist damit als Werkzeug annotiert, ohne dass dafür Code geschrieben werden musste. Wie die übrigen Artefakte dieser Site aufgebaut sind, steht unter Wie diese Seite gebaut ist.