Website-Aktionen mit WebMCP für KI-Agenten zugänglich machen

WebMCP kehrt die Richtung des Model Context Protocol um. Statt dass sich ein Agent nach außen zu einem von Ihnen gehosteten Server verbindet, registriert Ihre Seite ihre eigenen Tools in JavaScript mit document.modelContext.registerTool(), und ein Agent, der die Seite bereits geöffnet hat, ruft diese deklarierten Aktionen direkt auf – statt sich durch Ihre Oberfläche zu klicken und Ihre Formularfelder zu erraten.

Wer bereits einen MCP-Server an einen Coding-Agenten angebunden hat, kennt das serverseitige Modell: ein Prozess, ein Transport, eine Tool-Liste, ein Client, der sich verbindet. Der Browser-Fall ist der unbequeme. Agenten-Traffic trifft auf einer gerenderten Seite mit eingeloggter Session ein, und bislang führte der einzige Weg über Aktuation: DOM auslesen, ableiten, was die Buttons tun, und hoffen, dass der Checkout-Schritt nicht mitten im Klick neu rendert.

Dieser Artikel behandelt die Mechanik, die für Betreiber einer realen Anwendung relevant ist: wie eine korrekte Tool-Registrierung aussieht, was die drei Annotation-Hints am Agentenverhalten tatsächlich ändern, wo Site-Tools heute laufen und welche Sicherheitsfolge es hat, wenn ein Tool innerhalb der angemeldeten Session des Nutzers ausgeführt wird.

Die Umkehrung: Was macht WebMCP anders?

Ein serverseitiger MCP-Server ist etwas, zu dem ein Agent sich nach außen verbindet – einmal konfiguriert und unabhängig von einer geöffneten Seite erreichbar. WebMCP funktioniert andersherum. OpenAIs Dokumentation zu Site-Tools zieht die Grenze dort, wo die Tools leben. MCP richtet eine KI-Anwendung auf einen Server aus, lokal oder remote, der außerhalb der Seite liegt und funktioniert, ob ein Browser geöffnet ist oder nicht. Eine WebMCP-Site übergibt ihre eigenen Fähigkeiten als fertiges Tool-Set, das ein Agent bei seiner Ankunft vorfindet – und der Nutzer muss nichts installieren.

Der Gewinn ist Präzision. Chromes WebMCP-Dokumentation formuliert den Unterschied darüber, wer entscheidet, was ein Bedienelement bedeutet: Bei einem Tool sagt die Website es ausdrücklich, und dem Agenten bleibt nichts mehr abzuleiten. Aktuation gibt ihm eine Kette von Schritten und bei jedem eine Ermessensentscheidung. Ein Agent, der search_orders({ status: "open" }) gegen ein von Ihnen geschriebenes Schema aufruft, kann sich nicht in ein Filter-Dropdown verklicken, und er bricht nicht, weil Sie eine CSS-Klasse umbenannt haben.

Wie registriert man ein Tool mit document.modelContext.registerTool()?

Die Tool-Registrierung nimmt ein Objekt mit name, description und inputSchema entgegen; Chromes Referenz zur imperativen API behandelt diese drei als Pflichtfelder, während annotations und eine execute-Funktion das Verhalten tragen. Führen Sie vor dem Aufruf eine Feature-Erkennung durch, genau wie OpenAIs eigenes Beispiel, denn die API ist in den meisten Browsern noch nicht vorhanden.

