---
title: "WebMCP erklärt: Wie Chrome deine Website zum MCP-Server für KI-Agenten macht"
description: "WebMCP erklärt: wie die neue Browser-API KI-Agenten das JavaScript einer Website als Tools im MCP-Stil aufrufen lässt, wie Chrome 149 Registrierung, Discovery und Ausführung umsetzt, worin sich WebMCP von MCP-Servern unterscheidet und was ich beim Produktivbetrieb von fünf WebMCP-Tools gelernt habe."
author: Aleksei Aleinikov
date: 2026-09-30
lang: de
tags: [webmcp, mcp, model context protocol, chrome webmcp, ki-agenten, browser-agenten]
canonical: https://www.alekseialeinikov.com/de/blog/topics/ai/webmcp-erklaert-chrome-ki-agenten-mcp-tools
source: alekseialeinikov.com
---
# WebMCP erklärt: Wie Chrome deine Website zum MCP-Server für KI-Agenten macht
KI-Agenten bedienen die meisten Websites wie ein Mensch mit verbundenen Augen: Screenshot machen, raten, welches Feld die Suche ist, klicken, tippen, warten, nächster Screenshot – und hoffen, dass sich das Layout nicht geändert hat. Das reicht für eine Demo und scheitert oft genug, um zu nerven.
**WebMCP** dreht das um. Statt dass der Agent deine Oberfläche zurückentwickelt, sagt die Seite dem Agenten, was sie kann – als Tools mit Namen, Beschreibung und JSON Schema. Die Idee ist dieselbe wie bei einem [MCP-Server](https://www.alekseialeinikov.com/de/blog/topics/ai/mcp-server-erklaert-selbst-bauen-und-sicher-betreiben-2026), nur läuft alles im Browser-Tab. Chrome liefert WebMCP seit Chrome 149 als Origin Trial aus, und am 27. September 2026 habe ich fünf WebMCP-Tools im [Tools-Bereich dieser Website](https://www.alekseialeinikov.com/de/tools) live geschaltet.
Dieser Guide erklärt, wie WebMCP funktioniert, was Chrome zwischen deiner Seite und dem Agenten tatsächlich macht, worin es sich von MCP unterscheidet und worauf ich im Produktivbetrieb gestoßen bin.
## WebMCP auf einen Blick
| | |
|---|---|
| **Was es ist** | Ein vorgeschlagener Webstandard, der JavaScript-Funktionen und HTML-Formulare einer Seite als Tools für KI-Agenten bereitstellt |
| **Wer dahintersteht** | [W3C Web Machine Learning Community Group](https://github.com/webmachinelearning/webmcp); das Explainer-Dokument erschien erstmals am 13. August 2025, verfasst von Entwicklern bei Microsoft und Google |
| **Kern-API** | `document.modelContext.registerTool()`, `getTools()`, `executeTool()` und das Event `toolchange` |
| **Deklarative Variante** | Die Attribute `toolname` und `tooldescription` an einem `
```
Chrome macht aus den Formularfeldern ein JSON Schema und nutzt das `` jedes Feldes (oder ein Attribut `toolparamdescription`) als Parameterbeschreibung. Ruft der Agent das Tool auf, fokussiert der Browser das Formular und füllt es aus, während der Nutzer zusieht.
## Wie Chrome WebMCP umsetzt
Jetzt wird es spannend. WebMCP ist keine Bibliothek, die der Agent in deine Seite lädt. Der Browser besitzt die Registry und steht bei jedem Aufruf in der Mitte.
### 1. Zuerst kommen die Schranken
Bevor sich überhaupt ein Tool registriert, gelten drei Prüfungen:
- **Das Feature muss aktiv sein.** Entweder trägt deine Origin ein gültiges [Origin-Trial-Token](https://developer.chrome.com/blog/ai-webmcp-origin-trial), oder der Nutzer hat das Test-Flag eingeschaltet.
- **Das Dokument muss origin-isoliert sein.** Nutzt eine Seite `document.domain` – etwa über `Origin-Agent-Cluster: ?0` –, schaltet Chrome die WebMCP-APIs ab, damit sich die Origin eines Tools während seiner Lebensdauer nicht ändern kann.
- **Die Permissions Policy `tools` muss es erlauben.** Standard ist `self`: Top-Level-Dokumente und iFrames derselben Origin dürfen Tools registrieren, fremde iFrames nur, wenn die einbettende Seite `allow="tools"` setzt. Blockiert die Policy, lehnt `registerTool()` mit einem `NotAllowedError` ab.
### 2. Die Registrierung baut eine Registry pro Dokument
`registerTool()` übergibt Chrome die Definition. Chrome speichert sie zusammen mit Origin und Fenster der Seite und feuert ein `toolchange`-Event auf `document.modelContext`. `getTools()` liefert die Liste alphabetisch sortiert und enthält standardmäßig nur Tools aus Dokumenten derselben Origin im Frame-Baum. Für eine andere Origin wird ein Tool nur sichtbar, wenn du sie in `exposedTo` einträgst **und** der Aufrufer sie mit `fromOrigins` anfragt.
### 3. Der Agent findet Tools, während der Nutzer auf der Seite ist
Der Agent lädt Name, Beschreibung und Schema jedes Tools in den Kontext des Modells. Die Discovery hängt am Besuch: Laut Chrome-Doku müssen Clients eine Website direkt besuchen, um zu wissen, ob sie aufrufbare Tools hat. Ein Manifest, das Crawler lesen könnten, gibt es noch nicht.
### 4. Chrome vermittelt den Aufruf
Wählt das Modell ein Tool, ruft der Agent `executeTool(tool, args)` auf. Chrome prüft, ob Freigabe und Origins zusammenpassen, und führt dann dein `execute()` **im Kontext der Seite aus, der das Tool gehört**. Es läuft also mit der eingeloggten Session, den Cookies und dem aktuellen Seitenzustand des Nutzers – genau das, was eine Backend-Integration auf einem Server nachbauen müsste.
`execute()` bekommt ein `AbortSignal` als `options.signal`. Drückt der Nutzer in der Agent-Oberfläche auf Stopp, feuert das Signal, und du kannst einen `fetch()` oder eine lange Aufgabe abbrechen. Löst ein Tool eine Navigation aus, liefert `executeTool()` den Wert `null`.
### 5. Abmelden ist einfach ein Abort
Tools meldet man ab, indem man das Signal abbricht, das man `registerTool()` übergeben hat. Seit Chrome 153 bricht das Abmelden eine bereits laufende Ausführung nicht mehr ab – wichtig in Komponenten-Frameworks, die oft mounten und unmounten. Google rät, nur Tools zu registrieren, die zum aktuellen Seitenzustand passen, und sie wieder zu entfernen, wenn sie nicht mehr gelten: Jedes Tool kostet Kontext-Tokens und erhöht die Chance, dass das Modell das falsche wählt.
### 6. Annotationen sagen dem Agenten, wie vorsichtig er sein muss
| Annotation | Bedeutung | Was der Agent damit tun kann |
|---|---|---|
| `readOnlyHint` | Das Tool liest nur, keine Seiteneffekte | Ohne Rückfrage aufrufen |
| `consequentialHint` | Folgenreiche oder unumkehrbare Aktion, etwa Buchung oder Zahlung | Vorher um Bestätigung bitten |
| `untrustedContentHint` | Die Ausgabe enthält Text von Nutzern oder Dritten | Den Inhalt als Daten behandeln, nicht als Anweisung |
| `debugging` (ab Chrome 156) | Das Tool ist für Entwicklerwerkzeuge gedacht | Vor Endnutzer-Agenten verbergen |
### 7. Die deklarative API bekommt echte Browser-Hooks
Deklarative Formulare bekommen Plattform-Features, die keine Bibliothek nachrüsten könnte. `SubmitEvent.agentInvoked` verrät deinem Submit-Handler, ob ein Mensch oder ein Agent das Formular abgeschickt hat, und mit `respondWith()` gibst du dem Modell ein Ergebnis zurück. Die Events `toolactivated` und `toolcancel` feuern, wenn ein Agent ein Formular ausfüllt oder abbricht. Mit den CSS-Pseudoklassen `:tool-form-active` und `:tool-submit-active` gestaltest du ein Formular, während ein Agent daran arbeitet, und `toolautosubmit` lässt den Agenten abschicken, ohne dass der Nutzer auf den Button klickt.
## WebMCP vs. MCP
Die häufigste Frage zu WebMCP lautet, ob es MCP ersetzt. Tut es nicht – und Googles eigener Guide nennt das gleich zu Beginn ein Missverständnis.
| | MCP | WebMCP |
|---|---|---|
| Wo das Tool läuft | Auf einem Server oder in einem lokalen Prozess | Im JavaScript der Seite |
| Lebensdauer | Dauerhaft | Flüchtig, an den Tab gebunden |
| Reichweite | Desktop, Mobil, Cloud, IDEs | Nur Browser-Agenten |
| Auth und Zustand | Auf dem Server nachgebaut | Die echte Session des Nutzers |
| Transport | JSON-RPC über stdio oder HTTP | Vom Browser vermittelte Aufrufe |
| Resources und Prompts | Ja | Nein – nur Tools |
Das Explainer-Dokument begründet klar, warum man nicht einfach MCP in den Browser gepackt hat: MCP fehlen native Web-Konzepte wie Origins, Browser-Berechtigungen, DOM-Integration und ein an den Tab gebundener Lebenszyklus, und eine Web-API an ein sich weiterentwickelndes Backend-Protokoll zu koppeln, würde die Abwärtskompatibilität gefährden. WebMCP teilt also das Vokabular von MCP – Tools, Schemas, Parameter –, ist aber eine eigenständige Web-API.
In der Praxis braucht man beides. Sollen Agenten deinen Dienst aus Claude Desktop, einer IDE oder einem Cloud-Workflow erreichen, ist das ein [MCP-Server](https://www.alekseialeinikov.com/de/blog/topics/ai/mcp-server-erklaert-selbst-bauen-und-sicher-betreiben-2026), und die Frage, welcher Nutzer welches Tool bekommt, gehört in ein [Gateway davor](https://www.alekseialeinikov.com/de/blog/topics/security/benutzerbezogene-zugriffskontrolle-mcp-tools-gateway-2026). Ist der Nutzer auf deiner Website und soll ein Agent bei dem helfen, was auf dem Bildschirm ist, ist das WebMCP.
## Meine Implementierung: fünf WebMCP-Tools im Produktivbetrieb
Jede Seite unter [/de/tools](https://www.alekseialeinikov.com/de/tools) auf dieser Website registriert fünf reine Lese-Tools, sobald der Browser WebMCP unterstützt:
| Tool | Was es macht | Live-Seite |
|---|---|---|
| `check_gcp_iam_policy` | Prüft eine Google-Cloud-IAM-Policy auf Least-Privilege-Probleme | [IAM Checker](https://www.alekseialeinikov.com/de/tools/iam-checker) |
| `recommend_gcp_compute` | Wählt Cloud Run, GKE, Compute Engine usw. für einen Workload | [Compute Selector](https://www.alekseialeinikov.com/de/tools/compute-selector) |
| `recommend_gcp_database` | Wählt Cloud SQL, AlloyDB, Spanner, Firestore usw. | [Database Selector](https://www.alekseialeinikov.com/de/tools/database-selector) |
| `explain_cron` | Erklärt einen Cron-Ausdruck und listet die nächsten Läufe in einer Zeitzone | [Cron Translator](https://www.alekseialeinikov.com/de/tools/cron-translator) |
| `convert_cron` | Übersetzt Cron-Syntax zwischen neun Plattformen | [Cron Translator](https://www.alekseialeinikov.com/de/tools/cron-translator) |
Alle fünf nutzen dieselben Engines wie die Oberfläche. Nichts geht an einen Server – eine IAM-Policy, die ein Agent übergibt, wird im Browser analysiert, genau wie eine, die ein Mensch einfügt.
### Laden: null Kosten für alle anderen
Die Browser der meisten Besucher haben kein WebMCP, also darf das Tool-Modul für sie nie geladen werden. Die Website nutzt den clientseitigen Router von Astro, deshalb muss der Loader Tools registrieren, wenn man nach `/tools` navigiert, und sie wieder entfernen, wenn man die Seite verlässt:
```js
let controller = null;
let registeredFor = '';
async function syncWebMcp() {
const onTools = /^\/(en|de)\/tools(\/|$)/.test(location.pathname);
const key = onTools ? document.documentElement.lang : '';
if (key === registeredFor) return;
controller?.abort(); // /tools verlassen oder Sprache gewechselt
controller = null;
registeredFor = '';
if (!onTools || !('modelContext' in document)) return;
const current = new AbortController();
controller = current;
registeredFor = key;
const { registerWebMcpTools } = await import('./webmcp-tools.js');
await registerWebMcpTools(current.signal);
}
document.addEventListener('astro:page-load', syncWebMcp);
```
Drei Details sind wichtig. Die Feature-Prüfung (`'modelContext' in document`) läuft vor dem dynamischen `import()`, Browser ohne Unterstützung laden also nichts herunter. Der `AbortController` meldet bei einem Routenwechsel alle Tools mit einem Aufruf ab. Und die Sprache ist Teil des Schlüssels: Wechselt man von `/en/tools` zu `/de/tools`, werden die Tools mit deutschen Ausgaben neu registriert.
### Die Schemas kommen aus den Inhalten der Oberfläche
Die beiden Selector-Tools nehmen dieselben Fragen entgegen, die das interaktive Quiz stellt. Statt das Schema von Hand zu schreiben, wird es aus der Fragenliste erzeugt, die auch die Oberfläche rendert:
```js
export function selectorSchema(kind) {
const properties = {};
for (const q of SELECTORS[kind].questions.en) {
properties[q.id] = {
type: 'string',
enum: q.options.map((o) => o.value),
description: `${q.label} ${q.options.map((o) => `${o.value} = ${o.label}`).join('; ')}`,
};
}
return { type: 'object', properties };
}
```
Kommt eine Frage ins Quiz, sieht der Agent sie beim nächsten Deploy. Schema und Oberfläche können nicht auseinanderlaufen, weil es nur eine Quelle gibt.
### Ausgabe: unter 1.500 Zeichen, mit Weg zurück
Googles Sicherheits-Guide empfiehlt etwa 1,5K Zeichen pro Tool-Ausgabe, 500 pro Tool-Beschreibung und 150 pro Parameterbeschreibung. Eine IAM-Policy mit vierzig Befunden würde das locker sprengen. Deshalb baut jedes Tool seine Antwort Zeile für Zeile auf und hört auf, sobald die nächste Zeile das Budget überschreiten würde:
```js
export const MAX_OUTPUT = 1500;
function fitLines(head, lines, footer) {
let out = head;
for (let i = 0; i < lines.length; i += 1) {
const rest = lines.length - i - 1;
const tail = rest ? `\n… and ${rest} more` : '';
if (`${out}\n${lines[i]}${tail}\n${footer}`.length > MAX_OUTPUT) {
return `${out}\n… and ${lines.length - i} more\n${footer}`;
}
out += `\n${lines[i]}`;
}
return `${out}\n${footer}`;
}
```
Die letzte Zeile ist immer ein Link auf den vollständigen interaktiven Bericht. So kann der Agent dem Nutzer das ganze Ergebnis geben statt eines abgeschnittenen.
### Fehler, die der Agent selbst beheben kann
Die WebMCP Best Practices raten, „streng im Code, locker im Schema“ zu validieren und Fehler zurückzugeben, mit denen das Modell arbeiten kann. Ein falscher Wert wirft keine Exception, sondern sagt dem Agenten genau, was er stattdessen schicken soll:
```text
Invalid value "h100" for hardware. Use one of: none, gpu, tpu.
```
### Das eine Tool mit `untrustedContentHint: true`
Vier Tools geben Text zurück, den ich geschrieben habe. `check_gcp_iam_policy` ist anders: Seine Befunde zitieren Rollennamen und Member-Strings aus der Policy, die der Nutzer übergeben hat. Eine Policy ist JSON, das jeder bearbeiten kann – ein Member-String könnte also eine Anweisung an das Modell enthalten. Nur dieses Tool ist mit `untrustedContentHint: true` markiert; alle fünf tragen `readOnlyHint: true` und `consequentialHint: false`.
### Das Origin-Trial-Token läuft ab
Das Token steckt als Meta-Tag im Head der Seite und ist an `https://www.alekseialeinikov.com` gebunden:
```html