Zwei Protokolle, eine Architekturentscheidung.
Welche Ihrer Funktionen ins Backend gehören und welche in die laufende Seite: Das ist keine Protokollfrage, sondern eine Produktfrage. Genau daran arbeiten wir im Seminar.
Architektur
WebMCP vs. MCP: zwei Protokolle, zwei Ebenen
WebMCP ist weder eine Erweiterung noch ein Ersatz von MCP; die
Chrome-Doku sagt es wörtlich:
WebMCP is not an extension or a replacement of MCP.
MCP verbindet Agenten
mit Backends, Datenquellen und Workflows und läuft persistent als Server; WebMCP macht die
laufende Website im Browser-Tab für Agenten bedienbar. Die Empfehlung beider Lager:
kombinieren. MCP für die Kernlogik im Hintergrund, WebMCP für die Interaktion mit der
Web-Oberfläche.
Warum es überhaupt zwei braucht
MCP (Model Context Protocol) hat das Problem der Backend-Anbindung gelöst: Ein Agent
spricht mit einem Server, der Daten und Aktionen anbietet, unabhängig von jeder Oberfläche.
Genau daraus entsteht aber ein zweites Problem, das der
WebMCP-Explainer UI Disintermediation & Context Loss
nennt: Die Integration läuft am
Nutzer und an der Web-App vorbei, direkt zwischen Agent und Dienst. Session, Login-Zustand,
Warenkorb, alles was in der laufenden Web-App steckt, ist für den Backend-Weg unsichtbar.
WebMCP setzt deshalb auf der anderen Seite an: im Browser, im selben Tab, in dem der Nutzer arbeitet. Tools laufen im Kontext der geladenen Seite und nutzen deren Zustand und deren Session.
Der Vergleich im Überblick
Die Gegenüberstellung nach der Chrome-Doku:
| Aspekt | MCP | WebMCP |
|---|---|---|
| Zweck | Daten und Aktionen überall verfügbar machen | die Live-Website für Agenten bedienbar machen |
| Lebenszyklus | persistent (Server/Daemon) | ephemer, an den Tab gebunden |
| Verfügbarkeit | global (Desktop, Mobile, Cloud) | im Browser |
| Kontext | headless, ohne UI | im DOM, mit Nutzer-Session und Seitenzustand |
| Typischer Fall | Hintergrund-Aktion über eine API | eine Buchung, Suche, Konfiguration in der laufenden UI |
Zwei Punkte daraus verdienen Betonung. Erstens Geschwindigkeit und Verlässlichkeit: WebMCP-Tools arbeiten browserintern ohne Server-Roundtrips. Zweitens Stabilität: Tools hängen an der Anwendungslogik, nicht am Design; ein Redesign bricht keine Agent-Funktionalität.
Das häufigste Missverständnis: „Der Browser wird zum MCP-Server"
Nein. Patrick Brosset (Microsoft Edge) hat diese Fehldeutung öffentlich korrigiert, inklusive seiner eigenen: Der Browser agiert als Übersetzer, nicht als MCP-Server. WebMCP definiert die Primitive, vor allem Tools; die übrigen Schichten des MCP-Ökosystems (Transport, Session-Verwaltung, Client-Logik) verwaltet der Browser bzw. der Agent. Wer WebMCP einführt, betreibt deshalb keinen Server und verwaltet keine Endpoints; er annotiert seine Web-App.
Wann nehme ich was?
- Nur MCP: Die Funktion existiert unabhängig von einer Oberfläche (Datenbank, interner Dienst, Automatisierung ohne Nutzer im Loop).
- Nur WebMCP: Die Funktion lebt in der Web-App und braucht deren Session und Zustand: Suche, Buchung, Formular, Konfigurator.
- Beides: Die realistische Zielarchitektur für Unternehmen. Der Explainer nennt WebMCP ausdrücklich komplementär zu backend-orientierten Protokollen wie MCP: dieselbe Geschäftslogik, zwei Zugänge, je nachdem ob der Agent mit oder ohne Nutzer unterwegs ist.
Quellen
Alle Belege sind öffentlich zugänglich und am auf Erreichbarkeit geprüft.
- Chrome-Doku: Compare WebMCP to MCP die Gegenüberstellung der beiden Protokolle
- webmachinelearning/webmcp Spezifikation und Diskussion
- Patrick Brosset: WebMCP updates, clarifications, and next steps die Klarstellung zum Browser als Übersetzer