WebMCP vs. MCP: Was ist der Unterschied?

MCP ist ein Protokoll für den Betrieb eines Servers, der Ihre Tools KI-Agenten von überall aus zugänglich macht. WebMCP ist ein vorgeschlagener Webstandard, mit dem eine Webseite festlegen kann, welche Aktionen ein Agent auf dieser Seite ausführen darf, solange der Nutzer sie geöffnet hat.

Wenn Sie bereits einen MCP-Server gebaut haben, legt der Name „WebMCP“ nahe, es handle sich um dasselbe Protokoll, nur in den Browser verlagert. Das ist nicht der Fall. Der Unterschied entscheidet darüber, wo Ihr agentenseitiger Code liegt, unter welcher Identität er läuft und ob Sie sich schon jetzt darauf verlassen können.

Dieser Artikel vergleicht beide Ansätze hinsichtlich Laufzeitumgebung, Identität, Lebenszyklus und Discovery. Anschließend ordnet er jeden Ansatz einem Produkttyp zu und gibt eine nüchterne Einschätzung zum aktuellen Stand von WebMCP.

Was ist der Unterschied zwischen WebMCP und MCP in einem Satz?

MCP ist ein Server, den Sie betreiben, damit ein Agent Ihre Tools aufrufen kann. Mit WebMCP legt Ihre Seite fest, was ein Agent auf der Seite tun kann, auf der er sich bereits befindet. Das Model Context Protocol ist ein offener Standard, um KI-Anwendungen mit externen Daten, Tools und Workflows zu verbinden, und es spielt dabei keine Rolle, ob der Agent in einem Browser läuft. Chromes Leitfaden dazu, wann WebMCP und wann MCP eingesetzt werden sollte, bezeichnet WebMCP als vorgeschlagenen Browserstandard, der aus zwei APIs besteht. Diese APIs erreichen nur den im Browser integrierten Agenten, und der Browser leitet Nachrichten zwischen diesem Agenten und Ihrer Website weiter. Hintergrundinformationen zu Browsern mit eigenem Agenten finden Sie in unserer Einführung in agentische Browser. Chrome bezeichnet WebMCP als „MCP-inspiriert“. Es ist eine an MCP angelehnte Browser-API, kein in JavaScript neu geschriebenes MCP.

Wer betreibt was bei MCP und WebMCP?

Ein MCP-Server ist ein eigenständiger Prozess mit eigenem Deployment, eigener Authentifizierung und eigener Verfügbarkeit. WebMCP fügt keinen neuen Prozess hinzu: Es läuft innerhalb des geöffneten Tabs.

Mit MCP betreiben Sie einen Dienst, mit dem sich Agenten auf Desktop-, Mobil-, Cloud- oder Web-Clients jederzeit verbinden können. Diese Reichweite hat ihren Preis. Sie hosten den Server, versionieren ihn, überwachen ihn und entscheiden, wie jeder Aufrufer authentifiziert wird. Der Entwicklerleitfaden zum MCP-Ökosystem erläutert, wie Clients, Server und das Protokoll zusammenspielen.

Bei WebMCP werden die Tool-Definitionen als Teil Ihres Frontends ausgeliefert. Es muss nichts zusätzlich deployt werden, aber die Tools sind an den Tab gebunden. Jedes WebMCP-Tool verschwindet zusammen mit dem Tab, der es registriert hat. Navigiert der Nutzer weg oder schließt er den Tab, verliert der Agent den Zugriff auf dieses Tool.

Identität: Der Agent handelt als angemeldeter Nutzer

Da WebMCP-Tools innerhalb der Seite ausgeführt werden, die der Nutzer bereits geöffnet hat, arbeitet ein Agent, der sie verwendet, innerhalb der bestehenden Session, der Cookies und der Berechtigungen dieses Nutzers. Er verfügt über keine separaten Zugangsdaten für Ihre Website. Chrome weist darauf hin, dass WebMCP die aktuellen Session-Daten, Cookies und das DOM der Seite nutzen kann – nichts davon existiert außerhalb eines geöffneten Tabs. Daraus folgt, dass die Netzwerkanfragen eines Tools mit der Session gesendet werden, die die Seite ohnehin schon hat.

Ein MCP-Server steht vor einem anderen Problem. Als eigenständiger Dienst muss er selbst ermitteln, wer ihn aufruft und welche Aktionen dieser Aufrufer ausführen darf. Das bedeutet in der Regel, Zugangsdaten für den Agenten oder den von ihm vertretenen Nutzer auszustellen und zu prüfen. WebMCP überspringt diesen Schritt, da es die Session des Nutzers nie verlässt. Sie müssen weder API-Schlüssel bereitstellen noch Service-Accounts einrichten oder eine separate Autorisierungsschicht für den Agenten aufbauen.

