> WebMCP lässt eine Seite typisierte, aufrufbare Tools an einen Agenten im Browser publizieren. Was der Standard tut, wie viel heute ausgeliefert ist und wann ein MCP-Server die bessere Wahl bleibt. > > Web page: https://balazscsorba.com/de/blog/webmcp · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/webmcp.md) · [Magyar](https://balazscsorba.com/hu/blog/webmcp.md) > Author: Balázs Csorba · Published: 2026-09-30 · Keywords: webmcp, webmcp vs mcp, document.modelContext registerTool, webmcp declarative api, browser agent tools, webmcp origin trial, webmcp chrome 149 [Blog](https://balazscsorba.com/de/blog)/Web-Engineering # WebMCP: Tools veröffentlichen statt Pixel ausliefern WebMCP lässt eine Seite typisierte, aufrufbare Tools an einen Agenten im Browser publizieren. Was der Standard tut, wie viel heute ausgeliefert ist und wann ein MCP-Server die bessere Wahl bleibt. [Balázs Csorba](https://balazscsorba.com/de/about)·30\. September 2026·11 Min. Lesezeit - WebMCP - Agent tools - JSON Schema - Chrome - MCP ![Eine breite Fläche aus winzigen Quadraten, ein Schlitz in der Kante führt einen geformten Block zum Empfänger.](https://balazscsorba.com/images/blog/webmcp/cover.webp?v=026ce075d9) ## Das Wichtigste in Kürze - WebMCP ist ein API-Vorschlag für den Browser, keine Bibliothek: Chrome 149 und Edge 150 liefern ihn als Origin Trial, Firefox und Safari stehen bei der Standards-Position. - Tools sind an den Tab gebunden, laufen im Code der Seite selbst und werden über die tools-Permissions-Policy gesteuert, nicht durch ein Raten des Agenten im DOM. - Chromes Leitfaden begrenzt eine Tool-Beschreibung auf 500 Zeichen und die Ausgabe eines Tools auf 1,5 KB. Der Tool-Katalog ist also ein Budget im Kontextfenster. - Alle vier Tool-Annotationen stehen standardmäßig auf false. Die Sicherheitseigenschaften eines Tools sind also so ehrlich wie die Seite, die sie setzt. - Es gibt keinen Discovery-Mechanismus: Ein Client muss die Seite besuchen, um zu erfahren, dass es Tools gibt. Das ändert den geschäftlichen Wert des Standards. Auf dieser Seite 1. [Was es ist](https://balazscsorba.com/#what-it-is) 2. [Wie es funktioniert](https://balazscsorba.com/#how-it-works) 3. [Erste Schritte](https://balazscsorba.com/#getting-started) 4. [Tools, die Agenten auswählen](https://balazscsorba.com/#tool-design) 5. [Sicherheit und Annotationen](https://balazscsorba.com/#security) 6. [Wo es zu kurz kommt](https://balazscsorba.com/#where-it-shingles) 7. [Urteil](https://balazscsorba.com/#verdict) 8. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 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. ![WebMCP tool lifecycle A page registers a tool on document.modelContext. The browser mediates: it lists the tools to the agent, the agent invokes one, the execute function runs in the page, the page updates its own DOM and state, and the result travels back through the browser to the agent.](https://balazscsorba.com/images/blog/webmcp/diagram-7.webp?v=517519f667) Der Browser sitzt zwischen Agent und Seite. Nichts anderes in der Schleife kann diese Grenze erweitern. 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. ```
``` 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. **Die günstige Hälfte des Standards** Die deklarative API erreicht keine reine JavaScript-Funktion, weil in der Tool-Definition kein JavaScript steckt. OpenAIs Dokumentation zu den Site-Tools hält fest, dass der eingebaute Browser die deklarative API gar nicht implementiert. Eine reine Formular-Integration ist für ChatGPT Work und Codex heute also unsichtbar. ## 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. Budget Empfohlene Grenze Tool-Beschreibung 500 Zeichen Parameter-Beschreibung 150 Zeichen Tool-Name und Parameter-Name je 30 Zeichen Ausgabe eines Tools 1,5 KB Zeichen 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. **exposedTo ist die scharfe Kante** Die Option `exposedTo` listet sichere Origins, die ein Tool finden und ausführen dürfen, und der Leitfaden ist deutlich: Ein Read-only-Tool kann Nutzerdaten preisgeben, ein schreibendes Tool handelt im Namen des Nutzers. Gib nur Origins frei, denen du auch die Zugangsdaten geben würdest. ## 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. WebMCP MCP-Server DOM-Aktuierung Lebenszyklus An den Tab gebunden, weg beim Navigieren Dauerhafter Daemon Ein Request Sieht Live-DOM, Cookies, Session Nur das, was du exponierst Was der Agent abgreift Führt deinen Code aus Ja, in der Seite Nein, nur serverseitig Nein Erreichbar von Heute eine Engine-Familie Jedem MCP-Client Jedem Browser 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](https://balazscsorba.com/de/blog/webmcp-agent-ready-website-guide) 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. **Das billigste erste Experiment** Nimm einen bestehenden Button-Handler, packe ihn mit ehrlich gesetzten Annotationen in `registerTool()` und messe, ob der Agent den Tool-Pfad statt des Klick-Pfads nimmt. Diese eine Messung beantwortet die Adoptionsfrage schneller als jede Spezifikationslektüre. ## Quellen 1. [Chrome for Developers: WebMCP (get started)](https://developer.chrome.com/docs/ai/webmcp) 2. [Chrome for Developers: Imperative API](https://developer.chrome.com/docs/ai/webmcp/imperative-api) 3. [Chrome for Developers: Declarative API](https://developer.chrome.com/docs/ai/webmcp/declarative-api) 4. [Chrome for Developers: WebMCP versus MCP](https://developer.chrome.com/docs/ai/webmcp/compare-mcp) 5. [Chrome for Developers: WebMCP tool security](https://developer.chrome.com/docs/ai/webmcp/secure-tools) 6. [Chrome for Developers: Build effective tools](https://developer.chrome.com/docs/ai/webmcp/build-tools) 7. [WebMCP explainer and specification draft](https://github.com/webmachinelearning/webmcp) 8. [WebMCP implementation status](https://github.com/webmachinelearning/webmcp/blob/main/implementation-status.md) ## Häufige Fragen Was ist WebMCP? WebMCP ist ein vorgeschlagener Webstandard, der es einer Seite erlaubt, typisierte, aufrufbare Tools an einen KI-Agenten im Browser zu publizieren. Die Seite registriert einen Namen, eine natürlichsprachliche Beschreibung, ein JSON Schema für die Eingabe und eine Execute-Funktion; der Browser vermittelt die Aufrufe zwischen Agent und Funktion. Die Tools leben nur so lange wie der geöffnete Tab. Ist WebMCP ein Ersatz für MCP? Nein. Chromes eigene Vergleichsseite behandelt beide als Partner, nicht als Rivalen: MCP exponiert Backend-Funktionen dauerhaft an jeden Client, WebMCP exponiert den Live-Zustand einer Seite ephemer an einen integrierten Browser-Agenten. In der Praxis landen die meisten Systeme bei beidem: MCP für die Fachlogik, WebMCP für die Oberfläche vor dem Nutzer. Brauche ich das Chrome-Origin-Trial, um WebMCP lokal zu nutzen? Nein. Für die lokale Entwicklung aktiviert das Flag chrome://flags/#enable-webmcp-testing die API ohne Token. Für echte Nutzer auf Chrome 149 oder neuer ist eine Registrierung für das Origin Trial nötig, Edge 150 hat ein eigenes Trial mit eigener Registrierung. Was ist die größte Einschränkung heute? Die Browser-Unterstützung, gefolgt von der Auffindbarkeit. Die Implementierungsstatus-Datei im Spezifikationsrepository nennt Origin Trials in Chrome und Edge, experimentelle Unterstützung in Braves Leo-Chat und Unterstützung in ChatGPT Desktop, und nichts Ausgeliefertes in Firefox oder Safari. Dazu kommt: Die API ist nicht für Headless-Browsing gedacht, und ein Client erfährt nur durch einen Besuch, dass eine Seite Tools anbietet. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Schema.org-Strukturdaten für B2B-Shops: Preise hinter Logins, Einheiten und Varianten](https://balazscsorba.com/de/blog/schema-org-structured-data-b2b-shop) - [Ein KI-Assistent für den Support im B2B-Shop: Tools, Berechtigungen und die Übergabe an Menschen](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support) - [Streaming-Chat mit KI in Vue und Nuxt: von Anfang an barrierefrei](https://balazscsorba.com/de/blog/vue-ai-chat-ui-streaming-accessibility) - [Eine LLM-Übersetzungspipeline für i18n: Glossar, Platzhalter und Review](https://balazscsorba.com/de/blog/llm-translation-pipeline-i18n) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)