← Wissensdatenbank

WebMCP — Agent-Interaktion im Browser

Was ist WebMCP?

WebMCP ist ein Draft-Vorschlag einer W3C Community Group, der KI-Agenten mit Websites über den Browser des Nutzers interagieren lässt statt über eine separate API. Sites annotieren bestehende HTML-Formulare mit Attributen, die sie als aufrufbare Tools deklarieren; der Browser exponiert diese Tools für einen Agenten über eine neue document.modelContext-API. Der Vorschlag wird von Google und Microsoft getragen und ist seit Chrome 149 (Juni 2026) als Origin Trial in Chrome verfügbar.

Der Name ist ein bewusstes Echo auf MCP, Anthropics Model Context Protocol, aber die beiden sind eigenständige Spezifikationen, die verschiedene Probleme lösen. MCP definiert ein JSON-RPC-Protokoll, mit dem ein Agent Tools auf einem Server aufruft. WebMCP definiert eine Browser-API, mit der ein Agent Tools aufruft, die bereits als Formulare auf einer Seite existieren. Sie teilen das „Tools“-Konzept und sonst wenig.

Warum WebMCP wichtig ist

Der traditionelle Weg für Agent-Website-Integration: Die Site veröffentlicht eine API (OpenAPI) oder einen MCP-Server, der Agent authentifiziert sich separat, und die Aufrufe laufen über einen Backchannel. Das funktioniert für First-Party-Agent-Integrationen, bricht aber beim Long Tail von Websites zusammen, die wertvolle Funktionalität haben, aber kein API-Team, um eine parallele Oberfläche zu bauen.

WebMCP geht den umgekehrten Weg: Die Site hat bereits ein Formular für die Sache, der Nutzer ist bereits eingeloggt, der Browser hat bereits die Session. Warum eine parallele API bauen? Annotiere das bestehende Formular mit ein paar Attributen, und ein Agent im Browser kann es direkt aufrufen — und erbt die Auth des Nutzers, die CSRF-Schutzmechanismen der Site und das Berechtigungsmodell des Browsers gratis dazu.

Die Anwendungsfälle sind vor allem Agent-Flows mit dem Nutzer in der Schleife: ein Agent, der im Auftrag eines eingeloggten Nutzers auf der gerade besuchten Site handelt. Einen Flug buchen, ein Support-Ticket erstellen, einen Kommentar posten — überall dort, wo normalerweise ein Formular eine menschliche Eingabe entgegennimmt.

Wie sich WebMCP von MCP unterscheidet

	MCP	WebMCP
Wer ruft wen auf	Agent → Server	Agent → Browser → Server
Wo der Agent läuft	Außerhalb des Browsers	Im oder neben dem Browser
Authentifizierung	OAuth 2.1 / API-Keys	Die bestehende Browser-Session des Nutzers
Transport	JSON-RPC über HTTP/SSE	Browser-interne API (document.modelContext)
Was du auf der Site baust	Einen dedizierten MCP-Endpoint	Attribut-Annotationen an bestehenden HTML-Formularen
Verbindungsdauer	Persistent über Sessions hinweg	Endet, wenn der Tab schließt
Discovery	MCP-Registry / well-known	DOM-Scan + /.well-known/webmcp.json-Manifest

Die Architekturen sind nahezu Gegensätze. MCP gibt externen Agenten eine stabile Backend-Schnittstelle; WebMCP gibt In-Browser-Agenten Zugriff auf das bestehende Frontend. Eine Site kann beides veröffentlichen: MCP für Headless-Agent-Integrationen, WebMCP für Browser-Flows mit dem Nutzer in der Schleife.

So funktioniert WebMCP

Es gibt zwei zusammenwirkende Teile: DOM-Annotationen (pro Seite) und ein optionales Manifest (pro Site).

1. Annotierte Formulare. Eine Site markiert ein beliebiges HTML-Formular mit drei Custom-Attributen als agent-aufrufbar:

<form tool-name="search-products" tool-description="Search the catalog by keyword">
  <input type="text" name="q" tool-param-description="Search query, e.g. 'red shoes'">
  <button type="submit">Search</button>
</form>

Die browserseitige WebMCP-Runtime scannt das DOM nach tool-name-Elementen, baut eine Tool-Liste und exponiert sie für den Agenten. Wenn der Agent search-products mit q: "running shoes" aufruft, füllt der Browser das Formular aus und sendet es im Auftrag des Agenten ab — über die Session des Nutzers.

2. Das Manifest. Eine Site kann /.well-known/webmcp.json veröffentlichen und darin Tools deklarieren, die nicht auf jeder Seite sichtbar sind (oder mehrstufige Abläufe umfassen). Das Manifest-Format spiegelt MCPs Tool-Deskriptoren:

