Das Model Context Protocol (MCP) standardisiert die Verbindung zwischen einer KI-Anwendung und externen Werkzeugen. Ein kompatibler Client kann verfügbare Tools erkennen, einen erlaubten Aufruf ausführen und ein strukturiertes Ergebnis zurückerhalten, ohne dass für jede einzelne Nutzeranfrage ein neues Integrationsskript nötig ist.

Für browserbasierte Workflows ergänzt BitBrowser diese Ebene um isolierte Profile. Diese Profile haben getrennte Cookies und lokalen Speicher. Sie nutzen auch Proxy-Einstellungen, Erweiterungen und Fingerprint-Konfigurationen. Außerdem enthalten sie eigene Sitzungen. Seit BitBrowser 7.1.5 ist ein MCP-Dienst in die Local-API-Umgebung eingebunden. BitBrowser 7.1.5 Release Notes

Dadurch können Cursor, Claude und andere kompatible MCP-Clients mit BitBrowser über natürlichsprachige Anweisungen arbeiten. MCP ersetzt weder Playwright noch Selenium oder direkte API-Automatisierung, sondern bietet eine zusätzliche agentenorientierte Schnittstelle. Offizieller BitBrowser MCP Guide

Diese Anleitung führt durch Local API, Authentication Control, MCP-Konfiguration, einen sicheren Read-only-Test, das Erstellen eines Testprofils, einen autorisierten Proxy, konsistente Profilparameter sowie Teamrechte, Sicherheit und Fehlerbehebung.

Was ist ein MCP-Server?

MCP ist ein offenes Protokoll, mit dem ein Server die verfügbaren Werkzeuge, Parameter und Ergebnisse gegenüber einem KI-Client beschreiben kann. Der Client wählt abhängig von Nutzeranfrage und Berechtigung das passende Tool aus.

Bei BitBrowser lässt sich die Kette so darstellen: KI-Client → MCP → lokaler BitBrowser MCP Server → Local API → Browserprofil → autorisierte Website oder Webanwendung. Der lokale Endpoint hält den unmittelbaren Browserzugriff auf dem kontrollierten Rechner.

Der zentrale Vorteil ist die Trennung von Kontexten. Ein Agent kann mit mehreren Profilen arbeiten, ohne Cookies, Sitzungen, Proxy-Konfigurationen oder Projektdaten zu vermischen. Das verbessert Reproduzierbarkeit und Auditierbarkeit.

Die Rolle von BitBrowser im MCP-Workflow

BitBrowser ist mehr als ein einzelner MCP-Endpunkt. Der praktische Nutzen entsteht durch die Kombination aus Agentenzugriff und isolierter Browserprofil-Infrastruktur. Jedes Profil kann eigene Cookies, Speicher, Proxy-, Fingerprint- und Erweiterungseinstellungen behalten.

Ein Team kann so beispielsweise ein Frankreich-QA-Profil, ein Deutschland-Lokalisierungsprofil und ein US-Marktforschungsprofil führen. Diese Aufteilung ist verständlicher als ein ständig wechselnder Browserkontext.

MCP liegt über dieser Infrastruktur. Wenn ein Tool freigegeben ist, kann ein Agent Profile auflisten, eine Konfiguration prüfen, ein Testprofil erstellen, ein Fenster starten oder eine gezielte Änderung ausführen.

Die Local API bleibt daneben relevant. Deterministische interne Skripte können direkt gegen die API arbeiten, während MCP für Aufgaben geeignet ist, bei denen ein Nutzer die Absicht formuliert und ein KI-Client das passende Werkzeug auswählt.

BitBrowser-MCP-Architektur

Voraussetzungen

Vor dem Start sollte eine kontrollierte Testumgebung vorhanden sein:

• BitBrowser 7.1.5 oder neuer

• Zugriff auf Settings → Browser Settings → Local API

• Aktiviertes Authentication Control

• KI-Client mit Unterstützung benutzerdefinierter MCP-Server

• Eigenes Testprofil ohne sensible Produktionsdaten

• Autorisierter Proxy, falls regionale QA erforderlich ist

• Definierte Rollen und Rechte für Team und KI-Agent

Schritt-für-Schritt-Einrichtung

1. BitBrowser installieren oder aktualisieren

Installiere eine aktuelle BitBrowser-Version beziehungsweise aktualisiere den vorhandenen Client. Starte BitBrowser danach neu. In Teams sollte eine neue Version zunächst auf einem Testsystem geprüft werden, bevor kritische Profile oder automatisierte Produktionsprozesse damit arbeiten. BitBrowser herunterladen

