WebMCP: Tools veröffentlichen statt Pixel ausliefern

WebMCP ist ein vorgeschlagener Webstandard, der es einer Seite erlaubt, typisierte, aufrufbare Tools an einen KI-Agenten zu publizieren, statt den Agenten die Absicht aus dem DOM erraten zu lassen. Der Vorschlag ist klein, die Browser-Unterstützung ist dünn, und die Designentscheidung ist die richtige. Behandle ihn als Spezifikation, die man verfolgt, und als progressive Enhancement hinter einer Feature Detection, nicht als Abhängigkeit für dieses Quartal.

Er steht neben Model Context Protocol, nicht dagegen. Ein MCP-Server exponiert Backend-Funktionen an jeden Client, überall; WebMCP exponiert den Live-Zustand einer angemeldeten Seite im Tab an einen integrierten Browser-Agenten und verschwindet, wenn der Tab schließt. Die interessante technische Frage ist nicht, welches Protokoll gewinnt. Es ist, welches ohne zusätzlichen Server vorhandene Frontend-Logik erreichbar macht.

Was es ist

Die Spezifikation liegt in der W3C Web Machine Learning Community Group und ist im WebMCP-Explainer auf GitHub beschrieben, wo die Teams von Chrome und Edge die sichtbaren Implementierer sind. Chrome liefert sie ab Version 149 hinter einem Origin Trial, mit einem lokalen Entwicklungs-Flag unter chrome://flags/#enable-webmcp-testing. Die API ist ein Objekt auf Document, und sie kommt in zwei Formen.

• document.modelContext stellt registerTool(), getTools(), executeTool() und ein toolchange-Event bereit.
• Ein Tool besteht aus einem Namen, einer natürlichsprachlichen Beschreibung, einem JSON Schema für die Eingabe und einer Execute-Funktion, die in der Seite läuft.
• Die deklarative API macht aus einem annotierten Formular ein Tool, über toolname, tooldescription, toolparamdescription und toolautosubmit.
• Tools sind ephemer. Sie existieren nur, solange die Seite geöffnet ist, und laufen mit deren Cookies und Session.
• Beide APIs sind an die tools-Permissions-Policy gebunden, die standardmäßig self ist. Cross-Origin-Iframes bleiben damit aus, solange der Host nicht allow="tools" setzt.
• Tool-Metadaten liegen im Kontextfenster des Modells. Die Anzahl registrierter Tools ist damit ein Budget pro Seite und nicht nur eine Codefrage.

Wie es funktioniert

Registrieren ist ein Aufruf aus dem Seitenskript; der Aufruf selbst wird vom Browser zwischen Agent und Seite vermittelt. Der Browser gibt dem Agenten nie ein DOM-Handle. Er parst die Argumente, ruft deine Execute-Funktion auf und reicht den Rückgabewert als Tool-Ergebnis zurück. Das ist die ganze Ergonomie-Geschichte in einem Satz: Die Seite entscheidet, was aufrufbar ist, und der Browser entscheidet, wer es aufrufen darf.

Der praktische Unterschied zur Aktuierung zeigt sich im Fehlerpfad. Ein Klick auf ein falsch gerendertes Element scheitert still oder löst den falschen Handler aus. Ein Tool-Aufruf mit einem schlechten Argument trifft deine eigene Validierung und liefert eine Meldung, die das Modell lesen und darauf reagieren kann. Chromes Leitfaden sagt das ausdrücklich und empfiehlt, im Code streng zu validieren, das Schema aber locker zu halten, weil eine Schema-Ablehnung eine Sackgasse für den Agenten ist.

Erste Schritte

Die imperative API ist die richtige Wahl, weil nur sie Anwendungszustand erreichen kann. Ein minimales Read-only-Tool sieht so aus.

// Feature-detect: the API is behind a flag or an origin trial.
if (typeof document.modelContext?.registerTool !== 'function') return;

const controller = new AbortController();

await document.modelContext.registerTool({
  name: 'get_order_status',
  description: 'Return the shipping status of one order for the signed-in customer.',
  inputSchema: {
    type: 'object',
    properties: {
      orderNumber: { type: 'string', description: 'Order number as shown in the order list.' },
    },
    required: ['orderNumber'],
    additionalProperties: false,
  },
  annotations: { readOnlyHint: true },
  execute: async ({ orderNumber }) => {
    const order = await orders.findForCustomer(orderNumber);
    // A message the model can act on beats a thrown Error.
    if (!order) return `No order ${orderNumber} is visible to this account.`;
    return `Order ${orderNumber}: ${order.status}, arriving ${order.eta}.`;
  },
}, { signal: controller.signal });

