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, 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 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

Warum Websites WebMCP brauchen

Ein Agent, der heute eine Website nutzen will, hat zwei Möglichkeiten. Bietet der Dienst einen MCP-Server oder eine API an, spricht der Agent direkt mit dem Backend und lässt die Website links liegen. Wenn nicht, greift er auf Aktuierung zurück: Er simuliert Mausklicks und Tastatureingaben anhand von Screenshots, DOM und Accessibility Tree.

Aktuierung ist der fragile Weg. Jeder Schritt ist eine Chance, ein Label falsch zu lesen, das falsche Element zu treffen oder zu handeln, bevor die Seite fertig gerendert ist – und ein Redesign kann einen Agenten zerlegen, der gestern noch funktioniert hat. Das WebMCP-Explainer-Dokument formuliert das Ziel klar: Agenten sollen über „klar definierte clientseitige Tools statt über brüchige UI-Aktuierung“ mit Websites arbeiten.

Hier dieselbe Frage an meinen Cron Translator, einmal auf jede Art:

Die rechte Seite ist kein Mock-up. Aufruf und Antwort stammen von dem Tool, das auf dieser Website läuft.

WebMCP ersetzt weder die Oberfläche noch die Backend-Integration. Beides steht im Explainer ausdrücklich unter den Nicht-Zielen. Es kommt ein dritter Weg dazu, auf dem Nutzer, Seite und Agent am selben Ort bleiben: Der Agent arbeitet über die Seite, und die Seite aktualisiert sich dabei sichtbar.

So funktioniert WebMCP

Ein WebMCP-Tool besteht aus vier Teilen, und wer schon einen MCP-Server gebaut hat, erkennt sie sofort:

const controller = new AbortController();

await document.modelContext.registerTool(
  {
    name: 'explain_cron',
    description: 'Explain a cron expression in plain language and list its next runs in a time zone.',
    inputSchema: {
      type: 'object',
      properties: {
        expression: { type: 'string', description: 'Cron expression, e.g. "30 2 * * 1-5".' },
        timezone: { type: 'string', description: 'IANA time zone, e.g. Europe/Berlin. Default UTC.' },
      },
      required: ['expression'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ expression, timezone }) => explainCron(expression, timezone),
  },
  { signal: controller.signal },
);

// Später: controller.abort() meldet das Tool wieder ab.

• name und description liest das Modell, um zu entscheiden, ob das Tool zur Anfrage des Nutzers passt.
• inputSchema ist ein JSON Schema für die Argumente. Der Agent füllt es aus; du musst keinen Freitext parsen.
• execute() ist ganz normales JavaScript der Seite. Es kann dieselben Funktionen nutzen wie deine Oberfläche, das DOM aktualisieren und Text oder JSON zurückgeben.
• annotations sind optionale Hinweise zu Seiteneffekten und Vertrauen – dazu gleich mehr.

Für einfache Formulare gibt es eine deklarative API, die ganz ohne JavaScript auskommt:

<form toolname="createSupportRequest"
      tooldescription="Submits a request for customer support."
      action="/support">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" required>
  <button type="submit">Send</button>
</form>

Chrome macht aus den Formularfeldern ein JSON Schema und nutzt das <label> 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, 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

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.

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, und die Frage, welcher Nutzer welches Tool bekommt, gehört in ein Gateway davor. 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 auf dieser Website registriert fünf reine Lese-Tools, sobald der Browser WebMCP unterstützt:

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:

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:

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:

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:

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:

<meta http-equiv="origin-trial" content="…token…">

Meins läuft am 17. November 2026 ab, und eine API zum Verlängern gibt es nicht. Ein wöchentlicher CI-Job prüft das Ablaufdatum und schlägt 21 Tage vorher fehl, sodass GitHub mir rechtzeitig eine Mail schickt. Ein abgelaufenes Token macht nichts kaputt – WebMCP schaltet sich einfach ab –, aber die Tools würden unbemerkt verschwinden.

Agent-Aufrufe messen

Jedes execute() sendet ein Analytics-Event mit tool_action: 'agent_call', getrennt von dem Event, das ein Mensch in der Oberfläche auslöst. Drei Tage nach dem Start steht der Zähler bei null. Das überrascht nicht: WebMCP ist noch ein Origin Trial, und ein Agent muss mit dem Tab verbunden sein, bevor irgendetwas ein Tool aufruft. Der Sinn, jetzt live zu gehen: bereit und messbar sein, wenn sich das ändert.