Die sessionbasierte Identität von WebMCP hat jedoch ihren Preis. Aus Sicht der Seite ist ein WebMCP-Tool-Aufruf eine Aktion, die als angemeldeter Nutzer ausgeführt wird. Sofern Sie keine Unterscheidung explizit vorsehen, kann Ihr Code einen Agentenaufruf nicht von einem Klick unterscheiden. Daraus ergeben sich drei Best Practices:

• Geben Sie jedem Tool nur den Handlungsspielraum, den der Nutzer ohnehin bereits in der UI hätte.
• Verlangen Sie bei sensiblen Aktionen eine Bestätigung. Laut der WebMCP-Übersicht kann ein Tool, das etwas Sensibles ausführt, etwa einen Kauf, dem Nutzer vorher einen Bestätigungsdialog anzeigen.
• Verlassen Sie sich auf die Schutzmechanismen der Plattform. WebMCP läuft nur in origin-isolierten Dokumenten und wird durch die tools-Permissions-Policy gesteuert. Die Policy hat den Standardwert self, sodass einem Cross-Origin-iframe der Zugriff explizit gewährt werden muss.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

Fehlt dem iframe dieses Attribut, blockiert der Standardwert self die Tool-Registrierung in diesem Cross-Origin-Frame. Die Chrome-Dokumentation weist außerdem darauf hin, dass die WebMCP-APIs in jedem Dokument deaktiviert sind, das document.domain aktiviert, beispielsweise über den Header Origin-Agent-Cluster: ?0.

WebMCP und MCP im direkten Vergleich

Der zentrale Unterschied zwischen MCP und WebMCP: Auf der einen Seite stehen Persistenz und Reichweite, auf der anderen Seitenkontext und Nutzer-Session.

Die ersten fünf Zeilen basieren auf Chromes Vergleich von WebMCP und MCP.

Wann sollten Sie MCP oder WebMCP verwenden?

Verwenden Sie MCP für Aufgaben, die auf einem Server ohne UI ablaufen, und WebMCP für Aufgaben, die auf einer Seite mit einem aktiven Nutzer stattfinden.

• Backend-Dienst, Hintergrundjobs oder Datenzugriff ohne UI: MCP. WebMCP benötigt eine geöffnete Seite, und laut Chromes Übersicht ist es in erster Linie für eine Person konzipiert, die in einem lokalen Browser arbeitet, nicht für Headless-Ausführungen. Ein guter Einstieg ist der Artikel So bauen Sie einen MCP-Server.
• Web-App mit angemeldetem Nutzer: WebMCP. Setzen Sie es für Aktionen auf der aktuellen Seite ein, etwa das Ausfüllen eines komplexen Formulars oder die Datumsauswahl in einem Buchungs-Widget, wo die Session des Nutzers und der Seitenzustand eine Rolle spielen.
• Beides. Viele Produkte werden beides benötigen. MCP übernimmt die zentrale Geschäftslogik und die Daten, WebMCP deckt Aktionen innerhalb des Tabs ab. Wenn Sie bereits eine HTTP-API haben, ist es naheliegend, diese API über MCP für LLMs verfügbar zu machen – das ist die serverseitige Hälfte. Für die Browserseite lesen Sie unseren Begleitartikel Die Aktionen Ihrer Website mit WebMCP für KI-Agenten verfügbar machen.

Ersetzt WebMCP das MCP?

Nein. Chrome stellt klar, dass WebMCP MCP weder erweitert noch ersetzt. Es ist für den Browser konzipiert und verzichtet auf serverseitige Konzepte wie Resources. Zudem ist es von einer Seite abhängig. Seine Tools können nur durch den Besuch der Website gefunden werden und verschwinden, sobald der Tab geschlossen wird. Viele Agentenaufgaben berühren überhaupt keine Webseite: geplante Jobs, IDE-Assistenten, Datenpipelines und Agenten, die in der Cloud laufen. Für diese Aufgaben ist weiterhin ein MCP-Server erforderlich.

Wie ausgereift ist WebMCP?