{
  "spec": "webmcp/0.1",
  "tools": [
    {
      "name": "search-products",
      "description": "Search the product catalog",
      "url": "/search",
      "method": "GET",
      "parameters": [
        {
          "name": "q",
          "type": "string",
          "description": "Search query"
        }
      ]
    }
  ]
}

Das Manifest gibt Agenten einen Discovery-Pfad, der nicht vom DOM-Scraping abhängt. AgentGrade prüft beides: ein vorhandenes /.well-known/webmcp.json und tool-name-Attribute auf der Homepage.

WebMCP vs. andere Agent-Interop-Schichten

Spec	Wo der Agent lebt	Was exponiert wird	Auth
WebMCP	Im Browser	Annotierte HTML-Formulare	Session des Nutzers
MCP	Außerhalb des Browsers	JSON-RPC-Tools auf einem Server	OAuth / API-Keys
A2A	Überall	Ein ganzer Agent mit benannten Skills	Auth auf Agent-Ebene
OpenAPI	Überall	REST-Endpoints mit Schemas	Schema pro Endpoint
SKILL.md	Überall	Prosa-Playbook	Entfällt

WebMCP ist die einzige dieser Schichten, die im Browser des Nutzers läuft. Die anderen gehen alle davon aus, dass der Agent auf einem Server oder in einem Chat-Client sitzt; WebMCP geht davon aus, dass der Agent der User Agent des Nutzers ist — mit allem Vertrauen und aller Autorität, die das impliziert.

Aktueller Status

WebMCP ist ein Draft Community Group Report der W3C Web Machine Learning Community Group. Stand Mitte 2026:

• Die Spezifikation ist unter webmachinelearning.github.io/webmcp veröffentlicht.
• Chromes Implementierung ist im Origin Trial (Anmeldungen seit Chrome 149); Microsoft Edge betreibt einen eigenen Opt-in-Origin-Trial. Keiner liefert standardmäßig aus.
• Es ist in keinem Produktions-Browser standardmäßig aktiv. Firefox und Safari haben keine Pläne angekündigt.
• Die Spezifikation wird sich voraussichtlich ändern, bevor sie den W3C-Working-Draft-Status erreicht.

Weil die Nutzerseite von Browser-Support abhängt, sind Sites, die WebMCP heute ausliefern, früh dran — sie wetten darauf, dass die Spezifikation sich stabilisiert und Browser ausliefern. Die Kosten des Frühseins sind niedrig (ein paar HTML-Attribute); der Vorteil ist, für die erste Welle von In-Browser-Agenten aufrufbar zu sein, die die Spezifikation übernehmen.

Wer hinter WebMCP steht

• Google — das Chrome-Team hat den Vorschlag veröffentlicht und liefert den Prototyp.
• Microsoft — Co-Editor der Spezifikation; Mitveröffentlicher eines Chrome-Developer-Blog-Posts, der das Verhältnis zwischen MCP und WebMCP erklärt.
• W3C Web Machine Learning Community Group — das Governance-Gremium.

Auffällig abwesend: Anthropic (der MCP-Autor) und OpenAI. Die Spezifikation ist als Ergänzung zu MCP positioniert, nicht als Konkurrenz, aber die Namensüberschneidung hat für einige Verwirrung gesorgt.

So fügst du WebMCP zu deiner Site hinzu

1. Wähle die Formulare, die zählen. Annotiere nicht jedes Formular der Site. Wähle die 1-3 wertvollsten agent-aufrufbaren Aktionen (Suche, Absenden, Abonnieren).
2. Füge die Attribute hinzu. tool-name am <form>-Element, tool-description am Formular, tool-param-description an jedem <input>.
3. Nutze Kleinbuchstaben mit Bindestrichen. search-products, nicht searchProducts.
4. Schreibe Beschreibungen für einen Agenten, nicht für einen Menschen. Beginne mit dem Verb. Sei konkret beim Parametertyp (z. B. „Search query string, 1-200 chars“ statt nur „search“).
5. Veröffentliche das Manifest. /.well-known/webmcp.json mit denselben Tools. Das ist der Discovery-Pfad für Agenten, die das DOM nicht scannen.
6. Teste über den Chrome Origin Trial (oder Edges Origin Trial) mit einem registrierten Token.

Häufige Fehler, die Scanner melden

