Erklärung zu WebMCP: Bereitstellung von Tools für KI-Agenten in Browsern anstelle von Vermutungen.

Bitten Sie einen KI-Agenten, auf einer Website einen Flug zu buchen, und beobachten Sie, was passiert. Er öffnet die Seite und beginnt, sie zu durchsuchen. Welches Element ist das Datumseingabefeld? In welchem Dropdown-Menu befindet sich das Reiseziel? Welcher Button erfordert zwei Klicks, weil ein Modal-Fenster ihn bedeckt? Manchmal schafft es der Agent, seine Aufgabe zu erledigen. Manchmal klickt er versehentlich auf das Falsche, füllt ein Feld mit Unsinn oder steckt beim Bezahlen fest, weil sich die Layouts nach dem Training des Modells geändert haben.

So arbeiten die meisten heutigen browserbasierten Agenten. Sie scannen den DOM, ermitteln aus dem Beschriftungstext und der Position jedes Elements dessen Funktion und simulieren anschließend die Klicks und Tasteneingaben, die ein Mensch ausführen würde. Diese Technik wird Actuation genannt – sie sieht in einer Demo großartig aus, bricht aber in der Praxis zusammen. Ändern Sie eine CSS-Klasse oder verschieben Sie einen Button, und ein Agent, der gestern noch funktioniert hat, gerät aus dem Takt.

WebMCP ist eine Reaktion darauf. Wenn man das Model Context Protocol (MCP) im Backend kennt, ist die Idee leicht zu verstehen: Man überträgt das Konzept von Tools in den Browser, sodass sie auf den von einem erstellten Seiten vorhanden sind.

Warum das Betrachten des DOMs nicht ausreicht

Agenten erreichen derzeit einen Dienst auf einer von zwei Wegen:

• Integration im Backend. Der Dienst registriert Tools bei einer KI-Plattform über einen MCP-Server, OpenAPI oder eine proprietäre API, wodurch die KI direkt mit dem Server kommuniziert, ohne den Browser zu berühren.
• Aktivierung im Browser. Der Agent öffnet die Seite wie ein Mensch und versucht herauszufinden, auf welche Elemente geklickt oder welche ausgefüllt werden müssen.

Die Aktivierung ist aufwendig und leicht fehleranfällig. Jeder Schritt kann falsch interpretiert werden, insbesondere in komplexen, mehrschichtigen Benutzeroberflächen wie modernen Single-Page-Apps.

WebMCP fügt einen dritten Ansatz hinzu, der weder eine Integration mit einem Backend noch blindes Klicken ist. Die Seite selbst gibt an, was sie kann. Anstatt dass ein Agent raten muss, was die Bezahlfunktion bewirkt, beschreibt der Entwickler, was die Bezahlfunktion leistet, welche Eingaben sie benötigt und was sie zurückgibt.

Was WebMCP ist

WebMCP ist ein vorgeschlagener Web-Standard der Web Machine Learning Community Group beim W3C. Die Spezifikation definiert eine JavaScript-API sowie Anmerkungen zu HTML-Formelementen, damit ein Agent ohne Raten die Funktionen der Seite nutzen kann.

Vergleichen Sie es mit dem Backend-MCP. Eine Seite, die WebMCP implementiert, verhält sich wie ein MCP-Server, dessen Tools als Client-Seiten-Skripte ausgeführt werden. Wo man normalerweise einen separaten Server einrichten müsste, um eine Funktion bereitzustellen, kann man diese Funktion direkt aus dem bereits auf der Seite laufenden JavaScript registrieren.

Das Design setzt sich aus drei Komponenten zusammen:

• Entdeckung: eine Standardmethode, mit der Seiten Tools wie checkout oder search_products bei einem Agenten registrieren können.
• JSON Schema: explizite Definitionen der erwarteten Eingaben und Ausgaben, die Halluzinationen und Missverständnisse verringern.
• Zustand: ein gemeinsames Bild des aktuellen Kontexts der Seite, damit der Agent weiß, worauf er sich gerade einstellen kann.

