# WebMCP erklärt: Wie Websites KI-Agenten Werkzeuge geben

> WebMCP lässt eine Seite dem KI-Agenten benannte, typisierte Funktionen reichen statt eines DOM zum Raten. Funktionsweise, Abgrenzung zu MCP und Browser-Automation, Sicherheitsmodell und Stand im Chrome-Origin-Trial.

- Quelle: https://www.agentifizierung.de/webmcp
- Übersicht: https://www.agentifizierung.de/llms.txt
- Volltext: https://www.agentifizierung.de/llms-full.txt

---

Agentenfähige Website

## WebMCP: Wie Websites KI-Agenten Werkzeuge geben

Von [Gorden Wübbe](https://www.agentifizierung.de/autoren/gorden-wuebbe) · Zuletzt aktualisiert: 28\. August 2026

**Kurz erklärt:** WebMCP ist eine Browser-Schnittstelle, mit der eine Seite einem KI-Agenten eine Liste benannter, typisierter Funktionen reicht – statt ihn aus Screenshots und HTML erraten zu lassen, wo er klicken soll. Jedes Werkzeug hat einen Namen, eine Beschreibung in natürlicher Sprache und ein JSON-Schema für seine Parameter. Der Agent ruft es im Namen des angemeldeten Nutzers auf, in dessen laufender Sitzung – ohne dass ein API-Schlüssel den Besitzer wechselt.

Inhalt

- [Was WebMCP ist](#definition)
- [Wie es technisch funktioniert](#funktionsweise)
- [Was WebMCP nicht ist](#nicht)
- [WebMCP, MCP, API oder Automation?](#abgrenzung)
- [Sicherheit und offene Fragen](#sicherheit)
- [Stand August 2026](#status)
- [Was Sie jetzt tun sollten](#praxis)
- [Häufige Fragen](#faq)

Agenten bedienen Websites heute so, wie ein Mensch es täte, nur schlechter: Sie machen ein Bildschirmfoto, suchen darin nach einem Feld, tippen hinein, klicken und schauen wieder nach, was passiert ist. Das ist langsam, teuer und bricht bei jedem Redesign. WebMCP dreht die Richtung um – die Seite sagt selbst, was sie kann.

### Was WebMCP ist

WebMCP – ausgeschrieben Web Model Context Protocol – erweitert das Dokument im Browser um die Eigenschaft `modelContext`. Über sie meldet eine Seite Werkzeuge an: aufrufbare Funktionen mit Namen, Beschreibung und Eingabeschema. Ein Agent, der die Seite offen hat, bekommt diese Liste und kann die Funktionen direkt aufrufen, statt die Oberfläche nachzuahmen.

Der Vorschlag stammt von Entwicklerinnen und Entwicklern bei Google und Microsoft und wird in der Web Machine Learning Community Group des W3C weiterentwickelt. Er borgt sich Vokabular und Muster beim Model Context Protocol (MCP), das dieselbe Idee für Server umsetzt – bleibt aber bewusst eine eigene, browser-eigene Schnittstelle.

Der wichtigste Unterschied liegt nicht in der Technik, sondern beim Zugang: Ein Werkzeug existiert nur, solange die Person, für die der Agent handelt, die Seite offen und sich angemeldet hat. Es wird kein neuer Schlüssel ausgestellt, nichts landet dauerhaft im Kontextfenster eines Modells, und der Entzug des Zugriffs heißt schlicht: ausloggen.

### Wie es technisch funktioniert

Es gibt zwei Wege, Werkzeuge bereitzustellen. Der programmatische registriert sie im JavaScript der Seite:

```
await document.modelContext.registerTool({
  name: "termin-verfuegbarkeit",
  description: "Prüft, welche Termine an einem Tag noch frei sind",
  inputSchema: {
    type: "object",
    properties: {
      datum: { type: "string", description: "Wunschtag im Format JJJJ-MM-TT" }
    },
    required: ["datum"]
  },
  annotations: { readOnlyHint: true },
  async execute({ datum }) {
    const slots = await ladeFreieSlots(datum);
    return {
      content: [{ type: "text", text: "Frei am " + datum + ": " + slots.join(", ") }]
    };
  }
});
```

Vier Dinge stehen darin, und alle vier sind für den Agenten entscheidend: der Name, an dem er das Werkzeug erkennt; die Beschreibung, die für ein Sprachmodell geschrieben ist und nicht für Ihre Entwicklerdokumentation; das JSON-Schema, das den Spielraum für erfundene Parameter schließt; und die Funktion, die tatsächlich etwas tut und ein strukturiertes Ergebnis zurückgibt. Die Registrierung nimmt zusätzlich ein `AbortSignal` entgegen, damit Single-Page-Anwendungen ihre Werkzeuge beim Seitenwechsel wieder abmelden können.

Der zweite Weg ist deklarativ: Der Browser leitet Werkzeuge aus Formularen ab, die ohnehin im Markup stehen. Wer saubere Formulare mit beschrifteten Feldern hat, bekommt hier einen Teil der Arbeit geschenkt – ein weiteres Argument dafür, dass gutes HTML die Vorstufe ist und nicht der Notnagel.

Ein Detail, über das derzeit jeder stolpert: Die Schnittstelle ist am 21. Juli 2026 von `navigator.modelContext` nach `document.modelContext` umgezogen, weil Werkzeuge zum Dokument gehören und nicht zum Browser – verschiedene Tabs können Verschiedenes können. Chrome 150 hat den alten Ort für überholt erklärt. Viele Anleitungen im Netz zeigen noch die alte Variante; wer beides bedienen will, kapselt den Zugriff einmal zentral:

```
function modelContext() {
  if ("modelContext" in document) return document.modelContext;
  if ("modelContext" in navigator) {
    console.warn("[webmcp] Fallback auf das veraltete navigator.modelContext");
    return navigator.modelContext;
  }
  return null;
}
```

### Was WebMCP nicht ist

Der Nutzen der Schnittstelle wird derzeit größer erzählt, als er ist. Vier Abgrenzungen ersparen teure Umwege:

- **Kein Ersatz für einen MCP-Server:** WebMCP-Werkzeuge existieren nur, solange die Seite im Browser offen ist. Alles, was nachts läuft, planmäßig synchronisiert oder von einem Partnersystem ohne angemeldeten Menschen aufgerufen wird, braucht weiterhin eine serverseitige Schnittstelle.
- **Kein Ersatz für erreichbare Inhalte:** Werkzeuge, die in einem JavaScript-Bundle stecken, helfen nichts, wenn der Agent die Seite gar nicht erst laden, rendern oder lesen kann. Die Reihenfolge bleibt: erreichbar, verständlich, dann bedienbar.
- **Kein Ersatz für sauberes HTML:** Jeder Agent ohne WebMCP-Unterstützung – und das sind derzeit die meisten – bedient weiterhin Ihre Formulare, Überschriften und Links. Semantisches Markup bleibt die Grundlage, WebMCP kommt obendrauf.
- **Keine Reparatur einer unklaren API:** Ein Werkzeug, das einen undokumentierten Endpunkt aufruft, erbt dessen Probleme. WebMCP macht bestehende Funktionen auffindbar, es macht sie nicht besser.

Zusammengefasst: WebMCP ist der letzte Schritt, nicht der erste. Ein Agent muss die Seite erreichen, verstehen und benutzen können – erst dann bringt eine Werkzeugliste etwas.

### WebMCP, MCP, API oder Automation?

Die Frage, die alle vier Ansätze sortiert, lautet: **Wer hält das Credential?** Daran hängen Sicherheit, Kosten und Betriebsaufwand.

Kriterium

Eigene API

MCP-Server

Browser-Automation

WebMCP

Wo es ausgeführt wird

Ihre Infrastruktur

Ihre Infrastruktur

Gesteuerter Browser

Die offene Seite des Nutzers

Wer das Credential hält

API-Schlüssel der Maschine

Token oder OAuth der Maschine

Hinterlegte Session

Die bestehende Anmeldung des Nutzers

Vorab auffindbar

Über die Spezifikation

Ja

Entfällt

Nein – erst beim Seitenaufruf

Übersteht ein Redesign

Ja

Ja

Bricht regelmäßig

Ja

Laufender Aufwand

Bereits vorhanden

Eigener Dienst nötig

Teuer je Aufruf

Gering je Aufruf, Pflege im Frontend

API und MCP-Server passen, wenn Maschinen unabhängig arbeiten: nächtliche Abgleiche, Überwachung, Partneranbindungen. Browser-Automation funktioniert überall, weil sie keine Mitwirkung der Seite braucht – dafür ist sie langsam, teuer und zerbricht am nächsten Relaunch. WebMCP passt für Wege, die ohnehin in der angemeldeten Sitzung stattfinden: suchen, vergleichen, konfigurieren, buchen. Und es hat eine klare Schwäche: Weil Werkzeuge erst mit der offenen Seite entstehen, kann kein Agent vorab wissen, dass es sie gibt.

### Sicherheit und offene Fragen

Der Sicherheitsgewinn ist real und liegt beim Credential. Es wird kein Token ausgestellt, keines wandert in ein Modell, keines kann aus einem Kontextfenster abfließen. Die Schnittstelle steht nur über HTTPS zur Verfügung, Werkzeuge sind standardmäßig auf ihren eigenen Origin beschränkt, und fremde Frames brauchen eine ausdrückliche Freigabe.

Ungelöst ist etwas anderes. Sobald ein Agent gleichzeitig private Daten lesen, fremde Inhalte verarbeiten und etwas nach außen senden kann, ergeben drei für sich harmlose Fähigkeiten zusammen ein Abflussrisiko. Beschreibungen und Rückgabewerte von Werkzeugen sind dabei ein eigener Angriffsweg: Ein Sprachmodell liest Anweisung und Nutzdaten im selben Textstrom. Wer nutzergenerierte Inhalte zurückgibt – Bewertungen, Kommentare, hochgeladene Texte –, liefert einem Angreifer den bequemsten Kanal.

Die Spezifikation kennt dafür Kennzeichnungen wie `readOnlyHint` für nur lesende Werkzeuge und `untrustedContentHint` für Rückgaben aus fremder Feder. Entscheidend ist, wie ernst man sie nimmt: **Es sind Hinweise an den Agenten, keine Zusicherungen des Browsers.** Ein als lesend markiertes Werkzeug kann trotzdem schreiben. Verhindert wird das nur durch Autorisierung auf dem Server – so, wie bei jeder anderen Schnittstelle auch.

Praktisch heißt das: lesende Werkzeuge zuerst; jede folgenreiche Aktion – Geld, Kündigung, Nachricht, Unumkehrbares – hinter eine sichtbare Bestätigung im eigenen Interface; Abfragen strikt auf die Sitzung eingrenzen statt auf durchzählbare Fremdschlüssel; und in Werkzeugbeschreibungen keine internen Hostnamen oder Geheimnisse. Für die Datenschutzprüfung im Haus ist das eine gute Nachricht: Ein klar begrenzter, lesender Umfang mit dokumentiertem Bedrohungsmodell ist prüfbar. Eine pauschale Freigabe „für Agenten“ ist es nicht.

### Stand August 2026

WebMCP ist kein verabschiedeter Standard, sondern ein Entwurf – ein Draft Community Group Report der W3C Web Machine Learning Community Group. In Chrome läuft seit Version 149 ein Origin Trial, davor war die Schnittstelle ab Chrome 146 nur hinter einem Flag erreichbar. ChatGPT auf dem Desktop wertet angebotene Werkzeuge inzwischen aus, Google hat Unterstützung in Gemini angekündigt, Firefox und Safari haben sich nicht festgelegt.

Für eine Planung im Mittelstand bedeutet das: Es lohnt sich, den Mechanismus zu verstehen und die Vorarbeiten zu leisten, die ohnehin nützen. Es lohnt sich nicht, einen Prozess darauf aufzubauen, dass jeder Kundenagent diese Schnittstelle kennt. Nichts an WebMCP zwingt heute zum Handeln – und das Fenster, in dem frühe Umsetzungen einen Vorsprung bedeuten, ist noch offen.

### Was Sie jetzt tun sollten

- **1\. Erreichbarkeit prüfen:** Liefert die Seite ihre Kernaussagen ohne JavaScript aus? Blockiert die robots.txt versehentlich Agenten oder Discovery-Dokumente? Ohne diese Basis bringt jede weitere Stufe nichts.
- **2\. Bestehende Schnittstelle dokumentieren:** Eine saubere OpenAPI-Beschreibung mit sprechenden operationId-Werten ist die Vorarbeit, aus der sich Werkzeuge später fast von selbst ableiten – und sie nützt heute schon jedem Integrationspartner.
- **3\. Drei bis zehn Kernaktionen benennen:** Nicht jede Funktion wird ein Werkzeug. Gesucht sind die Handlungen, wegen derer Menschen die Seite überhaupt öffnen: suchen, vergleichen, konfigurieren, Status abfragen, Termin buchen.
- **4\. Lesend anfangen:** Abfragende Werkzeuge liefern den größten Nutzen bei kleinstem Risiko. Alles, was Geld bewegt, kündigt, verschickt oder unumkehrbar ist, gehört hinter eine ausdrückliche Bestätigung im eigenen Interface.
- **5\. Auffindbarkeit herstellen:** Weil WebMCP-Werkzeuge erst mit der offenen Seite entstehen, kann kein Agent vorab damit planen. Ein Discovery-Dokument und eine gepflegte Sitemap schließen die Lücke.

Die ersten beiden Schritte zahlen sich unabhängig davon aus, ob WebMCP sich durchsetzt. Welche maschinenlesbaren Schnittstellen diese Website selbst anbietet – llms.txt, Markdown je Seite, Agent Card, OpenAPI –, steht unter [Maschinenlesbare Schnittstellen](https://www.agentifizierung.de/developers).

### Häufige Fragen

Was ist WebMCP in einem Satz?

WebMCP ist eine Browser-Schnittstelle, über die eine Website einem KI-Agenten eine Liste benannter, typisierter Funktionen übergibt, statt ihn aus Screenshots und HTML erraten zu lassen, wo er klicken muss.

Ist WebMCP bereits ein verabschiedeter Standard?

Nein. WebMCP wird in der Web Machine Learning Community Group des W3C entwickelt und liegt als Draft Community Group Report vor. In Chrome läuft ein Origin Trial; andere Browser haben sich noch nicht festgelegt. Für den produktiven Einsatz heißt das: zusätzlich anbieten, nicht darauf verlassen.

Brauche ich WebMCP, wenn ich schon eine API oder einen MCP-Server habe?

Es ersetzt beides nicht. Die entscheidende Frage ist, wer das Credential hält. Läuft die Aufgabe ohne angemeldeten Menschen – nachts, planmäßig, aus einem Partnersystem –, brauchen Sie weiterhin API oder MCP-Server. WebMCP deckt den Fall ab, dass ein Mensch angemeldet auf der Seite ist und sein Agent ihm dort etwas abnimmt.

Verhindert WebMCP Prompt Injection?

Nein. Beschreibungen und Rückgabewerte von Werkzeugen sind selbst ein Einfallstor: Sprachmodelle verarbeiten Anweisungen und Daten im selben Textstrom. WebMCP kennt dafür Kennzeichnungen wie readOnlyHint und untrustedContentHint, aber das sind Hinweise an den Agenten, keine Garantien des Browsers. Durchgesetzt werden Rechte weiterhin serverseitig.

Was ändert sich für die Suchmaschinenoptimierung?

WebMCP ist kein Rankingfaktor und ersetzt keine Inhalte. Es setzt dort an, wo klassische Optimierung aufhört: nicht beim Gefundenwerden, sondern beim Bedienen. Wer will, dass Agenten auf der Seite etwas erledigen statt sie nur zu zitieren, baut zuerst saubere Inhalte und Formulare und dann Werkzeuge.

Wie fange ich sinnvoll an?

Mit einem internen Werkzeug oder einer lesenden Funktion, die niemandem schaden kann, wenn ein Agent sie falsch aufruft. Danach lässt sich seriös beurteilen, ob die eigenen Prozesse überhaupt von agentischer Bedienung profitieren – und ob der Aufwand zur Nutzung passt.

### Quellen

- [webmcp-tool.com – Was WebMCP ist und was nicht](https://webmcp-tool.com/what-is-webmcp)
- [webmcp-tool.com – WebMCP im Vergleich zu MCP, APIs und Browser-Automation](https://webmcp-tool.com/webmcp/vs-mcp)
- [webmcp-tool.com – Das Sicherheitsmodell und die offenen Stellen](https://webmcp-tool.com/webmcp/security)
- [webmcp-tool.com – Umzug von navigator.modelContext zu document.modelContext](https://webmcp-tool.com/webmcp/migration)
- [W3C Web Machine Learning CG – WebMCP Explainer und Spezifikationsentwurf](https://github.com/webmachinelearning/webmcp)
- [Chrome for Developers – Origin Trial zu WebMCP](https://developer.chrome.com/blog/ai-webmcp-origin-trial)
- [Chrome for Developers – Sicherheitsüberlegungen für Agenten](https://developer.chrome.com/docs/agents/security)
- [InfoQ – WebMCP als Standardvorschlag im Chrome-Origin-Trial](https://www.infoq.com/news/2026/06/webmcp-web-agent-standard-chrome/)

Lohnt sich agentische Bedienung für Ihren Prozess?

Vor der Frage nach der Schnittstelle steht die Frage nach dem Prozess: Welcher Ablauf in Ihrem Haus wird oft genug wiederholt, ist klar genug beschrieben und hat einen Verantwortlichen, der entscheiden kann? Genau das klären wir im [Agentifizierungs-Check](https://www.agentifizierung.de/agentifizierungs-check).