• Kein Manifest — /.well-known/webmcp.json liefert 404. Der Check ist informativ; die Site kann trotzdem Tools auf Formularebene exponieren.
• Manifest liefert HTML — SPA-Catch-all-Routen geben die Homepage statt der JSON-Datei zurück.
• Formular-Annotationen ohne Beschreibungen — tool-name ist gesetzt, aber tool-description fehlt, sodass Agenten nicht erkennen, was das Formular tut.
• Ungültiger Tool-Name — Großbuchstaben, Unterstriche oder Sonderzeichen in tool-name.
• Annotationen an Nicht-Formular-Elementen — nur <form>-Elemente sollten tool-name tragen.

Häufig gestellte Fragen

Ist WebMCP ein Fork von MCP?

Nein. Es sind separate Spezifikationen von separaten Arbeitsgruppen mit separaten Architekturen. Sie teilen das „Tools“-Konzept (eine benannte, parametrisierte Aktion, die ein Agent aufrufen kann), aber Protokolle, Transporte und Vertrauensmodelle sind völlig verschieden. Die Namensgebung ist unglücklich.

Funktioniert Chromes WebMCP in Firefox oder Safari?

Derzeit nicht. Firefox und Safari haben die Spezifikation nicht implementiert. Cross-Browser-Support hängt davon ab, dass die Spezifikation über den Draft-Status hinaus reift — ein mehrjähriger Prozess.

Sollte ich WebMCP hinzufügen, wenn ich schon MCP habe?

Ja, wenn dein Service eine Website mit Formularen hat, die Nutzer heute ausfüllen. Beide adressieren verschiedene Agent-Kontexte: Server-seitige Agenten nutzen MCP; Browser-Agenten mit dem Nutzer in der Schleife nutzen WebMCP. Sites mit beidem lassen Agenten die passende Oberfläche wählen.

Bestraft AgentGrade Sites ohne WebMCP?

Nein. WebMCP ist ein informativer Check. Der Score wird für sein Fehlen nicht bestraft. Ist es vorhanden, ist es ein positives Signal.

Ist WebMCP sicher?

Das Sicherheitsmodell erbt vom Browser: Same-Origin-Durchsetzung, die bestehende Session des Nutzers, CSRF-Schutz. Ein Agent kann nur Tools aufrufen, die der Nutzer auf derselben Seite auch manuell aufrufen könnte. Es gibt keine Eskalationsfläche über das hinaus, was der Nutzer ohnehin hat. Das Risiko ist, dass der Agent im Auftrag des Nutzers handelt, ohne dass der Nutzer versteht, was passiert — ein UX-Problem, kein Problem der Sicherheitsgrenze.

Was ersetzt /.well-known/webmcp.json, wenn ich meine Formulare in einem iframe hoste?

Es gelten Same-Origin-Regeln: Ein Agent auf der Elternseite kann Formular-Tools in Same-Origin-iframes aufrufen. Cross-Origin-iframes sind isoliert. Das Manifest sollte auf dem Origin des iframes liegen.

Funktioniert WebMCP mit Single-Page-Apps?

Ja, aber die Formulare müssen zum Zeitpunkt des Agent-Scans im DOM vorhanden sein. SPAs, die Formulare erst bei Nutzerinteraktion hydrieren, müssen sie womöglich stattdessen im Manifest deklarieren.

Wann kommt WebMCP in das stabile Chrome?

Kein öffentlicher Zeitplan. Die Spezifikation ist ein Draft; der Produktions-Rollout hängt von Spezifikationsstabilität, Security-Review und nachgewiesener Entwickler-Adoption ab.

Reifegrad der Spezifikation

Draft, im Origin Trial. WebMCP ist ein Draft einer W3C Community Group (nicht auf dem W3C-Standards-Track). Chrome hat mit Chrome 149 (Juni 2026) einen Origin Trial geöffnet, und Edge betreibt einen eigenen Opt-in-Trial; noch liefert nichts standardmäßig aus, und die API-Oberfläche ist weiter in Bewegung — Chrome hat navigator.modelContext in Chrome 150 zugunsten von document.modelContext als veraltet markiert. Beachte, dass das /.well-known/webmcp.json-Manifest eine Community-Konvention ist, nicht Teil des Drafts — die Spezifikation definiert nur die In-Page-API. Die Spezifikation kann sich ändern. Die Adoption ist früh — Formulare zu annotieren ist eine günstige Versicherung für Sites, die bereit sein wollen, wenn produktiver Browser-Support ankommt.

Mehr erfahren

• WebMCP specification — der W3C-Draft
• WebMCP GitHub repository — Vorschläge und Diskussionen
• Chrome: When to use WebMCP and MCP — die offizielle Einordnung
• MCP — das serverseitige Gegenstück
• A2A — Agent-to-Agent-Protokoll

Verwandt: Was ist KI-Agent-Readiness?