// Unregister on route change. From Chrome 153 aborting no longer breaks a
// call that is already running.
controller.abort();

Drei Details sind wichtiger als der Rest. Die Beschreibung ist das Einzige, was das Modell liest, um zu entscheiden, ob es das Tool aufruft, und Chromes Leitfaden begrenzt sie auf 500 Zeichen. Die Execute-Funktion sollte die Funktion wiederverwenden, die der sichtbare Button schon aufruft, damit es einen Codepfad gibt und Oberfläche und Tool nicht auseinanderlaufen können. Das AbortSignal ist der Weg zum Abmelden, kein Timeout.

Deklarative Formulare

Die deklarative API ist für einfache Formulare und nichts sonst. Ein Formularelement annotieren, und der Browser leitet die Tool-Definition aus dem Markup und den Feldnamen ab.

<form toolname="create_support_request"
      tooldescription="Submits a support request for the signed-in customer."
      action="/support"
      toolautosubmit>
  <label for="subject">Subject</label>
  <input id="subject" name="subject" type="text">

  <label for="reason">Reason</label>
  <select id="reason" name="reason" required
          toolparamdescription="Determines which team handles the request.">
    <option value="returns">Return a purchase</option>
    <option value="delivery">Where is my parcel</option>
    <option value="site">The website is broken</option>
  </select>

  <button type="submit">Submit</button>
</form>

Ohne toolautosubmit füllt der Agent das Formular und der Mensch klickt auf Absenden. Das ist die richtige Voreinstellung für alles, was Kosten verursacht. Mit dem Attribut sendet und navigiert der Browser, und respondWith() auf dem SubmitEvent erlaubt der Seite, stattdessen ein Ergebnis an das Modell zurückzugeben. Das Flag agentInvoked sagt der Seite, welcher der beiden Wege gerade läuft.

Tools, die Agenten auswählen

Der veröffentlichte Best-Practice-Leitfaden ist ungewöhnlich konkret, und es lohnt sich, ihm wörtlich zu folgen. Die Leitidee: Eine Tool-Beschreibung ist Code, den ein probabilistischer Leser einmal pro Sitzung interpretieren muss. Die Zeichenbudgets existieren, damit der gesamte Katalog in der Aufmerksamkeit dieses Lesers bleibt.

Der Rat oberhalb der Tabelle ist der schwierigere Teil: eine Funktion pro Tool, keine Überschneidungen, und Registrierung passend zum Seitenzustand statt eines statischen Katalogs auf jeder Seite. Überschneidende Tools sind der häufigste Grund, warum ein Agent das falsche wählt.

• Eine Verantwortung. Eine Funktion pro Tool und kein zweites Tool, das fast dasselbe tut.
• Für den aktuellen Zustand registrieren. Den Controller abbrechen, wenn sich Route oder Dialog ändert, damit der Agent keine Tools mehr sieht, die nicht mehr gelten.
• Roheingaben akzeptieren. Wenn jemand 11:00 to 15:00 sagt, nimm den String und normalisiere ihn im Code. Das Modell soll nicht rechnen.
• Lesbare Enum-Werte. "express" ist besser als shipping_id = 1, denn das Modell liest den Wert und nicht deine Datenbank.
• Handlungsfähige Fehler zurückgeben. Sag, was zu tun ist, nicht was intern kaputtging. Auch ein fehlgeschlagenes Tool sollte nutzbar bleiben.

Sicherheit und Annotationen

Annotationen sind der wichtigste Hebel, den eine Seite hat, um zu steuern, wie ein Host ihre Tools behandelt, und alle vier stehen standardmäßig auf false. Das ist die sichere Voreinstellung, bedeutet aber: Die Sicherheitseigenschaften eines Tools sind genau so ehrlich wie die Seite, die es registriert.