2. Local-API-Einstellungen öffnen

Öffne Settings → Browser Settings → Local API. Dort befinden sich Port, Authentifizierung und lokale Zugriffseinstellungen. Notiere die aktuelle Konfiguration, damit Änderungen später nachvollziehbar bleiben und ein Verbindungsproblem nicht durch mehrere gleichzeitig veränderte Werte verschleiert wird.

3. Authentication Control aktivieren

Aktiviere Authentication Control. BitBrowser verwendet anschließend einen Token im Header x-api-key. Behandle ihn wie ein Passwort: nicht in öffentliche Repositories einchecken, nicht in Screenshots zeigen und nur an Systeme oder Personen geben, die den Zugriff tatsächlich benötigen.

4. MCP-Endpunkt prüfen

Prüfe den Endpunkt in deiner Installation. Die Standardkonfiguration nutzt typischerweise 127.0.0.1:54345 für die Local API und /mcp für MCP. Wurde der Port geändert, gilt ausschließlich die lokale Einstellung und nicht ein Beispielwert aus einem Artikel.

Local API: http://127.0.0.1:54345
MCP:       http://127.0.0.1:54345/mcp

5. Generierte MCP-Konfiguration kopieren

Kopiere bevorzugt die von BitBrowser erzeugte MCP-Konfiguration. So werden Endpoint, Port und Authentifizierung konsistent übernommen. Nach einem Tokenwechsel muss auch die Konfiguration im KI-Client aktualisiert werden, sonst führt ein alter Schlüssel zu Authentifizierungsfehlern. Offizieller BitBrowser MCP Guide

6. BitBrowser mit Cursor verbinden

Öffne in Cursor die MCP- beziehungsweise Tools-&-Integrations-Einstellungen, füge einen neuen Server hinzu und hinterlege die BitBrowser-Konfiguration. Aktiviere die Verbindung und lade Cursor bei Bedarf neu. Teste zuerst Tool Discovery, bevor ein Agent Schreibrechte verwendet.

7. Claude oder anderen Client verbinden

Füge BitBrowser in Claude oder einem anderen Client mit Custom-MCP-Unterstützung als Server hinzu. Übernimm Endpoint und Authentifizierung aus der aktuellen BitBrowser-Konfiguration. Oberflächen externer Clients können sich ändern, daher sollte die generierte Konfiguration als Quelle dienen.

8. Zuerst nur lesend testen

Starte mit einer Read-only-Anfrage: Verbindung prüfen und verfügbare Profile auflisten, ohne etwas zu erstellen, zu starten, zu ändern oder zu löschen. Damit lassen sich Netzwerk, Authentifizierung, Tool Discovery und Berechtigungen getrennt von einer Schreiboperation testen.

List the BitBrowser profiles available to this connection.
Do not create, modify, launch or delete anything.

9. Testprofil erstellen

Erstelle nach erfolgreichem Lesetest genau ein Profil namens MCP_Test_01. Importiere keine sensiblen Produktionscookies. Lass dir die Profil-ID zurückgeben und stoppe danach, damit das Ergebnis in BitBrowser manuell geprüft werden kann.

Create a BitBrowser profile named MCP_Test_01.
Return the profile ID and stop.

10. Autorisierten Proxy konfigurieren

Wenn eine autorisierte Lokalisierungs- oder QA-Aufgabe eine regionale Verbindung erfordert, weise dem Testprofil einen freigegebenen HTTP-, HTTPS- oder SOCKS5-Proxy zu. Prüfe Host, Port und Zugangsdaten und teste den Endpoint, bevor der Browser gestartet wird.

11. Umgebung konsistent halten

Halte Region, Sprache, Zeitzone und Projektzweck eines Profils möglichst stabil. Ein DE_QA-Profil sollte nicht bei jedem Lauf eine andere Region erhalten. Konsistente Umgebungen sind leichter zu reproduzieren, zu dokumentieren und bei Problemen zu analysieren.

12. Profil über MCP starten

Lass den MCP-Client anschließend nur MCP_Test_01 starten. Prüfe, ob das richtige Profil geöffnet wurde und die erwartete Netzwerkumgebung aktiv ist. Die Trennung von Erstellen, Konfigurieren, Prüfen und Starten verringert die Fehlersuche deutlich.

13. Schrittweise skalieren

Erst wenn der kleine Workflow zuverlässig funktioniert, sollten Templates, Gruppen, zusätzliche Schreibaktionen oder wiederkehrende Aufgaben eingeführt werden. Begrenze Berechtigungen, protokolliere wichtige Änderungen und setze bei risikoreichen Aktionen eine menschliche Freigabe ein.

