WebMCP, servicebasiertes MCP oder einfache Browser-Nutzung: Wo Agenten-Tools hingehören.
Eine kritische Betrachtung von WebMCP: Seite-Tools gegenüber servicebasiertem MCP und herkömmlichen Browser-Agenten, mit Schwerpunkt auf Sitzungen, OAuth CIMD, Entdeckung, lokalem Zustand und Eigentumsrechten.
Quellen: WebMCP: My Architectural Uneasiness and Where I Think It May Fit
Auf den ersten Blick erscheint WebMCP sinnvoll. Der Benutzer ist bereits eingeloggt, ein Agent arbeitet im Browser, und die Seite kann angeben, welche Aktionen verfügbar sind, sodass der Agent nicht selbst erraten muss, welche Felder und Schaltflächen es gibt. Das Problem liegt darin, wo diese Schnittstelle platziert werden soll. Wenn Anstrengungen unternommen werden, um eine Anwendung für Agenten nutzbar zu machen, sollten die Funktionen dann von der Seite selbst oder von den darunterliegenden Diensten bereitgestellt werden? Und was bringt eine auf Seitenebene angelegte Tool-Schnittstelle im Vergleich zu den üblichen Browser-Tools hinzu?
Diese beiden Fragen bilden den Rahmen für die folgende Bewertung.
Was WebMCP ist
Durch WebMCP kann eine Website strukturierte Tools registrieren, die ein kompatibler Agent über den Browser aufrufen kann. Jedes Tool gibt an, was es tut, welche Eingaben es akzeptiert und welcher Code es ausführt. Die Registrierung erfolgt in JavaScript oder über annotierte HTML-Formulare. Chrome dokumentiert diese Idee als vorgeschlagenen Standard, dessen Pilotphase mit Chrome 149 beginnt, und die API kann sich ändern.
Stellen Sie sich eine Flugsuchseite vor. Ohne WebMCP liest ein Agent die Seite, findet das Feld für das Reiseziel, gibt Daten ein und klickt auf Suchen. Mit WebMCP könnte die Website ein search_flights-Tool veröffentlichen, das ein Reiseziel und Daten entgegennimmt. Der Agent füllt lediglich die Argumente aus, und die Anwendung führt die Suche durch.
Drei Ansätze sollten voneinander getrennt bleiben: MCP auf Serviceebene, WebMCP sowie die allgemeine Nutzung im Browser. Es gibt nichts, was einen bestimmten Ansatz vorschreibt, und ein einziger Agent kann ein Service-Tool für ein Produkt, ein Seiten-Tool für ein anderes sowie den Browser direkt für ein drittes verwenden.
Die architektonische Herausforderung
Die erste Reaktion ist, dass WebMCP servicebezogene Aspekte in die Präsentationsschicht bringt. Das Suchen von Beständen, Ändern einer Buchung oder Aufgeben eines Auftrags in einer typischen Unternehmensanwendung endet bei einem Backend-Service, und der Browser ruft bereits einen Endpunkt auf, der diese Aufgabe erledigt. Warum also einen für Agenten bestimmten Vertrag innerhalb der Seite definieren anstatt neben diesem Service?
Eine natürliche Alternative geht vom bereits vorhandenen Servicevertrag aus, wie beispielsweise einer OpenAPI-Spezifikation oder einer gRPC-Definition, und baut darauf die MCP-Schnittstelle auf. Der Vorteil liegt in der Eigenverantwortung: Das für den Betrieb zuständige Team kann den für Agenten bestimmten Vertrag versionieren, testen und verwalten, wobei interaktive Agenten, Batch-Aufgaben sowie geplante Workflows alle davon profitieren können.
Auch das Hüllen eines internen Endpunkts in ein Seitenwerkzeug macht den Vertrag nicht zu einer geringeren Verpflichtung. Die Agenten erhalten eine Operation mit vorgegebenen Eingaben und Verhaltensweisen, und Workflows funktionieren nicht mehr, wenn sich dieses Verhalten ändert. Überall, wo das Werkzeug zugänglich gemacht wird, muss das Team entscheiden, welche Kompatibilität und Unterstützung es bietet – und das Platzieren der Schnittstelle im Web-Bereich verringert diese Pflichten nicht von selbst.
Ein genauerer Blick schwächt einige dieser anfänglichen Annahmen.
- Der Browser speichert den aktuellen Zustand. Ein Editor kann einen ungespeicherten Entwurf, eine aktive Auswahl oder lokale Operationen enthalten, für die es keine sinnvolle Server-Äquivalenz gibt, und die Bezeichnung des Clients als leere Hülle ignoriert all das.
- Die Logik muss nicht dupliziert werden. Ein Tool kann dieselbe Client-Funktion wie eine Schaltfläche aufrufen und über diese denselben Backend-Endpunkt nutzen. Die eigentliche Sorge besteht in dem zusätzlichen Tool-Vertrag mit seinem eigenen Lebenszyklus sowie darin, wie sich im Laufe der Zeit Geschäftsregeln um dieses Tool ansammeln könnten.
Auch die Reifegrad spielt eine Rolle. Ein gewisses Maß an Experimentieren ist zu erwarten, doch eine Schnittstelle, die auf einer sich ändernden Browser-API basiert, führt zu zusätzlicher Wartungsarbeit.
Die überarbeitete Ansicht lautet daher, dass eine nachhaltige Geschäftsprozessführung am besten dort erfolgt und gesteuert wird, wo der Dienst, der ihn umsetzt, lokalisiert ist, und dass es einen spezifischen Grund braucht, um den Vertrag auf der Seite zu platzieren.
Wiederverwendung von Sitzungen versus Delegierter Zugriff
Der Vorteil der Authentifizierung ergibt sich aus der Arbeit innerhalb eines angemeldeten Browsers, und WebMCP sowie der normale Browsernutzer teilen diesen Vorteil. Der Vergleich hier stellt diese Bequemlichkeit gegenüber dem delegierten Dienstzugriff. Welche zusätzlichen Funktionen explizite WebMCP-Tools im Vergleich zur normalen Browserinteraktion bieten, ist eine separate Frage, die weiter unten behandelt wird.
Wenn ein Agent auf eine Steuerelemente auf einer angemeldeten Website klickt, sendet die Anwendung ihre Anfrage im Rahmen der bestehenden Sitzung, und ein direkt aufgerufenes WebMCP-Tool kann dieselbe Sitzung nutzen. Weder das Tool noch die Anwendung benötigen eine separate Delegation zwischen dem Agenten-Host und dem Service.
Der Vorteil wird bei verschiedenen Anwendungen immer deutlicher. Ein Workflow, der fünf Services betrifft, könnte fünf Genehmigungen, fünf Token-Lebenszyklen sowie fünf Satz Integrationserfordernisse erfordern, zusätzlich zu einer Client-Anmeldung, die von jedem Service abhängt. Wenn der Benutzer bereits bei allen fünf Websites angemeldet ist, vermeidet die Wiederverwendung dieser Sitzungen einen Großteil dieser Einrichtungsarbeiten.
Es wäre übertrieben, diese kostenlose Authentifizierung so zu bezeichnen. Eine Live-Sitzung hat ihr eigenes Sicherheitslebenszyklus, und das Eingeloggt-Sein bedeutet nicht zwingend Zustimmung zu allem, was ein Agent versuchen könnte. Dennoch ist die eingesparte Integrationsarbeit tatsächlich vorhanden. Prompt-Injection und unerwünschte Aktionen lassen sich nicht dadurch lösen, dass einfach eine Schicht ausgewählt wird, da beide Ansätze Schutzmaßnahmen wie Bestätigungen für folgenschwere Operationen benötigen – mit unterschiedlicher Exponiertheit und Durchsetzung – weshalb jedes Design diese Risiken eigenständig bewerten muss.
Wie CIMD die Lücke verringert
Der Zugriff auf Service-Ebene verbessert sich ebenfalls. Client ID Metadata Documents (CIMD) beheben ein Problem bei OAuth: Wie identifiziert sich ein völlig neuer Client bei einem Autorisierungsserver, der ihn noch nie getroffen hat. Der Client verwendet eine HTTPS-URL als seine Identifikation, und diese URL liefert ein Metadatendokument, das Angaben wie zulässige Redirect-URI aufführt. Ein unterstützender Server lädt dieses Dokument herunter und überprüft es, wodurch es nicht mehr notwendig ist, jedes Client-Server-Paar im Voraus zu registrieren. Die MCP-Autorisierungsspezifikation vom November 2025 empfiehlt die Unterstützung von CIMD und setzt diese dem dynamischen Client-Register vor, sofern keine im Voraus registrierten Client-Daten vorhanden sind.
In dem Fall mit fünf Diensten beseitigt die CIMD-Unterstützung auf allen fünf Autorisierungsservern die vorherigen Registrierungen. Die Autorisierungsanforderungen sowie die Lebenszyklen der Tokens pro Dienst bleiben unverändert, wobei bestehende Genehmigungen oder Sitzungen die Anfragen verringern können, sodass nicht unbedingt fünf neue Anmeldungen erforderlich sind. Die Autorisierungsentscheidungen selbst werden durch CIMD nicht berührt.
Kontext, Lebenszyklus und Entdeckung
Ein ungespeichertes Dokument zeigt den Wert des lokalen Browser-Zustands. Ein Tool, das den ausgewählten Abschnitt eines unvollendeten Entwurfs bearbeitet, arbeitet mit einem Zustand, den der Dienst noch nicht gesehen hat – das ist ein spezifischerer Grund, eine Seitenwerkzeug zu bereitstellen, anstatt eine Backend-Operation weiterzuleiten.
Das Problem ist, dass der lokale Zustand die Tools an die Seite bindet. Wenn ein Benutzer wegklickt oder die Seite schließt, muss ein Agent möglicherweise die Anwendung erneut öffnen und den Kontext neu erstellen. Die Anmeldesitzung kann durchaus überleben, während der ungespeicherte Zustand sowie die dort vorhandenen Tools verschwinden.
Die Erkundung ist eine separate Angelegenheit: Wie erfährt ein Agent, was eine Seite anbietet? Chromes dokumentierte Einschränkungen besagen, dass die Seite besucht werden muss, bevor ihre WebMCP-Tools bekannt sind. Ein bekannter MCP-Endpunkt kann direkt abgefragt werden, ohne dass eine Benutzeroberfläche erforderlich ist, doch die Lokalisierung eines Endpunkts anhand einer einfachen Web-Adresse stellt eine eigene Herausforderung dar. Zudem finden OAuth-Metadaten nur den Autorisierungsserver für bereits bekannte, geschützte Ressourcen – es gibt keine universelle Auflistung der MCP-Fähigkeiten.
SEP-2127 mit dem Titel „MCP Server Cards“ schlägt eine Standardmethode vor, um strukturierte Server-Metadaten über HTTP zu veröffentlichen, damit Clients Service-Interfaces vor dem Herstellen einer MCP-Verbindung entdecken können – ohne dass eine für Nutzer sichtbare Seite betrieben werden muss. Das ist eine vielversprechende Richtung. Zum Zeitpunkt der Niederschrift ist der Pull Request noch offen, sodass es sich um einen Vorschlag zur Lösung des Problems handelt und nicht um eine überall anwendbare, bereits angenommene Lösung.
Auf der Seite der Entdeckungsfunktionen hat keines der beiden Ansätze einen klaren Vorteil: Seite-basierte Tools erfordern einen Besuch der Website, während es für die Entdeckung von Diensten von einer beliebigen Adresse noch keine universelle Konvention gibt. Auch keine der beiden Schichten garantiert eine gute Verwaltung, denn WebMCP-Tools können gut getestet und gewartet werden, während Service-Tools schlecht gestaltet sein können. Die eigentliche Frage ist die Verantwortlichkeitszuweisung sowie welche Arbeitsabläufe die Schnittstelle unterstützen muss.
Browser-Agenten funktionieren bereits ohne diese Funktion
Es lohnt sich, zu prüfen, was ein Browser-Agent ohne WebMCP herausfinden kann. In einer Desktop-Sitzung eines Code-Agenten werden vorzugsweise auf Zugänglichkeit basierende Elementaktionen genutzt, sofern verfügbar, wobei Screenshots zum visuellen Kontext oder als Ersatz dienen. Die für eine Dokumentationsseite zurückgegebene Zugänglichkeitsinformation war aufschlussreich. Das ist eine beobachtete Eigenschaft einer bestimmten Sitzung und keine Aussage über jede Version oder den Standardzustand.
Durch die Integration erhielt der Agent eine strukturierte Beschreibung der dargestellten Benutzeroberfläche mit Textfeldern, Schaltflächen, Beschriftungen, Werten und Zuständen. Zudem standen domorientierte Werkzeuge für geeignete Aufgaben zur Verfügung. Mehr vom Inhalt der Seite erschien in Form strukturierten Textes, als es von screenshottreuen Erwartungen vorherzusehen wäre. Für ein einfaches Suchformular könnte der Agent beispielsweise etwas Ähnliches erhalten.
1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled
Daraus kann ein Agent das Zielfeld identifizieren, auf die Schaltfläche „Flüge suchen“ klicken und den aktualisierten Status überprüfen. Die HTML-Semantik sowie die Barrierefreiheitsbeschreibungen tragen bereits einen Großteil der Bedeutung einer Benutzeroberfläche in sich. Welche Ansicht einer Seite ein Modell erhält, hängt von der Integration ab und nicht vom Namen des Modells; außerdem zeigen OpenAIs Dokumentationen zur Computernutzung Integrationen, bei denen Screenshote an das Modell gesendet werden und Aktionen über von der Anwendung bereitgestellte Tools zurückgegeben werden.
Das Ergebnis ist, dass Agenten eine Website auch ohne WebMCP bedienen können, was die Menge an Funktionen verringert, die Website-Entwickler implementieren müssen. Das klärt jedoch nicht, ob WebMCP lohnenswert ist. Ein Zugänglichkeitsbaum listet Steuerelemente auf, während ein gut gestaltetes Tool eine gesamte Aktion samt Eingaben beschreiben kann, wodurch Interaktionen und Raten erforderlich werden. Während ein Browser-Agent über zehn verschiedene Steuerelemente arbeitet, könnte die Anwendung für diese Aufgabe ein einziges Tool anbieten. Chrome präsentiert WebMCP als progressive Verbesserung und enthält einen Inspektor zum Ausprobieren der Tools.
Für diese Bewertung wurde kein kontrollierter Vergleich mit und ohne WebMCP-Tools durchgeführt, sodass es sich um ein architektonisches Urteil und nicht um ein Leistungsresultat handelt. Ein gerechtes Urteil würde die Aufgabenerledigung, die Anzahl der Interaktionen sowie die verstrichene Zeit in mehreren Arbeitsabläufen messen. Eine erfolgreiche Demo ist ein guter Ausgangspunkt, beantwortet aber diese umfassendere Frage nicht.
Was eingesetzt werden kann, hängt auch davon ab, welche Schnittstellen ein Team kontrolliert. WebMCP benötigt die Zusammenarbeit der Website, und eine Service-Integration erfordert eine zugängliche, autorisierte Service-Schnittstelle. Wenn eine Drittanbieter-Anwendung weder das eine noch das andere bietet, kann die normale Browsernutzung der einzige praktikable Weg sein.
Was bleibt übrig
Die daraus resultierenden Ausgangspunkte sind:
- Tools auf Serviceebene eignen sich für zuverlässige Geschäftsprozesse, insbesondere für unüberwachte oder langlaufende Abläufe.
- WebMCP ist geeignet, wenn der lokale Anwendungsstatus wichtig ist oder wenn die Wiederverwendung eines authentifizierten Client-Workflows viel Integrationsarbeit spart.
- Normale Browsernutzung deckt die Fälle ab, in denen es keine speziellen Tools gibt, insbesondere Anwendungen außerhalb der Kontrolle des Teams.
Es bleibt Unbehagen bestehen, wenn WebMCP zur Standardplattform für Funktionen wird, die bereits klare Servicegrenzen aufweisen. Die Bequemlichkeit bei Sitzungen ist ein starker Argument für die Implementierung, sollte aber nicht allein die langfristige Architektur bestimmen.
Beweise, die diese Sichtweise ändern könnten, wären solche, die für eine bestimmte Anwendung zeigen, dass page-basierte Tools deutlich vorteilhafter sind als die normale Browsernutzung – und zwar zu geringeren Gesamtkosten – im Vergleich zum Aufbau und zur Wartung einer Service-Schnittstelle, wobei diese Kosten Autorisierungen, Wartung, Governance sowie Arbeitsabläufe umfassen, die die Schnittstelle nicht abdecken kann.
WebMCP ist am stärksten, wenn drei Faktoren zusammenfallen: eine aktive, authentifizierte Sitzung, wertvoller lokaler Zustand sowie Client-Arbeitsabläufe, die wiederverwendet werden können. Auch die normale Browsernutzung ermöglicht die Wiederverwendung von Sitzungen, sodass die offene Frage bleibt, welche expliziten Tools dazu beitragen. Ein Seitenwerkzeug, das eine Operation lediglich an einen Dienst weiterleitet, benötigt dennoch eine Begründung dafür, warum das an den Agenten gerichtete Vertragsmodell auf der Seite verbleiben soll.