Was ändert sich im Workflow, wenn Browseraktionen an MCP ausgelagert werden, und welche Teile verschwinden aus dem Code? Dieser Erfahrungsbericht zeigt die Aufgabenteilung, vier typische Konfigurationsprobleme und eine sinnvolle Reihenfolge für die Fehlersuche.
Beim Schreiben von Browserautomatisierung mit Claude Code nervt zuerst der Glue-Code: Browser starten, Proxy anbinden, Umgebungen anlegen und auf Handles warten. Das hat wenig mit der eigentlichen Geschäftslogik zu tun und muss trotzdem immer wieder geschrieben werden. Wenn Browseraktionen über MCP ausgelagert werden, verschwindet dieser Teil weitgehend aus dem Code: Man beschreibt die Aufgabe, und das Modell entscheidet selbst, welches Tool es aufruft.
Wie die Aufgaben verteilt werden
Claude Code ist ein Coding-Assistent für die Kommandozeile. Er kann Dateien lesen und schreiben, Befehle ausführen und mit Git arbeiten. Seine Stärke liegt bei Code und Terminal. Direkt mit dem Browser zu interagieren ist weder seine Stärke noch seine Aufgabe.
Genau diese Lücke füllt MCP. Es verpackt die Fähigkeiten einer Browserautomatisierungsumgebung als Tools, die das Modell nach der Registrierung aufrufen kann: Umgebungen auflisten und anlegen, Browser starten und stoppen, Screenshots erstellen und Seiteninhalte lesen. Eine Seite kümmert sich um Code und Logs, die andere um Browser und Seiten. Mit dieser klaren Trennung lassen sich Fehler leichter eingrenzen.
Wie sich der Workflow verändert
Am deutlichsten wird die Veränderung beim Aufbau der gesamten Kette. Früher musste für jede Prozessänderung ein Skript angepasst werden. Heute kann man den Ablauf zunächst in natürlicher Sprache testen: vorhandene Umgebungen auflisten, sich in zwei davon anmelden, Screenshots erstellen und die Ergebnisse zusammenfassen. Erst wenn das funktioniert, wird daraus ein festes Skript.
In realen Projekten arbeiten meist drei Ebenen zusammen. MCP übernimmt Anweisungen in natürlicher Sprache und eignet sich für Erkundung und Ad-hoc-Aufgaben. Eine lokale HTTP-Schnittstelle übernimmt Massenaktionen, etwa das Anlegen von Dutzenden Umgebungen in einem Durchgang, und lässt sich stabil wiederholen. Für präzise Interaktionen, etwa auf einen bestimmten Zustand zu warten oder strukturierte Seitendaten zu erfassen, verbindet sich CDP direkt mit dem Browser. Die drei Ansätze konkurrieren nicht, sondern decken jeweils einen Abschnitt ab.
Die Umgebungsebene separat zu verwalten, war ebenfalls eine Erkenntnis aus dieser Phase. Wenn Umgebungen über verschiedene Skripte verteilt sind, wird die Fehlersuche mit wachsender Zahl an Aufgaben schnell unübersichtlich. Deshalb werden Umgebungen nun zentral über Umgebungs-Tools angelegt, angezeigt und in Gruppen aufgeräumt; ein Skript erhält nur noch eine Umgebungs-ID zur Nutzung. In Szenarien mit mehreren Konten übernimmt eine Isolationslösung wie PurpleMark genau diese Ebene: Umgebung, Sitzung und Cache jedes Kontos bleiben getrennt, damit die Ausführungsebene sie zuverlässig einplanen kann.
Vier typische Stolperstellen
Die erste Stolperstelle: Das Tool wird nicht erkannt. Viele Clients lesen ihre Konfiguration nur beim Start ein; nach der Registrierung ist daher ein Neustart nötig. Auch ein falscher Pfad zur Konfigurationsdatei kommt häufig vor, weil verschiedene Tools unterschiedliche Speicherorte verwenden. Eine einfache Diagnose ist erstaunlich wirksam: Den Dienst manuell starten. Läuft er, liegt das Problem eher an der Konfiguration; läuft er nicht, an der Umgebung.
Die zweite Stolperstelle ist eine fehlgeschlagene Authentifizierung. Häufig wurden beim Kopieren der Zugangsdaten versehentlich Leerzeichen oder Zeilenumbrüche übernommen. Das sollte zuerst geprüft werden. Danach lohnt sich ein Blick darauf, wie Umgebungsvariablen eingelesen werden, denn Betriebssystem und Startmethode können zu unterschiedlichen Ergebnissen führen.
Die dritte Stolperstelle: Die lokale Schnittstelle läuft nicht. Viele MCP-Dienste setzen voraus, dass der zugehörige Client aktiv ist. Ist der Client geschlossen, startet der Dienst entweder nicht oder die Verbindung läuft in einen Timeout. Zusätzlich sollte geprüft werden, ob der Port bereits belegt ist; übrig gebliebene Prozesse können ihn blockieren. Die Portnummer lässt sich in den Client-Einstellungen nachsehen.
Die vierte Stolperstelle sind konkurrierende Aufgaben, die sich gegenseitig stören. Ein einzelner Lauf funktioniert, doch parallel treten Datenvermischung oder kollidierende Anmeldesitzungen auf. Meist nutzen mehrere Aufgaben dieselbe Umgebung. Das lässt sich nicht wegdebuggen, sondern nur durch klare Regeln verhindern: eine Umgebung pro Aufgabe, Anlegen und Aufräumen über die Batch-Schnittstelle und keine spontanen Umgebungen im Skript.
Gewohnheiten beim Debugging
Wartebedingungen sollten in Anweisungen ausdrücklich genannt werden. „Auf Senden klicken“ enthält zu wenig Information. „Warten, bis die Schaltfläche Senden anklickbar ist, und dann klicken“ führt deutlich zuverlässiger zum Ziel. Das Modell entscheidet, was getan wird; der richtige Wartezeitpunkt muss vorgegeben werden.
Die Kette sollte zunächst mit schreibgeschützten Aufgaben geprüft werden. Umgebungen auflisten, Screenshots erstellen und Seitentext lesen haben keine Nebenwirkungen, testen aber in einem Durchgang Authentifizierung, Netzwerk und Dienst. Solange diese Kette nicht funktioniert, sollte man keine Aktionen mit Nebenwirkungen ausführen.
Zugangsdaten gehören nicht in den Code. Verwenden Sie Umgebungsvariablen oder lokale Konfigurationsdateien und nehmen Sie diese Dateien in die Ignore-Liste auf; bei personellen Änderungen im Team sollten Zugangsdaten rotiert werden. Wenn eine lokale Schnittstelle ihre eigene Prüfung deaktiviert hat, sollte sie mindestens nur auf dem lokalen Rechner lauschen und von außen nicht erreichbar sein.
Zum Schluss die Grenze des Ganzen: MCP verbindet die technische Kette, ändert aber keine Plattformregeln. Auch bei einer reibungslosen Integration gelten weiterhin alle Nutzungsbedingungen der jeweiligen Aufgabe.