Selbst ausprobieren

1. In Chrome chrome://flags/#enable-webmcp-testing öffnen, aktivieren und neu starten.
2. Die Extension Model Context Tool Inspector installieren.
3. /de/tools/cron-translator öffnen und die Extension starten. Sie listet die fünf Tools mit ihren Schemas.
4. explain_cron mit {"expression": "30 2 * * 1-5", "timezone": "Europe/Berlin"} aufrufen – oder eine Frage in normaler Sprache eintippen und den Agenten der Extension das Tool wählen lassen.

Die Extension zeigt auch genau, was deine eigenen Tools zurückgeben. So prüfst du am schnellsten, ob Beschreibungen und Ausgaben für ein Modell gut lesbar sind.

WebMCP und Sicherheit

WebMCP schränkt ein, wer deine Tools sieht, macht einen Agenten aber nicht sicher. Googles Sicherheits-Guide sagt das deutlich: Modelle arbeiten probabilistisch, es gibt reproduzierbare Prompt-Injection-Angriffe auf Agenten, und Sicherheit innerhalb eines Large Language Models lässt sich nicht garantieren.

Was du als Betreiber der Website in der Hand hast:

• Freigabe. Standardmäßig sehen nur deine Seite, Frames derselben Origin und eingebaute Browser-Agenten die Tools. Nimm Origins nur dann in exposedTo auf, wenn du dieselben Daten auch direkt mit dieser Website teilen würdest.
• Annotationen. consequentialHint: true für alles, was Geld ausgibt, Nachrichten verschickt oder Daten löscht; untrustedContentHint: true für alles, was Text zurückgibt, den du nicht selbst geschrieben hast.
• Validierung. Behandle jeden execute()-Aufruf wie eine API-Anfrage eines nicht vertrauenswürdigen Clients. Das Schema ist ein Hinweis an das Modell, keine Garantie.
• Extensions. Eine Chrome-Extension mit Host-Berechtigungen kann deine WebMCP-Tools aufrufen – aber sie konnte auch vorher schon beliebiges JavaScript auf deiner Seite ausführen. WebMCP öffnet da kein neues Loch, es macht den vorgesehenen Weg sauberer.

Wer über Agenten nachdenkt, die auf echten Systemen handeln: Was passierte, als autonome KI-Agenten eine Regierungswebsite angriffen, ist eine gute Erinnerung daran, warum die Schutzmechanismen in deinen Code gehören.

Solltest du WebMCP jetzt einbauen?

Jetzt einbauen, wenn:

• deine Website Aufgaben hat, nicht nur Inhalte – Suche, Filter, Konfiguratoren, Formulare, Rechner, Dashboards;
• die Logik ohnehin im Browser läuft und Tools größtenteils Wrapper um vorhandene Funktionen sind;
• du die ersten Tools nur lesend halten und schreibende Aktionen später mit consequentialHint nachziehen kannst.

Abwarten, wenn:

• deine Seiten vor allem Artikel sind – die lesen Agenten heute schon gut, und eine llms.txt bringt mehr;
• deine wichtigsten Aktionen serverseitigen Zustand brauchen, den die Seite nicht hat – das ist Aufgabe eines MCP-Servers;
• du nicht zusagen kannst, alle paar Monate ein Origin-Trial-Token zu erneuern.

Weil das Ganze hinter einer Feature-Prüfung steckt, kostet es Nutzer ohne WebMCP nichts. Die eigentliche Arbeit ist gutes Tool-Design: kurze Beschreibungen, klare Schemas und Ausgaben, mit denen ein Modell etwas anfangen kann.

Fazit

WebMCP macht aus einer Website etwas, das ein Agent aufrufen kann, statt es entziffern zu müssen. Die Seite deklariert ihre Tools, Chrome führt die Registry, prüft die Schranken und führt dein execute() in der Session des Nutzers aus, und der Agent bekommt eine typisierte, kurze Antwort statt eines Screenshots zum Deuten.

Es ist früh: ein Origin Trial in Chrome und Edge, ein Desktop-Assistent und bisher null Agent-Aufrufe in meiner eigenen Analytics. Aber die API ist klein, die Kosten für alle anderen sind null, und die Tools im Tools-Bereich dieser Website haben weniger Code gebraucht als die Oberfläche drumherum. Wenn deine Website Aufgaben hat und die Logik schon im Browser läuft, lohnt es sich, jetzt ein einziges Lese-Tool live zu schalten und zu schauen, was es aufruft.