WebMCP ist experimentell. Es ist über einen Chrome Origin Trial ab Chrome 149 sowie lokal über das Flag chrome://flags/#enable-webmcp-testing verfügbar, und Chrome weist darauf hin, dass die API noch diskutiert wird und sich ändern kann. Origin Trials laufen über einen festgelegten Zeitraum, können mit Nutzungsbeschränkungen verbunden sein und dienen dazu, Feedback zu sammeln, das die finale API prägt. Die WebMCP-Spezifikation ist ein Berichtsentwurf der W3C Web Machine Learning Community Group. Sie ist kein W3C-Standard und befindet sich nicht im W3C Standards Track. Die Chrome-Dokumentation bezieht sich ausschließlich auf die Chrome-Implementierung. Gehen Sie daher nicht von einer Unterstützung in anderen Browsern oder Agent-Hosts aus, solange deren eigene Dokumentation dies nicht bestätigt. Verfolgen Sie WebMCP auf Chrome Status, um über Änderungen an Meilensteinen informiert zu bleiben. Chrome weist außerdem darauf hin, dass WebMCP als Progressive Enhancement hinzugefügt werden kann. Bauen Sie es genau so ein, damit Ihre UI unabhängig davon gleich funktioniert, ob ein Agent die Tools sehen kann oder nicht.

Die Wahl zwischen beiden

MCP und WebMCP beantworten unterschiedliche Fragen. MCP macht Ihre Funktionen für jeden Agenten jederzeit erreichbar. WebMCP macht die Seite, auf der sich ein Nutzer befindet, für den Agenten in seinem Browser nutzbar – unter der eigenen Session des Nutzers. Als nächsten Schritt sollten Sie die Aktionen auflisten, die Ihr Produkt bereitstellt, und sie zuordnen: Headless-Operationen gehören auf einen MCP-Server, sessiongebundene Seitenaktionen sind Kandidaten für WebMCP im Rahmen des Origin Trials. Halten Sie die WebMCP-Schicht schlank, da sich die API noch ändern kann.

FAQs

Wie aktiviere ich WebMCP für echte Besucher und nicht nur für meinen eigenen Browser?

Registrieren Sie Ihren Origin in der Chrome Origin Trials Console und generieren Sie ein WebMCP-Token. Liefern Sie es auf jeder Seite aus, die Tools registriert, entweder in einem Origin-Trial-Meta-Tag oder in einem Origin-Trial-HTTP-Response-Header. Tokens gelten pro Origin. Ohne Token sehen Besucher mit Standard-Chrome Ihre Tools nie, da das lokale Test-Flag nur den Browser betrifft, in dem Sie es aktivieren. Der Trial startete mit Chrome 149 und sollte ursprünglich bis Chrome 156 laufen. Google hat eine Verlängerung bis Chrome 162 beantragt, prüfen Sie daher das Enddatum Ihres Tokens in der Origin Trials Console.

Wie kann ich WebMCP-Tools testen, ohne einen Agenten zu bauen?

Verwenden Sie den Model Context Tool Inspector, eine Chrome-Erweiterung, die in der WebMCP-Dokumentation von Chrome aufgeführt ist. Sie listet die Tools auf, die eine Seite registriert hat, und ermöglicht es Ihnen, diese selbst auszuführen. Außerdem bestätigt sie, dass der Browser Ihr JSON Schema parsen kann, und zeigt jedes Ergebnis bzw. jeden Fehler an, den ein Tool zurückgibt. WebMCP muss auf Ihrer Seite trotzdem aktiviert sein, entweder über das WebMCP-Test-Flag unter chrome://flags oder über ein Origin-Trial-Token.

Kann ich meine MCP-Tool-Definitionen für WebMCP wiederverwenden?

Die Eingabedefinitionen können Sie häufig wiederverwenden, die Handler jedoch nicht. Sowohl MCP-Tools als auch WebMCP-Tools beschreiben ihre Eingaben mit JSON Schema, sodass Name, Beschreibung und Argumentstruktur eines Tools in der Regel übernommen werden können. Der Handler ist jedoch ein anderer. Ein MCP-Handler läuft auf Ihrem Server unter der von Ihnen implementierten Authentifizierung. Ein WebMCP-Handler ist JavaScript, das in der Seite läuft – mit der Session des Nutzers und dem aktuellen DOM-Zustand.

Unterstützt Angular WebMCP?

Ja, allerdings nur experimentell. Die experimentelle Unterstützung in Angular ermöglicht es Ihnen, WebMCP-Tools zu registrieren, die dem Lebenszyklus der Dependency Injection von Angular folgen, und sie kann Signal Forms in Tools umwandeln, ohne dass Sie JSON Schemas von Hand schreiben müssen. Die Angular-Dokumentation warnt, dass sich die WebMCP-Spezifikation häufig ändert und diese APIs sich auch außerhalb von Major-Versionen ändern können. Pinnen Sie Ihre Angular-Version und rechnen Sie damit, Ihren Code anpassen zu müssen.