Noch ein Detail: Die Tools laufen weiterhin sichtbar auf der Seite. Wenn ein Agent ein add_to_cart-Tool aufruft, erscheint das Ergebnis in der Benutzeroberfläche, anstatt stillschweigend abzulaufen. Das ist wichtig für das Vertrauen, denn die Nutzer können sehen, was für sie getan wird, und die von Ihnen entworfene Erfahrung wird nicht umgangen.

WebMCP auf einer Website registrieren

Die Einbindung in eine bereits vorhandene Website bedeutet keine Neuerrichtung. Es handelt sich dabei um eine zusätzliche Kommunikationsschicht, die auf einem bereits funktionierenden Backend aufsetzt. Die Schritte:

1. Die Umgebung aktivieren. Da der Standard noch nur vorgeschlagen ist, schalten Sie ihn für Experimente manuell ein. Öffnen Sie in Chrome chrome://flags/#enable-webmcp-testing, stellen Sie es auf „Enabled“ ein und starten Sie den Browser neu. Für eine Nutzung, die der Produktivumgebung näher kommt, melden Sie sich für den WebMCP Origin-Test an, der ab Chrome 149 verfügbar ist, damit echte Besucher die Funktion nutzen können, ohne auf Flags zurückgreifen zu müssen.

2. Wählen Sie nur die nützlichen Tools aus, die präsentiert werden sollen. Dieser Schritt wird oft unterschätzt. Präsentieren Sie nicht jede Funktion, nur weil es möglich ist. Überlegen Sie, bei welchen Aufgaben die Nutzer tatsächlich die Hilfe eines Agents benötigen – in der Regel bei Aufgaben mit einem klaren Zweck wie Suchen, Filtern, Formularausfüllen oder Bezahlen. Vermeiden Sie Dutzende von Tools auf einer Seite, da jedes registrierte Tool Platz im Kontextfenster verbraucht und ein langes Menü die Auswahl des Agents erschwert.

3. Wählen Sie die imperative oder deklarative API. Die imperative API registriert Tools mit reinem JavaScript über registerTool und eignet sich für komplexere Logiken wie Zustandsverwaltung, Navigation oder Kettung von Aktionen. Die deklarative API platziert Anmerkungen direkt in einem standardmäßigen HTML-<form>, wodurch das Tool automatisch für Sie erstellt wird – dies ist geeignet für einfache, formbasierte Fälle. React- und Angular-Projekte bieten framework-eigene Optionen. React stellt das usewebmcp-Paket bereit, dessen useWebMCP-Hook den Lebenszyklus eines Tools mit dem Einbinden und Entbinden eines Komponenten verknüpft. Angular bietet experimentelle Unterstützung, mit der Signal Forms in Tools umgewandelt werden können.

4. Machen Sie das inputSchema detailliert. Dies bestimmt, inwieweit ein Agent das Tool versteht. Schreiben Sie die description in einfachem, natürlichen Sprachstil und nicht in internen Abkürzungen, und definieren Sie jede Eigenschaft zusammen mit ihrem Typ. Für eine geschlossene Wertemenge verwenden Sie enum, damit der Agent seltener etwas Ungültiges sendet.

5. Stellen Sie sicher, dass die annotations dem tatsächlichen Risiko entsprechen. Jedes Tool benötigt eine ehrliche Kennzeichnung:

• readOnlyHint: true für ein Tool, das nur liest und alles unverändert lässt.
• consequentialHint: true für eine Aktion mit tatsächlichen Auswirkungen, bei der der Benutzer zuerst um Bestätigung gebeten werden sollte.
• untrustedContentHint: true, wenn die Ausgabe Inhalte von anderen Benutzern enthält, wie z. B. Bewertungen oder Kommentare, die eine Anweisung verbergen könnten.

6. Verbinden Sie execute mit einem bestehenden Endpunkt. Die execute-Funktion kann einfach die bereits vorhandene API-Route mithilfe von fetch() aufrufen. Eine Laravel-Route funktioniert hier gut. Es gibt keinen separaten WebMCP-Backend. Sie bauen eine Frontend-Brücke zu einer in der Produktion bereits erprobten Geschäftslogik.

