WebMCP: Definition, APIs und Unterschied zu MCP

Beispiel aus der Praxis

Ein Entwicklerportfolio mit Glossar und Fallstudien ist ein typischer Kandidat. Ein Browser-Agent, der im Auftrag einer Recruiterin prüfen soll, ob jemand Erfahrung mit RAG hat, müsste ohne WebMCP die Navigation lesen, eine Suche finden und Ergebnislisten auswerten. Mit WebMCP kann die Seite stattdessen ein Werkzeug wie projekte_suchen anbieten, das eine Liste passender Fallstudien mit Titel und Adresse zurückgibt.

Das Werkzeug ruft dieselbe Suchlogik auf, die auch das Suchfeld der Seite nutzt. Es liest nur und ändert nichts, was die Seite über den Hinweis readOnlyHint kennzeichnet. Ohne WebMCP im Browser passiert nichts, die Seite funktioniert wie bisher. So lässt sich der Standard als progressive Erweiterung testen, ohne sich auf einen Entwurf zu verlassen.

Ein solches Szenario ist bewusst klein gehalten: ein Werkzeug, nur lesend, ohne Zugriff auf Formulare mit persönlichen Daten.

Wie funktioniert WebMCP?

Eine Website meldet beim Browser Werkzeuge an. Jedes Werkzeug hat einen Namen, eine Beschreibung in natürlicher Sprache und ein Eingabeschema. Ein Agent, der die Seite besucht, sieht diese Werkzeuge und kann sie aufrufen. Laut Chrome-Dokumentation soll die Website damit selbst erklären, wofür ein Element da ist, statt dass der Agent es aus dem Seitenaufbau erraten muss (Chrome for Developers, Stand: Oktober 2026).

Beide APIs unterliegen der Permissions Policy tools. Standardwert ist self, also erlaubt für das eigene Origin und das oberste Dokument; Iframes von fremden Origins brauchen allow="tools". Für folgenreiche Aktionen wie Käufe kann ein Bestätigungsdialog für den Nutzer verlangt werden (Chrome for Developers).

Wie sieht die imperative API aus?

Die imperative API registriert ein Werkzeug über document.modelContext.registerTool(). Pflichtfelder sind name, description, inputSchema als JSON-Schema und eine asynchrone Funktion execute. Optional sind annotations, darunter readOnlyHint, das standardmäßig false ist (Chrome for Developers, Imperative API).

// Nur ausführen, wenn der Browser WebMCP anbietet.
if ('modelContext' in document) {
  const controller = new AbortController();

  await document.modelContext.registerTool(
    {
      name: 'projekte_suchen',
      description: 'Sucht Fallstudien auf dieser Website nach einem Stichwort und gibt Titel und URL zurück.',
      inputSchema: {
        type: 'object',
        properties: {
          stichwort: { type: 'string', description: 'Suchbegriff, z. B. "RAG" oder "n8n"' },
        },
        required: ['stichwort'],
      },
      annotations: { readOnlyHint: true },
      execute: async ({ stichwort }) => {
        const treffer = sucheProjekte(stichwort); // vorhandene Suchlogik der Seite
        return JSON.stringify(treffer.map((p) => ({ titel: p.titel, url: p.url })));
      },
    },
    { signal: controller.signal },
  );

  // Später abmelden: controller.abort();
}

Über das signal in den Optionen meldet abort() das Werkzeug wieder ab. Laufende Ausführungen werden dadurch laut Dokumentation nicht abgebrochen (Chrome for Developers, Stand: Oktober 2026).

Wie funktioniert die deklarative API?

Die deklarative API macht ein bestehendes HTML-Formular zum Werkzeug. Am <form> stehen toolname und tooldescription; fehlt eines davon, wird das Werkzeug abgemeldet. Felder erhalten mit toolparamdescription eine Beschreibung für das Schema, ohne das Attribut nutzt Chrome den Text des zugehörigen <label>. Mit toolautosubmit sendet der Browser das Formular ab, sobald der Agent das Werkzeug aufruft; ohne dieses Attribut bleibt das ausgefüllte Formular sichtbar und der Mensch klickt selbst auf Absenden (Chrome for Developers, Declarative API).

Im Submit-Ereignis zeigt agentInvoked, ob ein Agent das Formular ausgelöst hat, und respondWith() gibt nach preventDefault() ein Ergebnis an das Modell zurück.

Was ist der Unterschied zwischen WebMCP und MCP?

Die Autoren beschreiben WebMCP als Ergänzung: Es übernimmt Begriffe aus dem Model Context Protocol, läuft aber im Browser und nutzt Konzepte des Webs wie Origins und Berechtigungen. MCP direkt zu übernehmen, haben sie verworfen, weil dort Konzepte wie DOM-Anbindung und der Lebenszyklus eines Tabs fehlen (webmachinelearning/webmcp).

Wie testet man WebMCP?

Für eigene Versuche reicht ein lokales Chrome mit aktiviertem Flag chrome://flags/#enable-webmcp-testing und einem Neustart des Browsers. Wer WebMCP auf einer öffentlichen Website mit echten Besuchern ausprobieren will, meldet sich laut Chrome-Dokumentation für den Origin Trial an, der ab Chrome 149 verfügbar ist (Chrome for Developers, Stand: Oktober 2026).

In beiden Fällen gilt: Der Code sollte prüfen, ob document.modelContext existiert, und sonst nichts tun. So bleibt die Seite in allen anderen Browsern unverändert, und eine spätere Änderung der Spezifikation trifft nur die optionale Erweiterung.

Für die Werkzeuge selbst gelten dieselben Regeln wie bei einem MCP-Server. Namen und Beschreibungen sind die Schnittstelle zum Modell und sollten genau sagen, was ein Werkzeug tut und was es zurückgibt. Ein Werkzeug pro Aufgabe ist leichter zu kontrollieren als ein allgemeines Werkzeug mit vielen Optionen. Rückgaben sollten knapp und strukturiert sein, damit der Agent sie zuverlässig weiterverarbeiten kann.

Welche Grenzen und Risiken hat WebMCP?

Entwurfsstatus. Die Spezifikation ist ein Draft Community Group Report und steht laut eigenem Text nicht auf dem Standardisierungspfad des W3C (Stand 16. Oktober 2026). Namen und Verhalten können sich ändern.

Kein Betrieb ohne Tab. Laut Chrome ist WebMCP für den Einsatz im sichtbaren Browser mit einem Menschen gedacht. Ein Agent muss eine Seite besuchen, um ihre Werkzeuge zu sehen.

Erweiterungen und fremde Inhalte. Chrome weist darauf hin, dass Browser-Erweiterungen Werkzeuge über Content Scripts abfragen und ausführen können. Gibt ein Werkzeug Inhalte von Nutzern zurück, etwa Kommentare, droht Prompt Injection; dafür gibt es den Hinweis untrustedContentHint.

Schreibende Werkzeuge. Werkzeuge, die bestellen, senden oder löschen, sollten eine Bestätigung durch den Menschen verlangen, wie es auch bei Agentic Commerce üblich ist.