• readOnlyHint das Tool liest und ändert nichts. Bei jeder Lookup-Funktion setzen.
• untrustedContentHint der Rückgabewert enthält nutzergenerierte oder extern bezogene Daten und muss begrenzt werden, bevor er das Modell erreicht.
• consequentialHint der Aufruf bucht, zahlt, sendet oder löscht. Clients können damit eine Bestätigung erzwingen.
• debugging ab Chrome 156 markiert das ein Entwickler-Tool, damit allgemeine Agenten es herausfiltern können.

Chromes Sicherheitsleitfaden behandelt indirekte Prompt Injection als ungelöst. Modelle sind probabilistisch, wiederholbare Angriffe auf agentische Systeme sind dokumentiert, und der Rückgabewert eines Tools ist ein Kanal, den ein Angreifer beschreiben kann. Empfohlen werden Annotationen, Zeichenbudgets und Origin-Isolation, also Schadensbegrenzung und keine Lösung. Dieselbe Seite weist darauf hin, dass eine Extension mit Host-Berechtigungen die Seite auch ohne WebMCP bereits mit beliebigem JavaScript steuern kann.

Wo es zu kurz kommt

Die Schwächen kommen zuerst, weil sie der Grund sind, warum das hier ein Beobachtungsposten und keine Abhängigkeit ist. Die Unterstützung ist faktisch eine Engine-Familie. Die Statusdatei der Spezifikation nennt ein Origin Trial in Chrome 149 und Edge 150, experimentelle Unterstützung in Braves Leo-Chat, Unterstützung in ChatGPT Desktop sowie Standards-Position-Einträge in Firefox und WebKit ohne Implementierung dahinter. Chrome dokumentiert außerdem Headless-Browsing als außerhalb des Anwendungsbereichs, warnt davor, dass komplexe Oberflächen eine Umstrukturierung brauchen, um Anwendungs- und Oberflächenzustand synchron zu halten, und weist darauf hin, dass Clients eine Seite besuchen müssen, um ihre Tools zu entdecken. Es gibt kein Register, kein Manifest und keinen Index.

Der Punkt zur Auffindbarkeit verdient Betonung, weil er das übliche Geschäftsargument zerschlägt. Ein Backend-MCP-Server kann von einem Agenten gefunden werden, der die Seite nie besucht. Ein WebMCP-Tool nicht. Der einzige realistische Discovery-Pfad heute ist ein Nutzer, der die Seite öffnet. WebMCP konkurriert damit um die Qualität einer bereits begonnenen Sitzung, nicht um Reichweite.

Urteil

WebMCP ist eine sauber gezeichnete API für ein reales Problem, und besser gezeichnet, als die meisten Teams sie selbst gebaut hätten. Es ist noch keine Abhängigkeit. Baue die Tool-Schicht hinter eine Feature-Prüfung, lass die menschliche Oberfläche der Hauptpfad bleiben und schau wieder vorbei, wenn eine zweite Engine ausgeliefert wird oder die deklarative Hälfte nicht mehr Chromium-only ist. Für die Mechanik einer agentenfähigen Seite hat der Leitfaden des Sites zum agentenfähigen Webaufbau mit deklarierten Tools die Implementierungsdetails im Detail.

1. Nutze es auf Produktflächen, auf denen ein angemeldeter Nutzer und ein Agent dieselbe Seite sehen: Buchung, Checkout, Support-Anfragen, Einstellungen.
2. Lass es weg bei reinen Lese-Anwendungsfällen. Eine Markdown-Kopie der Seite ist billiger und braucht keinen Browser.
3. Lass es weg, wenn deine Abläufe überwiegend Formulare sind, die du nicht annotieren kannst, oder wenn du die Oberfläche nicht mit dem Tool-Pfad synchron halten kannst.
4. Baue keinen MCP-Server in der Erwartung, dass WebMCP ihn ersetzt. Beide sind verschiedene Schichten, und die nützliche Architektur nutzt beides.
5. Behandle die Zeichenbudgets und die Ein-Funktion-pro-Tool-Regel als harte Grenzen für den Katalog, nicht als Vorschläge.

Quellen

1. Chrome for Developers: WebMCP (get started)
2. Chrome for Developers: Imperative API
3. Chrome for Developers: Declarative API
4. Chrome for Developers: WebMCP versus MCP
5. Chrome for Developers: WebMCP tool security
6. Chrome for Developers: Build effective tools
7. WebMCP explainer and specification draft
8. WebMCP implementation status