7. Testen Sie es. Fügen Sie die Chrome-Erweiterung „Model Context Tool Inspector“ (Chrome Web Store) hinzu, laden Sie Ihre Seite und schauen Sie sich an, welche Tools registriert werden. Von dort aus können Sie auch mit einem Agenten sprechen, um zu bestätigen, dass Ihr Tool aufgerufen wird und sein Schema klar lesbar ist.

8. Behandeln Sie es als progressive Enhancement. Die Browserunterstützung ist begrenzt, daher müssen normale Buttonklicks weiterhin funktionieren, auch für Besucher, deren Browser WebMCP nicht unterstützen. Es wird ein neuer Pfad hinzugefügt, der den alten nicht ersetzt.

Beispiel: Ein Tool zum Anzeigen des Bestellstatus

Nehmen wir einen auf Laravel basierenden Online-Shop mit einer Bestellstatusseite. Der normale Ablauf sieht so aus, dass ein Benutzer sich einloggt, auf „Meine Bestellungen“ klickt, einen Zeitraum auswählt und eine Liste der Bestellungen mit deren Versandstatus einsehen kann. Ein Mitarbeiter, der Aktualisierungen vornehmen muss, würde erst den richtigen Dropdown-Menüpunkt und die Schaltfläche zum Senden finden müssen, um anschließend eine Ergebnistabelle aus dem rohen HTML zu extrahieren – wobei diese Struktur bereits bei geringfügigen Änderungen im Markup zusammenbricht.

Mit WebMCP umhüllt ein einziges Tool den bereits vorhandenen Endpunkt:

await document.modelContext.registerTool({
  name: 'get_order_status',
  description: 'Look up orders within a given timeframe. Returns order number, shipping status, and current location.',
  inputSchema: {
    type: 'object',
    properties: {
      timeframe: {
        type: 'string',
        enum: ['today', 'yesterday', 'last_7_days', 'last_30_days', 'last_6_months'],
        description: 'Timeframe for the order lookup.'
      }
    },
    required: ['timeframe']
  },
  annotations: {
    readOnlyHint: true,
    consequentialHint: false,
    untrustedContentHint: false
  },
  execute: async ({ timeframe }) => {
    const response = await fetch(`/api/orders/status?range=${timeframe}`, {
      headers: { 'Accept': 'application/json' }
    });
    const data = await response.json();
    return JSON.stringify(data);
  }
});

Drei Aspekte sind besonders hervorzuheben. inputSchema erspart dem Agenten das Raten des Formats, da es kennt, welche Werte timeframe akzeptiert. Die Anmerkung readOnlyHint: true kennzeichnet das Tool als frei von Nebeneffekten, weshalb keine Bestätigung erforderlich ist. Zudem ruft execute einfach einen vorhandenen Laravel-Route auf, sodass nichts neu erstellt werden muss.

Der Zahlungsvorgang ist sensibler, da dabei Geld überwiesen und eine Bestellung aufgegeben wird. Dafür ist ein anderes Signal notwendig:

await document.modelContext.registerTool({
  name: 'checkout_cart',
  description: 'Completes checkout for the currently logged-in user\'s cart.',
  inputSchema: {
    type: 'object',
    properties: {
      paymentMethod: { type: 'string', description: 'Payment method selected by the user' }
    },
    required: ['paymentMethod']
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: true,
    untrustedContentHint: false
  },
  execute: async ({ paymentMethod }) => {
    const response = await fetch('/api/checkout', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ payment_method: paymentMethod })
    });
    return await response.text();
  }
});

Mit consequentialHint: true weiß der Browser oder Agent, dass ein Bestätigungsdialog angezeigt werden muss, bevor die Aktion ausgeführt wird. Selbst wenn der Agent auf die Schaltfläche klickt, bleibt die endgültige Entscheidung beim Benutzer.

Um die auf einer Seite registrierten Tools aufzulisten:

const tools = await document.modelContext.getTools();
console.log(tools);

Und um einen manuell zum Testen auszulösen:

const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(tool, '{"timeframe": "last_7_days"}');

Eine vollständige Hin- und Rückreise

Hier ist die Abfolge, wenn Sie mit einem Agenten chatten, der das get_order_status-Tool verwendet.

1. Sie tippen in einfachen Worten etwas wie „Zeigen Sie mir meine Bestellungen von letzter Woche“ an einen Agenten, bei dem die Seite des Shops geöffnet ist.
2. Der Agent führt eine Suche durch, indem er auf der Seite getTools() aufruft.
3. Die Seite gibt ihre Tool-Liste mit den Schemata zurück, einschließlich get_order_status mit seiner Beschreibung und Eingabeformat.
4. Der Agent vergleicht Ihre Anfrage mit den Beschreibungen. Eine klare Beschreibung hilft ihm, sofort das richtige Tool auszuwählen.
5. Der Agent ruft executeTool() mit aus dem Gespräch abgeleiteten Argumenten auf, wie zum Beispiel {timeframe: 'last_7_days'}.
6. Die execute-Funktion der Seite ruft denselben Laravel-Endpunkt über fetch() auf, genauso wie bei einem Klick auf einen Button.
7. Die Backend-Plattform antwortet mit JSON, und das Tool gibt diese Antwort an den Agenten weiter.
8. Der Agent formuliert das Ergebnis in natürlicher Sprache und zeigt es an, wobei alles weiterhin in der Benutzeroberfläche der Seite sichtbar bleibt.

Warum ist das besser als herkömmliche Ausführungsmethoden?

• Es benötigt weniger Kontext. Der Agent liest ein kompaktes Schema, nicht tausende von Zeilen an Markup, wodurch die Antworten schneller und günstiger sind.
• Die Ergebnisse bleiben konsistent. Das Tool ruft Ihre eigentliche Funktion auf, sodass das Umfärben eines Buttons oder das Verschieben eines Elements nichts durcheinanderbringt.
• Die Nutzer behalten die Kontrolle. Hochriskante Aktionen, die mit consequentialHint: true markiert sind, erfordern weiterhin eine Bestätigung, sodass ein Agent nicht ungefragt vorgehen kann.

Es ist einfacher zu auditen. Jede Interaktion erfolgt über ein explizites Tool, sodass Sie genau protokollieren können, was ein Agent für einen Benutzer getan hat – was bei einfachem Klicken weitaus schwieriger ist.

Sicherheit

Da die Tools auf Ihren Seiten liegen, befindet sich die Sicherheit näher an der Oberfläche als bei MCP im Backend, das in der Regel isoliert auf seinem eigenen Server läuft. Die Spezifikation bietet mehrere Schutzmaßnahmen:

• Ursprungsisolation. WebMCP läuft nur in dokumenten mit Ursprungsisolation. Wenn eine Seite beispielsweise document.domain über den Header Origin-Agent-Cluster: ?0 aktiviert, wird WebMCP deaktiviert.
• Permissions Policy. Die Registrierung von Tools wird durch die tools-Richtlinie gesteuert, die standardmäßig auf self eingestellt ist. Daher können Cross-Origin-Iframes keine Tools registrieren, es sei denn, Sie erlauben dies mit allow="tools".

Exposition gegenüber einer anderen Quelle. Um ein Tool von einer anderen Quelle aus zugänglich zu machen, geben Sie diese Quelle in der Option exposedTo an. Nichts wird automatisch exponiert.

Drei Hinweise für Anmerkungen. readOnlyHint, consequentialHint und untrustedContentHint sind mehr als nur Beschriftungen. Sie geben an, ob ein Agent ein Tool ohne Bestätigung ausführen darf oder dessen Ausgabe vorsichtig behandeln sollte, da sie unzuverlässigen Inhalt wie Benutzerbewertungen enthält, der eine Prompt-Injection ermöglichen könnte.

