brightdata-mcp: 69 Werkzeuge für Web-Zugriff als MCP-Server

Der eigentliche Engpass liegt nicht im Modell, sondern zwischen Modell und Seite

Ein Agent, der eine Seite lesen soll, scheitert selten an der Formulierung. Er scheitert an der Antwort: Bot-Erkennung, CAPTCHA, Rate-Limits, Geo-Sperren. Genau an dieser Stelle setzt brightdata-mcp an. Der Server ist ein Model-Context-Protocol-Backend, das einem MCP-Client Werkzeuge für Websuche, Seitenabruf, strukturierte Extraktion, Browser-Steuerung, LLM-Abfragen und Paket-Registry-Daten bereitstellt. Die Zielgruppe ist damit klar umrissen: Teams, die Agenten, Coding-Assistenten oder Chat-Oberflächen betreiben und diesen Systemen Live-Webdaten geben wollen, ohne die Unblocking-Schicht selbst zu bauen. Das Projekt selbst liefert nur den Server und die Tool-Definitionen. Die Arbeit, die eine Anfrage durch Bot-Erkennung, CAPTCHA-Lösung und Proxy-Rotation bringt, passiert laut README in der Infrastruktur von Bright Data, nicht im Repository.

Zwei Betriebsarten mit sehr unterschiedlicher Konsequenz für den Datenpfad

Der Server lässt sich auf zwei Wegen betreiben. Erstens als gehosteter Remote-Endpunkt: eine URL der Form https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN_HERE, eingetragen direkt im MCP-Client. Zweitens als lokale Instanz über npx @brightdata/mcp, gestartet aus der Client-Konfiguration heraus, wobei der Token als Umgebungsvariable API_TOKEN übergeben wird. Der Unterschied ist nicht kosmetisch. Im gehosteten Betrieb verlässt jede Anfrage, die der Agent stellt, die eigene Umgebung und läuft über die Server des Anbieters. Im lokalen Betrieb startet nur der MCP-Prozess auf der eigenen Maschine; die eigentliche Abrufarbeit läuft nach der Beschreibung weiterhin über die Bright-Data-Infrastruktur, weil dort Unblocking und Proxy-Rotation sitzen. Wer gehofft hat, mit npx eine unabhängige Variante ohne Anbieterbindung zu bekommen, wird enttäuscht. Die lokale Installation verändert den Startpunkt des Protokolls, nicht den Weg der Daten.

69 Tools sind kein Feature, sondern ein Kontextproblem

Das README nennt 69 Werkzeuge, gegliedert in Websuche über Google, Bing und Yandex, Seitenabruf als Markdown oder HTML, strukturierte Extraktion aus Amazon, LinkedIn, Instagram, TikTok, YouTube, X, Reddit, Facebook, Crunchbase und Zillow, Browser-Steuerung mit Navigation, Klick, Texteingabe und Screenshot, Abfragen an ChatGPT, Grok und Perplexity sowie npm- und PyPI-Metadaten. Für den Menschen klingt das nach Abdeckung. Für das Modell ist es eine Liste von 69 Funktionsbeschreibungen, die bei jedem Aufruf mitgeschickt wird. Deshalb sind die beiden URL-Parameter groups und tools wichtiger als ihre unscheinbare Position in der Tabelle vermuten lässt. Mit groups=social,ecommerce aktivieren Sie ganze Gruppen, mit tools=search_engine,scrape_as_markdown nur einzelne Werkzeuge. Das ist der einzige Mechanismus im gezeigten Material, mit dem sich die Werkzeugliste eines Agenten eingrenzen lässt. Wer ihn nicht nutzt, bezahlt die Vollauswahl in jedem Request mit Kontextfenster, und ein Modell mit 69 Optionen greift häufiger daneben als eines mit vier.

Ein Token, kein Proxy-Setup: so sieht die Einrichtung konkret aus

Der Token stammt aus den Bright-Data-Kontoeinstellungen, neue Konten erhalten laut README 5.000 Anfragen pro Monat ohne Kreditkarte. Für Claude Desktop nennt die Dokumentation den Weg über Settings, Connectors, Add custom connector mit Namen und URL, alternativ die lokale Variante mit command npx und args @brightdata/mcp. Für Claude Code ist es ein einzelner Befehl: claude mcp add --transport http brightdata "https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN". Cursor liest ~/.cursor/mcp.json und erwartet dort einen Eintrag mit url, VS Code liest .vscode/mcp.json mit type http und url. Windsurf nutzt ~/.codeium/windsurf/mcp_config.json und den Schlüssel serverUrl, Gemini CLI ~/.gemini/settings.json und httpUrl, Zed den Schlüssel context_servers mit url, Warp eine Einstellungsmaske. Die Feldnamen unterscheiden sich also je Client, und das ist die häufigste Fehlerquelle beim ersten Versuch: derselbe Endpunkt, drei verschiedene Schlüssel. Wer die Konfiguration kopiert, sollte den Schlüsselnamen prüfen, nicht nur die URL.

Das Kontingent ist die eigentliche Grenze, nicht die Technik