Legitime Einsatzbereiche für BitBrowser MCP

KI-gestützte QA: Testprofile prüfen und reproduzierbare Browserumgebungen für autorisierte Tests starten.

Lokalisierungstests: Regionale Profile getrennt halten und lokalisierte Seiten kontrollieren.

Profilverwaltung: Profile für interne Projekte oder autorisierte Kunden erstellen, benennen, prüfen und starten.

Marktforschung: Sitzungen und Browserkontexte verschiedener Forschungsprojekte sauber trennen.

Werbeprüfung: Genehmigte regionale Umgebungen zur Kontrolle von Kampagnendarstellungen nutzen, ohne eigene Anzeigen künstlich zu klicken.

Entwicklung: Reproduzierbare Profile für UI-, Browser- und Regionaltests bereitstellen.

Teamprozesse: Gruppen, Rollen und Namensregeln für kontrollierte Zusammenarbeit verwenden.

Interne Automatisierung: MCP und Local API kombinieren, wenn die Organisation die betroffenen Systeme autorisiert verwaltet.

Teamsicherheit und Least Privilege

Ein KI-Agent sollte nur die Rechte erhalten, die für die konkrete Aufgabe notwendig sind. Wer Profile lediglich auflisten und starten soll, braucht keine Möglichkeit, alle Profile zu löschen, globale Proxy-Einstellungen zu ändern oder Teamrechte zu verwalten.

Nutze Unterkonto-Beschränkungen, URL-Allow-/Blocklisten und Profilgruppen. Experimente gehören in eine separate Testumgebung, damit Fehler keine wichtigen Sitzungen oder Kundenprofile beeinflussen.

Dokumentiere Besitzer, Zweck, Region, freigegebenen Proxy und Gruppe jedes Profils. Eindeutige Namen wie QA_DE_01 oder CLIENT_A_RESEARCH reduzieren Fehlzuordnungen durch Menschen und Agenten.

Für kritische Aktionen sollten Logs und bei Bedarf menschliche Freigaben vorgesehen werden. Automatisierung darf Kontrolle verbessern, nicht die Nachvollziehbarkeit verringern.

Best Practices für den Betrieb

Fehlerbehebung

Fazit

BitBrowser MCP ergänzt isolierte Browserprofile um eine agentenorientierte Schnittstelle. Es geht nicht darum, jede klassische Automation zu ersetzen, sondern KI-Clients einen kontrollierten Zugriff auf unterstützte Browserverwaltungswerkzeuge zu geben.

Ein sicherer Start besteht aus Local API, Authentication Control, einem Read-only-Test und genau einem Testprofil. Danach können autorisierte Proxy-Konfigurationen, Schreibaktionen, Gruppen und wiederkehrende Prozesse schrittweise ergänzt werden.

Mit MCP, Local API, isolierten Profilen, Teamrechten, Proxys und Sicherheitsregeln kann BitBrowser 2026 als Browser-Orchestrierungsschicht für legitime KI-Workflows eingesetzt werden.

Offizieller BitBrowser MCP Guide •  BitBrowser 7.1.5 Release Notes •  BitBrowser Dokumentation

Häufig gestellte Fragen

Unterstützt BitBrowser MCP?

Ja. Aktuelle BitBrowser-Versionen ab der 7.1.5-Linie enthalten einen MCP-Dienst in Verbindung mit der Local API.

Welchen MCP-Endpunkt soll ich verwenden?

Nutze die Adresse deiner Installation. Das lokale Standardbeispiel ist typischerweise http://127.0.0.1:54345/mcp.

Ist Authentifizierung notwendig?

Ja. Authentication Control aktivieren und den x-api-key geheim halten.

Kann Cursor verbunden werden?

Ja. Die generierte BitBrowser-MCP-Konfiguration in Cursor hinterlegen und mit einem Read-only-Test beginnen.

Kann Claude verwendet werden?

Eine Claude-Umgebung mit Unterstützung benutzerdefinierter MCP-Server kann die passende BitBrowser-Konfiguration verwenden.

Ersetzt MCP die Local API?

Nein. MCP ist agentenorientiert, die Local API bleibt für deterministische Softwareprozesse wichtig.

Kann ein Proxy konfiguriert werden?

BitBrowser-Profile unterstützen Proxys. Nur autorisierte Endpoints verwenden und vor dem Workflow testen.

Wie starte ich am sichersten?

Read-only prüfen, ein Testprofil anlegen, Ergebnis kontrollieren und Rechte anschließend schrittweise erweitern.