Eine ehrliche Einschränkung: Die Isolierung zwischen Tabs ist noch in der Entwicklung. Wenn ein Agent in zwei Tabs arbeitet, gibt es keine Regelung, die verhindert, dass sensibler Kontext von einem Tab in den anderen gelangt. Bei hochvertrauenswürdigen Anwendungen wie dem Bankwesen sollten Sie diese Funktion vor dem Einsatz genau prüfen.

Stand der Browserunterstützung

Stand Mitte 2026 ist es noch früh:

• Die W3C Web Machine Learning Community Group hat die Spezifikation im September 2025 offiziell angenommen.
• Chrome verfügt ab Version 149 über einen Testmodus, wobei eine native Unterstützung in Chrome und Edge für die zweite Hälfte des Jahres 2026 vorgesehen ist.
• Für lokale Experimente funktioniert die Einstellung chrome://flags/#enable-webmcp-testing ohne Teilnahme am Testmodus.
• Die Erweiterung Model Context Tool Inspector zeigt an, welche Tools eine Seite registriert hat, und kann eine Agentenkonversation simulieren.

Der Vorschlag kann sich noch ändern, daher sollte man keine Produktfunktionen darauf verlassen. Verwenden Sie progressive Enhancement. Wo der Browser WebMCP unterstützt, erhalten die Agenten eine präzisere Erfahrung, und wo nicht, funktioniert der manuelle Ablauf wie bisher.

Derzeitige Einschränkungen

• Kein headless-Browsing. Die API richtet sich an lokale Browser-Arbeitsabläufe mit menschlicher Beteiligung, nicht an unüberwachte Automatisierung.
• Hoher Aufwand bei komplexen Schnittstellen. Eine Anwendung mit komplexer Zustandsverwaltung benötigt vermutlich eine Refaktorierung, damit die Tools den tatsächlichen Zustand der Anwendung widerspiegeln.
• Entdeckung erfordert einen Besuch. Kunden erfahren nur durch einen Besuch der Seite, dass eine Seite Tools bietet. Es gibt bisher keinen globalen Index wie eine Sitemap für Tools.
• Noch keine Ressourcen oder Anweisungen. Zwei weitere Grundfunktionen aus dem vollständigen MCP sind noch nicht in WebMCP enthalten. Wenn ein Agent Dokumente lesen oder strukturierte Daten von einem anderen Ort abrufen muss, benötigt man weiterhin einen separaten MCP-Server.

Wo man anfangen sollte

WebMCP ergänzt das Backend-MCP, ersetzt es aber nicht. Das Backend-MCP bleibt geeignet für Daten und Logik, die auf einem Server gespeichert werden müssen, während WebMCP sich für die Interaktionsschicht im Frontend eignet: komplexe Formulare, mehrstufige Navigation sowie Aktionen, die mit dem aktuellen UI-Zustand auf dem Bildschirm verknüpft sind.

Eine sichere Einstiegsmethode:

• Activieren Sie die lokale Flagge und registrieren Sie ein einfaches Tool – idealerweise nur zum Lesen, wie beispielsweise eine Produktsuche.
• Verwenden Sie annotations von Anfang an richtig. Verschieben Sie readOnlyHint und consequentialHint nicht auf später, denn sie bilden die Sicherheitsgrundlage, die bestimmt, inwieweit einem Agenten Ihr Tool anvertraut werden kann.
• Folgen Sie dem Repository der Web Machine Learning Community Group auf GitHub, da die Diskussionen in der Community die Spezifikation weiterentwickeln.

WebMCP ist noch lange nicht ausgereift, doch die Richtung ist klar. Im Web entsteht eine explizite Sprache zum Kommunizieren mit Agenten, ein eindeutiger Vertrag zwischen Entwickler und Agent anstelle von Vermutungen bezüglich des DOMs. Für alle, die an Tools und Schemata aus dem Backend-MCP gewöhnt sind, wird dieser Wandel vertraut vorkommen. Der Vertrag befindet sich nun einfach im Browser.