5.000 Anfragen pro Monat klingt großzügig, bis man den Verbrauch pro Aufgabe rechnet. Eine Recherche ist selten ein einzelner Aufruf. Sie beginnt mit search_engine oder search_engine_batch, führt zu mehreren scrape_as_markdown-Aufrufen und endet vielleicht in einer Browser-Sitzung. Jeder dieser Schritte zählt als Anfrage. Das README benennt weitere Einschränkungen ausdrücklich: Ungenutztes verfällt am Monatsende, es wird nicht übertragen, und bei Team-Konten teilen sich alle Nutzer dasselbe Kontingent. Fällt der Free Tier aus, stoppen Anfragen. Nachgeladen wird nur, wenn Geld eingezahlt wurde, weshalb das README das Setzen eines spend cap im Kontrollpanel empfiehlt. Die Browser-Navigation wird separat nach Volumen abgerechnet, mit 8 US-Dollar pro Gigabyte, während Suche, Scraping und Extraktion mit 1,50 US-Dollar pro 1.000 Ergebnisse gelistet sind. Ein Agent, der regelmäßig Screenshots erzeugt oder lange Sitzungen fährt, verbraucht also nach einer anderen Metrik als einer, der Text abruft. Diese Aufteilung sollte man kennen, bevor man Browser-Werkzeuge in eine Schleife einbaut.

Strukturierte Extraktion gegen generisches Scraping

Die interessanteste Design-Entscheidung ist die Aufteilung zwischen scrape_as_markdown und den vorgefertigten Extraktoren für Amazon, LinkedIn, Instagram, TikTok, YouTube, X, Reddit, Facebook, Crunchbase und Zillow. Der generische Weg liefert Markdown oder HTML und überlässt dem Modell das Parsen. Der zweite Weg liefert laut README sauberes JSON, ohne dass HTML geparst werden muss. Das ist ein echter Unterschied in der Zuverlässigkeit, aber auch in der Bindung. Vorgefertigte Extraktoren sind nur so gut wie die Pflege der Zielfelder, und wenn eine Plattform ihr Markup ändert, hängt die Korrektur beim Anbieter, nicht bei Ihnen. Gegenmodell: ein eigener Crawler mit Playwright und einem Extraktor, den Sie selbst anpassen. Der Preis dafür ist genau die Arbeit, die brightdata-mcp abnimmt: Proxy-Rotation, Bot-Erkennung, CAPTCHA-Behandlung, Retry-Logik. Ob sich das rechnet, hängt davon ab, wie viele verschiedene Domains Sie brauchen. Für eine einzige, stabile Quelle ist ein eigener Extraktor oft die günstigere und kontrollierbarere Wahl. Für ein Dutzend Plattformen mit wechselnden Sperrmechanismen kippt die Rechnung schnell.

Pflegeaufwand, Lizenz und die Frage der Datenhoheit

Das Repository steht unter MIT, der Code ist also frei verwendbar, veränderbar und weitergebbar. Diese Lizenz gilt für den MCP-Server. Sie gilt nicht für die dahinterliegende Infrastruktur, und das ist der Punkt, an dem die Lizenzfrage in eine Vertragsfrage übergeht. Der Dienst selbst ist kostenpflichtig jenseits des Free Tier, die Nutzung unterliegt den Bedingungen von Bright Data, und das README verweist für Preise, Volumenpläne und Enterprise auf eine separate Seite. Wer den Server forkt und lokal betreibt, ändert daran nichts, weil die Anfragen weiterhin über den Anbieter laufen. Auf der Wartungsseite ist das Projekt aktiv: die letzten Releases v2.11.1 vom 27. Juli 2026 und v2.11.0 vom 16. Juni 2026 liegen rund sechs Wochen auseinander, davor v2.9.3 vom 29. März 2026. Für ein Projekt, dessen Nutzen von der Anpassung an fremde Sperrmechanismen abhängt, ist diese Taktung das relevante Signal, nicht die Zahl der Tools. Ob und wie lange ältere Versionen unterstützt werden, geht aus dem Material nicht hervor. Auch die Frage, welche Daten der gehostete Endpunkt protokolliert, lässt sich mit dem README nicht beantworten, und für Teams mit strengen Vorgaben zur Datenverarbeitung ist das ein offener Punkt, der vor der Einführung geklärt werden muss, nicht danach.

Redaktionelles Fazit

Sinnvoll ist der Server für Teams, die einem Agenten oder einem MCP-fähigen Client echten Web-Zugriff geben wollen, ohne Proxy-Rotation, CAPTCHA-Behandlung und Retry-Logik selbst zu bauen, und die mit einem monatlichen Kontingent von 5.000 Anfragen planen können. Wer die Datenhoheit vollständig behalten muss, keine externe Abhängigkeit im kritischen Pfad will oder nur gelegentlich eine einzelne Seite liest, ist hier falsch und mit einem lokalen Extraktor oder einem Crawler im eigenen Netz besser bedient. Vor dem ersten produktiven Einsatz würde ich drei Dinge prüfen: ob der Client die Tool-Gruppen über den URL-Parameter groups tatsächlich berücksichtigt, wie sich die Anfragen pro Aufgabe auf das Kontingent auswirken und ob der Anbieter-Ausfall in Ihrem Ablauf tolerierbar ist. Steht danach die Entscheidung für den Server, gehört der spend cap im Bright-Data-Kontrollpanel zu den ersten Einstellungen, die Sie setzen.

Offizielle Quellen

1. brightdata/brightdata-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases