- MCP-B: Ein browsernatives KI-Automatisierungsprotokoll
- Unterstützt KI dabei, durch direkten Zugriff auf die API einer Website 1.000-mal schneller und präziser zu automatisieren statt mit herkömmlichen Methoden auf Basis von Screenshots und Klicks; ein Browser-Context-Protokoll
- Mit nur rund 50 Zeilen Code lässt sich KI direkt über die Authentifizierungsinformationen innerhalb der Website anbinden, ganz ohne separates OAuth, API-Keys oder komplexe Konfiguration
- Nutzt Browser-Sitzungen und bestehende Authentifizierungssysteme, funktioniert sofort ohne neue Authentifizierung oder Berechtigungseinstellungen und respektiert unverändert die API-Sicherheitsrichtlinien jeder Web-App
- Über eine Erweiterung kann ein KI-Assistent direkt Daten abrufen und Aufgaben ausführen, während er zwischen mehreren Tabs und Apps wechselt; gegenüber bestehender Automatisierung werden Leistung (Ausführung in wenigen ms) und Zuverlässigkeit überwältigend verbessert
- Durch den strukturierten API-Zugriff ist es unabhängig von UI-Änderungen, Screenshot-Fehlern und komplizierter Selektor-Verwaltung. Sowohl Installation als auch Nutzung sind sehr einfach
Überblick über MCP-B
- MCP-B (Machine Context Protocol for Browsers) ist ein Model-Context-Protokoll für Browser, das einen Standard zur Steuerung und Interaktion mit Browser-Umgebungen auf ähnliche Weise wie KI-basierte Terminal-Automatisierung bereitstellt
- Das Protokoll definiert die Kommunikation zwischen Browser und KI-Engine klar und strukturiert so verschiedenste Automatisierungen und Modellinteraktionen
Unterschiede zu bisherigen Ansätzen
- Traditionelle Browser-Automatisierung: Screenshot-Analyse, Elementklicks, anfällig für UI-Änderungen, langsam und instabil (10–20 Sekunden pro Aufgabe, Kosten von $4–5)
- Bestehender MCP-Ansatz: API-Keys und komplexe Authentifizierung erforderlich, hohe Einstiegshürde beim initialen Setup
- MCP-B: Nutzung der Browser-Sitzung, direkter API-Zugriff, sofort einsatzbereit ohne komplexe Authentifizierung oder Konfiguration
Zentrale Prinzipien und Architektur
- MCP-Server pro Tab: Jede Web-App betreibt eigenständig einen TypeScript-basierten MCP-Server (In-Memory-Transport, Wiederverwendung bestehender Cookie-/JWT-Authentifizierung)
- MCP-B-Erweiterung: Chrome-/Edge-/Firefox-Erweiterung (Content-Script kommuniziert per
postMessagemit dem Tab-Server), bündelt Tools und APIs aller Tabs an einem Ort - Integration von KI-Assistenten: Browser-Automatisierung über MCP-B mit Native Bridge und verschiedenen Clients (Claude Desktop, Cursor IDE usw.) möglich
Nutzung und Bereitstellung
- Entwickler: 1) Paket installieren 2) MCP-Server-Code hinzufügen 3) Bereitstellung abschließen → keine separaten API-Keys, kein OAuth, keine komplexe Konfiguration nötig
- Nutzer: Nach Installation der Erweiterung sofort verwendbar; Automatisierung startet direkt allein über die KI-Konfiguration
Praktische Vorteile
- Authentifizierung: Verwendet bestehende Login- und Sitzungsinformationen der Website unverändert, kein OAuth 2.1 / keine separate Authentifizierung erforderlich
- Leistung: Aufgaben per direktem API-Aufruf in Millisekunden abgeschlossen (10.000-fache Verbesserung gegenüber bisher)
- Sicherheit: Läuft innerhalb der Anwendung und befolgt unverändert bestehende Zugriffssteuerungen und Berechtigungsrichtlinien
- Skalierbarkeit: Mehrere Web-Apps, Tabs und KI-Tools lassen sich über MCP-B integriert verwalten
- Konfiguration: Mit rund 50 Zeilen Code ist die Automatisierung einsatzbereit
Vergleich in Kürze
| Ansatz | Authentifizierung und Konfiguration | Funktionsweise | Leistung und Zuverlässigkeit |
|---|---|---|---|
| Bestehende Automatisierung | Komplexe Authentifizierung, API-Keys | Screen-Scraping, Klicks | Langsam und instabil (10–20 Sek.) |
| Bestehendes MCP | API-Keys, OAuth erforderlich | API-Zugriff | Hohe Einstiegshürde |
| MCP-B | Keine Konfiguration, Nutzung der Browser-Sitzung | Direkter API-Aufruf | ms-Bereich, sehr schnell/stabil |
Fazit: KI-Automatisierung der nächsten Generation im Browser
- MCP-B ist ein für Browser-Umgebungen optimiertes KI-Automatisierungsprotokoll und in Bezug auf Authentifizierung, Sicherheit, Skalierbarkeit und Leistung in jeder Hinsicht innovativ
- Ohne zusätzliche Authentifizierung oder komplexe Konfiguration lässt sich groß angelegte KI-Automatisierung allein durch browserbasierte direkte API-Aufrufe umsetzen
- MIT-Lizenz, Community-zentriert, Unterstützung für alle wichtigen Browser
2 Kommentare
Die Kernvision der MCP-B-Technologie lässt sich wohl wie folgt zusammenfassen.
„Über das vertrauenswürdige Vermittlungsmedium einer Chrome-Erweiterung (Extension) sollen die Nutzerdaten, die der Browser bereits sicher verwaltet (Cookies, Sessions, Authentifizierung usw.), genutzt werden, um die vom Entwickler vorab auf der Webseite definierten ‚Tools‘ per natürlichem Sprachbefehl aus dem AI-Chatfenster aufzurufen und zu steuern.“
Ich habe jedoch das Gefühl, dass „kaum Potenzial zur Verbreitung besteht“, und ich denke, die Gründe dafür sind die folgenden.
Zusammenfassend lässt sich sagen:
Die Idee von MCP-B selbst ist technologisch sehr interessant und innovativ, doch sie scheint weder Nutzern noch Entwicklern eine klare Antwort auf die grundlegende Frage zu geben: „Warum sollte man ausgerechnet diesen Ansatz verwenden?“ Gegenüber dem bestehenden API-Ansatz sind die Vorteile unklar, während die Nachteile in Form von Sicherheitsbedenken und Entwicklungsaufwand deutlich zutage treten.
Daher scheint diese Technologie derzeit zwar experimentell von einigen Enthusiasten oder Entwicklern mit speziellen Zielen genutzt werden zu können, doch für eine Ausweitung auf das gesamte Web-Ökosystem gibt es offenbar viele Hürden.
Hacker-News-Kommentare
Prognose: Das wird denselben Weg gehen wie RSS. Unternehmen neigen dazu, es zu vermeiden, dass Nutzer selbst kontrollieren, wie ihre Daten genutzt werden
Mit REST APIs war es ähnlich: Eine Zeit lang erwartete man mit dem Trend zum „API-first“-Design, dass sie die Zukunft von Service-Automatisierung und Integration würden. Dann merkten die Unternehmen schnell, dass solche Fähigkeiten ihr Erlösmodell bedrohen, und ruderten bald zurück. Am Ende stellte sich erneut heraus, dass das ganze Geld darin steckt, den Nutzern genau diese Kontrolle nicht zu geben
Ich finde nicht, dass RSS gescheitert ist, sondern im Gegenteil ein enormer Erfolg war. Nachdem Google Reader verschwunden war, konnte ich einfach zu einem anderen Reader wechseln, und RSS-Feeds funktionieren seit über 20 Jahren problemlos. Ich treffe fast nie auf Seiten, die kein RSS unterstützen
Die meisten Websites unterstützen RSS immer noch, und manche haben standardmäßig einen Feed, auch wenn er auf der Seite nicht angezeigt wird. Selbst wenn einige nicht den vollständigen Text veröffentlichen, ist es als Update-Hinweis oder Automatisierungs-Trigger weiterhin wertvoll. RSS lebt also immer noch äußerst nützlich weiter, fast wie eine Mikrowelle: Es ist einfach selbstverständlich da
Die Marktstruktur hat sich verändert, und große Unternehmen konzentrieren sich inzwischen eher auf die „Intelligence Layer“ als auf den Content selbst. Content wird zunehmend zur Ware. Google muss die Augen und Aufmerksamkeit der Nutzer und die smarten Techniken, die sie fesseln, in die Hand bekommen, um weiter Werbung verkaufen zu können. Google wollte RSS nicht, weil RSS Google Search umgehen konnte
Sobald AI bald wie Menschen klicken und scrollen kann, wird ein weiterer endloser Wettbewerb beginnen
Die Beitragsgeschichte des Github-Projekts ist sehr interessant (Zitat mit direktem Link). MiguelsPizza hat 3 Commits gemacht, Claude 2, aber das Änderungsvolumen von Claude ist fast überwältigend
Weil die Erweiterung vorübergehend privat geschaltet und dabei die Git-Historie angepasst wurde, gibt es leichte Abweichungen zur tatsächlichen Historie. Trotzdem stimmt es, dass Claude etwa 85 % des gesamten Codes geschrieben hat
Solche Muster — riesige AI-basierte Codebeiträge — werden in Zukunft wohl immer häufiger werden
Claudes Commit-Graph ist sehr ungewöhnlich. Es sieht so aus, als würde Claude Code direkt committen, tatsächlich ist das aber fast nie der Fall. Siehe auch das claude-Profil
In der tatsächlichen Commit-Liste steht überall MiguelsPizza / Alex Nahas als Autor (Link). Das wirkt etwas merkwürdig
Unter Verweis auf einen Auszug aus dem Blog wird das Authentifizierungsproblem von MCP angesprochen. OAuth2.1 ist langfristig betrachtet in Ordnung, aber für Agenten, die im Namen des Nutzers handeln, muss Authentifizierung praktisch neu erfunden werden. Das Risiko von Datenlecks in Multi-Tenant-Apps ist noch nicht gelöst
Die Möglichkeit, den Schadensradius und die zugänglichen Daten des Modells zu begrenzen, könnte ein großer Vorteil von MCP sein. Client-seitige APIs in Multi-Tenant-Apps dürften ohnehin bereits auf den jeweiligen Nutzerbereich beschränkt sein; wenn man dem Modell nur diese gibt, sollte der Schaden begrenzt bleiben. Erwähnt wird auch ein Kompatibilitätsproblem zwischen Amazons internem Auth-System und OAuth2.1 (bei Amazon ist Auth anders)
Ich frage mich, ob einige Funktionen von OAuth2.1 bereits in RFC 8693 unter Delegation und Impersonation behandelt werden
Der Umfang, auf den das Modell zugreifen kann, ist letztlich derselbe wie beim Nutzer, daher liegt die Verantwortung für eine solide Sicherheitsimplementierung bei den Betreibern der Website
Ich denke nicht, dass das Amazon-Beispiel ohne korrekt angewendetes OAuth das Kernproblem ist. Eine Backdoor-artige Zugriffsmöglichkeit über die eigentlichen Nutzerrechte hinaus wäre sehr gefährlich. Wenn alle Aktionen einer MCP-App unter derselben Kategorie wie der Nutzerzugriff protokolliert werden, könnte das viele Compliance-Probleme verursachen. Aus dieser Perspektive ist es sehr interessant, aber sicherheitstechnisch scheint es als Umgehungsweg problematisch zu sein
Es wird die Idee eingebracht, dass sich fast all das durch die Veröffentlichung einer Swagger(OpenAPI)-Spezifikation und einen generischen Swagger-MCP-Client ersetzen ließe. Der Nutzer könnte seine Auth-Session einfach selbst manuell öffnen. Vorgeschlagen wird, dass Claude API-Keys aus Prompt/Einstellungen gut erfassen und dann mit einem Swagger-basierten API-Client im Grunde dasselbe tun könnte
Daran haben beim Auftauchen von MCP alle zuerst gedacht. In der Praxis zeigte sich aber, dass es zu viele Tools gibt und es deshalb nicht gut funktioniert. Trotzdem gibt es in diesem Bereich weiterhin interessante Versuche
Es gibt auch den warnenden Hinweis, keine API-Keys in den Prompt zu schreiben
Claude Code wird bei API-Tests wirklich praktisch, wenn man in
CLAUDE.mdnur einen Link zurswagger.jsonangibtEs wird dazu ermutigt, es einfach selbst auszuprobieren
Ich bin mir nicht sicher, wer die Zielnutzer sind. Bei Frontend-Tests ist es eher nützlich, wenn Tests brechen, sobald sich die UI stark verändert. Für andere Automatisierungszwecke wäre es meiner Meinung nach besser, gleich eine echte API bereitzustellen
Zur Analogie „Wenn man bei Home Depot einen Tisch bauen will, wird es eher noch schwieriger“ wird eingewandt, dass es bei Home Depot doch jede Menge Holz gibt
Bei Home Depot werden auch bereits fertige Tische verkauft
Bei Home Depot könnte die Arbeit sogar leichter sein, weil es dort bessere Präzisionswerkzeuge und sogar Fachleute gibt
Im Scherz wird angemerkt, die Nuance sei eher: „Das Holz musst du dir selbst vorstellen und erschaffen“
Es wird erklärt, dass die Formulierung aufgrund dieses Hinweises angepasst wurde
Ich habe MCP selbst noch nicht benutzt, aber aus Sicht einer Person mit Behinderung scheint MCP großes Potenzial für Accessibility-Anwendungen in der Browser- und Smartphone-Automatisierung zu haben. Gleichzeitig frage ich mich, ob große Web- und App-Plattformen so etwas überhaupt einführen würden, weil die Technik von böswilligen Nutzern missbraucht werden könnte. Gibt es vielleicht schon reale Beispiele für den Einsatz zur Verbesserung der Accessibility?
Es wird begrüßt, dass MCP-B als Open Source veröffentlicht wurde. Vieles passiert zwar ohnehin im Browser, aber bei MCP ist die Annahme etwas anders, nämlich dass ein AI-Client die Aufgaben übernimmt. Grundsätzlich wird gefragt, worin sich MCP-B eigentlich davon unterscheidet, die JS-API einer Web-App direkt mit einem LLM-Server zu verbinden und so zu verwenden. Ist es am Ende dasselbe oder steckt ein größeres Gesamtbild dahinter?
Nur anhand des Inhalts der Homepage ist es schwer zu verstehen, und es wird gefragt, ob es sich wie eine Browser-Version von Selenium anfühlt
Es wird erwartet, dass mit dem Start der Browser-Automatisierung per MCP für kostenlose LLM-Nutzer auch kostenlose Modelle Captchas verlangen werden. Das Problem ist, dass Captchas gegen LLMs nicht besonders wirksam sind, sodass am Ende eine seltsame Ära von Roboterkriegen beginnen könnte, in der LLMs gegeneinander kämpfen, um den Zugriff anderer Automatisierungs-LLMs zu blockieren