async function registerAgentTools() {
  if (typeof document.modelContext?.registerTool !== "function") return;

  await document.modelContext.registerTool({
    name: "list_orders",
    description:
      "List the signed-in customer's orders, newest first, optionally filtered by fulfilment status. Returns order number, placed date, status and total.",
    inputSchema: {
      type: "object",
      properties: {
        status: {
          type: "string",
          enum: ["open", "shipped", "delivered", "cancelled"],
          description: "Fulfilment status to filter by. Omit for all orders.",
        },
        limit: {
          type: "integer",
          minimum: 1,
          maximum: 20,
          description: "Maximum orders to return. Defaults to 10.",
        },
      },
      required: [],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    // Same function the orders table calls. The API still checks the session.
    execute: async ({ status, limit = 10 }) => fetchOrders({ status, limit }),
  });
}

Die Beschreibung ist das Einzige, was das Modell liest, wenn es entscheidet, ob dieses Tool zur Anfrage passt – sie wiegt also genauso schwer wie der Code dahinter. Benennen Sie die Rückgabestruktur, benennen Sie den Filter, und sagen Sie, was das Tool nicht abdeckt.

Beachten Sie, was execute hier tut: Es delegiert. Das Tool ruft dieselbe Datenabruf-Funktion auf wie die UI, und der Server dahinter wendet dieselbe Autorisierung an, die er ohnehin anwendet. OpenAIs Leitlinien verweisen Entwickler auf ihre bestehende Authentifizierung und Autorisierung statt auf einen parallelen Pfad, und der technische Grund liegt auf der Hand: Zwei Codepfade zur selben Fähigkeit driften auseinander, und derjenige ohne UI davor ist der, bei dem niemand das Driften bemerkt.

Was ändern die drei Annotation-Hints?

Annotationen sind Metadaten, die einem Agenten mitteilen, wie er ein Tool behandeln soll, bevor er es aufruft. Chrome dokumentiert drei davon, und Chromes Leitfaden zur Tool-Sicherheit ordnet jeden einzelnen dem Risiko zu, das er signalisiert.

Setzen Sie sie pro Tool und bewusst. Ein cancel_subscription-Tool ohne consequentialHint ist ein Tool, das ein Agent ohne Innehalten auslösen kann, und ein Tool zum Abrufen von Bewertungen ohne untrustedContentHint übergibt dem Modell einen Block fremdverfassten Texts ohne jede Kennzeichnung.

Wo läuft WebMCP heute?

OpenAIs Site-Tools-Seite legt dar, wo ChatGPT ein registriertes Tool berücksichtigt: im integrierten Browser der ChatGPT-Desktop-App, sofern aktuell gehalten, wo ChatGPT Work und Codex finden und aufrufen können, was die Seite anbietet. Auch das Modell ist entscheidend: GPT-5.6 Sol und GPT-5.6 Terra werden unterstützt, bei GPT-5.6 Luna ist WebMCP deaktiviert. Enterprise- und Edu-Workspaces bleiben außen vor, und ob das Feature überhaupt erscheint, hängt weiterhin vom Rollout und davon ab, was die geöffnete Seite registriert. Ein Pfeil in der Adressleiste listet die Tools auf, die eine Seite bereitstellt, und das gesamte Feature lässt sich unter den Browser-Berechtigungen abschalten.

Chromes Implementierung ist noch eine Preview. Chrome dokumentiert WebMCP hinter dem Flag chrome://flags/#enable-webmcp-testing für die lokale Entwicklung – auf Enabled gesetzt und mit Neustart –, daneben gibt es einen Origin Trial, dem Sie ab Chrome 149 beitreten können. Im Stable-Kanal ist es nicht standardmäßig aktiviert, und die Support-Aussagen beider Anbieter verändern sich; lesen Sie die Quellseiten also, bevor Sie darauf aufbauend ausliefern.

Was der Browser von ChatGPT nicht unterstützt

OpenAIs Dokumentation stellt klar, dass der integrierte Browser nur einen Teil von WebMCP abdeckt, und nennt zwei Lücken. Über HTML-Formularattribute definierte Tools werden nicht zu Site-Tools, und innerhalb eines iframes registrierte Tools werden nicht erkannt – auch same-origin iframes nicht. Die praktische Anweisung ist kurz: imperativ registrieren, auf dem Top-Level-Dokument, und sich nicht auf Exotisches verlassen.

Diese iframe-Beschränkung ist ChatGPTs, nicht die des Standards. Chrome stellt beide APIs hinter die tools-Permissions-Policy, die bei self beginnt. Mit diesem Default können das Top-Level-Dokument und Same-Origin-Frames Tools registrieren, ein Cross-Origin-iframe hingegen nicht. Ein eingebettetes Widget auf einer anderen Origin kann Tools registrieren, wenn dem Frame die tools-Policy gewährt wird, das Tool exposedTo mit den autorisierten Origins übergibt und der Aufrufer fromOrigins an getTools() übergibt. Chrome beschränkt WebMCP zudem auf origin-isolierte Dokumente, sodass eine Seite, die document.domain verwendet, gar keine API erhält.

Ihr Tool läuft als der angemeldete Nutzer

Ein registriertes Tool wird innerhalb der laufenden Seite unter der angemeldeten Session des Nutzers ausgeführt. Das bedeutet: Jede Fähigkeit, die Sie freigeben, ist eine Fähigkeit, die ein Agent mit der Autorität dieses Nutzers ausüben kann. Die Frage beim Zuschnitt lautet nicht, was bequem zu automatisieren wäre. Sie lautet, was Sie akzeptieren würden, wenn es ohne Klick aufgerufen wird.

Chromes Sicherheitsleitfaden ist ungewöhnlich deutlich darin, warum das zählt. Ein Modell nimmt Anweisungen und Daten als einen durchgehenden Strom von Tokens auf, ohne Trennlinie dazwischen. Sicherheit lässt sich innerhalb von etwas Probabilistischem nicht garantieren. Prompt Injection hat bereits funktioniert, und zwar wiederholbar, gegen Agentensysteme mit den besten verfügbaren Modellen, und die Zahl solcher Angriffe im Web steigt weiter. OpenAI sagt Ähnliches über die Tools selbst: In seiner Site-Tools-Dokumentation gelten sowohl die Tool-Definitionen einer Website als auch die von ihnen zurückgegebenen Ergebnisse als nicht vertrauenswürdiger Inhalt.

Daraus folgen drei konkrete Kontrollen. Die Tool-Sichtbarkeit beginnt geschlossen, denn andere Websites und Cross-Origin-iframes können Ihre Tools erst sehen, wenn Sie deren Origins in exposedTo benennen; behandeln Sie Read-only-Tools, die Nutzerdaten preisgeben, mit derselben Sorgfalt wie schreibende Tools. Chrome weist außerdem auf einen Zugriffsweg hin, den Sie nicht geöffnet haben: Erweiterungen können Ihre Tools aus einem Content-Script heraus abfragen und ausführen, und eine Erweiterung mit host_permission für Ihre Site kann ohnehin bereits eigenes JavaScript auf der Seite ausführen. Und halten Sie Texte knapp. Chrome empfiehlt 500 Zeichen für eine Tool-Beschreibung, 150 pro Parameterbeschreibung, 30 für Tool- und Parameternamen sowie 1,5K pro Tool-Ausgabe und bezeichnet alle vier als Empfehlungen, die sich mit Feedback aus dem Ökosystem ändern und später formalisiert werden können. Die Arbeit am Consent-Management läuft weiter, einschließlich eines im Spezifikationsentwurf vorgesehenen requestUserInteraction(), um den Nutzer mitten in der Ausführung etwas zu fragen – ausgeliefert ist es noch nicht.

WebMCP ist kein SEO-Hebel

Die Registrierung von Site-Tools verändert, was ein Agent tun kann, sobald er auf Ihrer Seite ankommt. Sie trägt nichts dazu bei, dass er ankommt. Chromes eigene Liste der Einschränkungen nennt die Auffindbarkeit von Tools als offenes Problem: Ein Client oder Browser erfährt nur durch den Besuch, dass eine Site aufrufbare Tools hat. Es gibt keinen Crawl, keinen Index, keinen Feed registrierter Tools. Vor dem Hintergrund dieses Mechanismus ist die Schlussfolgerung eindeutig – sie ist allerdings unsere Lesart und keine Herstelleraussage: WebMCP ist eine Fläche im Conversion-Pfad, kein Ranking- oder Zitationshebel, und wer eine Tool-Beschreibung wie einen Meta-Description-Text behandelt, verkennt, wer sie liest.

Wählen Sie eine Aktion, die Ihre Nutzer ohnehin auf Ihrer Site abschließen, registrieren Sie sie zunächst read-only und stecken Sie die eigentliche Arbeit in die Beschreibung und das Schema. Genau dort versteht ein Agent Ihre Anwendung – oder eben nicht. Und das ist der Teil, den kein Browser-Rollout für Sie richten wird.

FAQs

Wie hebe ich die Registrierung eines WebMCP-Tools auf, wenn der Nutzer die Seite verlässt?

Es gibt keine unregisterTool-Methode. Übergeben Sie ein AbortSignal im Options-Objekt von document.modelContext.registerTool und brechen Sie diesen Controller ab, sobald das Tool nicht mehr zutrifft – etwa beim Unmount einer Komponente oder bei einem Routenwechsel in einer SPA. Chromes Best Practices formulieren das über den Seitenzustand: Registrieren Sie ein Tool, solange es nützlich ist, und heben Sie die Registrierung auf, sobald es das nicht mehr ist. Den Abbruch an Ihre Seitenübergänge zu koppeln, ist der praktische Weg dorthin, und es verhindert, dass ein veraltetes Tool bestehen bleibt oder mit einer neuen Registrierung desselben Namens kollidiert. Agenten beobachten die Änderung über das toolchange-Event auf document.modelContext.

Was ist der Unterschied zwischen der deklarativen und der imperativen WebMCP-API?

Die deklarative API verwandelt ein bestehendes HTML-Formular in ein Tool: Fügen Sie dem form-Element die Attribute toolname und tooldescription hinzu, dazu toolparamdescription an einzelnen Feldern, und der Browser leitet daraus eine strukturierte Repräsentation des Formulars ab. Das Entfernen eines der beiden Attribute hebt die Registrierung des Tools auf. Die imperative API, document.modelContext.registerTool, eignet sich für dynamische Tools und komplexe Logik. Der integrierte Browser von ChatGPT unterstützt nur den imperativen Weg.

Gibt es React- oder Angular-Unterstützung für die Registrierung von WebMCP-Tools?

Beides existiert und beides ist experimentell. Chrome Labs pflegt den useWebMCP-Hook im Paket use-webmcp-tool, der ein Tool beim Mount registriert, es beim Unmount wieder abmeldet, React 18 oder neuer voraussetzt und dort, wo die API fehlt, zu einer No-op wird. Angular stellt provideExperimentalWebMcpTools in seinem Core-Paket bereit und koppelt die Tool-Lebensdauer an einen Injector, wobei Route- oder Application-Provider als Platzierung empfohlen werden.

Validiert der Browser die von einem Agenten übergebenen Argumente gegen mein inputSchema?

Gehen Sie nicht davon aus. Behandeln Sie die Eingabe, die execute erreicht, als nicht validiert und prüfen Sie sie im Code, bevor Sie darauf reagieren. Chromes WebMCP-Leitfaden weist Entwickler an, Constraints zu validieren und aussagekräftige Fehler zurückzugeben, damit der Agent es erneut versuchen kann; Angular sagt unmissverständlich, dass es vom Agenten gelieferte Argumente nicht gegen das von Ihnen deklarierte JSON-Schema prüft. Serverseitige Autorisierungsprüfungen gelten weiterhin zusätzlich.