Wat verandert er in de workflow wanneer browseracties aan MCP worden uitbesteed, en welke delen verdwijnen uit de code? Dit praktijkoverzicht behandelt de taakverdeling, vier veelvoorkomende configuratieproblemen en een handige volgorde voor het oplossen ervan.
Bij browserautomatisering met Claude Code begint vooral de glue code snel te storen: de browser starten, een proxy koppelen, omgevingen aanmaken en op handles wachten. Dat heeft weinig met de bedrijfslogica te maken, maar moet toch telkens opnieuw worden geschreven. Zodra browseracties via MCP worden uitbesteed, verdwijnt dit grotendeels uit de code. Je beschrijft wat er moet gebeuren en het model bepaalt zelf welke tool het aanroept.
Hoe de verantwoordelijkheden worden verdeeld
Claude Code is een coding-assistent voor de opdrachtregel. Het kan bestanden lezen en schrijven, opdrachten uitvoeren en met Git werken. De kracht ligt aan de kant van code en terminal. Rechtstreeks met de browser werken is niet waar het goed in is en hoort ook niet zijn verantwoordelijkheid te zijn.
MCP vult precies dat gat. Het verpakt de mogelijkheden van een browserautomatiseringsomgeving als een reeks tools die het model na registratie kan aanroepen: omgevingen tonen en maken, browsers starten en stoppen, screenshots maken en pagina-inhoud lezen. De ene kant beheert code en logs, de andere browser en pagina’s. Met die duidelijke grens is ook beter te bepalen waar een probleem zit.
Hoe de workflow verandert
Het duidelijkste verschil is hoe snel de hele keten kan worden opgebouwd. Vroeger betekende een proceswijziging dat een script moest worden aangepast. Nu kun je het eerst in natuurlijke taal proberen: toon de beschikbare omgevingen, log in op twee ervan, maak screenshots en vat de resultaten samen. Werkt de flow goed, dan leg je hem daarna vast in een script.
In echte projecten werken meestal drie lagen samen. MCP verwerkt opdrachten in natuurlijke taal en is geschikt voor verkenning en tijdelijke taken. Een lokale HTTP-API voert bulkacties uit, zoals tientallen omgevingen tegelijk aanmaken, met stabiel gedrag en eenvoudige retries. Voor fijnmazige interacties, zoals wachten op een bepaalde status of gestructureerde data uit een pagina halen, kan CDP rechtstreeks met de browser verbinden. De drie aanpakken botsen niet; elk beheert een ander deel van de workflow.
Ook het apart beheren van de omgevingslaag werd in deze fase duidelijk. Wanneer omgevingen over verschillende scripts verspreid zijn, wordt probleemonderzoek lastig zodra het aantal taken groeit. Nu worden omgevingen centraal aangemaakt, bekeken en in batches teruggewonnen met tools op omgevingsniveau, terwijl een script alleen een omgevings-ID krijgt om te gebruiken. In scenario’s met meerdere accounts vervult een isolatieoplossing zoals PurpleMark precies deze laag: de omgeving, sessie en cache van elk account blijven gescheiden zodat de uitvoeringslaag ze betrouwbaar kan plannen.
Vier plekken waar het vaak misgaat
De eerste is dat een tool niet wordt herkend. Veel clients lezen configuratie alleen bij het opstarten, dus na registratie is een herstart nodig. Een fout pad naar het configuratiebestand komt ook vaak voor, omdat verschillende tools verschillende locaties gebruiken. Een eenvoudige maar effectieve test is de service handmatig starten. Start hij wel, dan ligt het waarschijnlijk aan de configuratie; start hij niet, dan ligt het aan de omgeving.
De tweede is mislukte authenticatie. De meest voorkomende oorzaak is dat bij het kopiëren van gegevens per ongeluk een spatie of regeleinde is meegenomen. Controleer dat eerst en kijk daarna hoe omgevingsvariabelen worden ingelezen. Het resultaat kan verschillen per besturingssysteem en startmethode.
De derde is dat de lokale API niet draait. Veel MCP-services zijn afhankelijk van de clientapplicatie zelf. Als de client niet actief is, start de service mogelijk niet of loopt de verbinding in een timeout. Controleer ook of de poort al bezet is; een achtergebleven proces kan die nog vasthouden. Het poortnummer is te vinden in de clientinstellingen.
De vierde is dat gelijktijdige taken elkaar beïnvloeden. Eén taak werkt prima, maar zodra meerdere taken tegelijk draaien raken gegevens door elkaar of overschrijven inlogsessies elkaar. Meestal delen meerdere taken dezelfde omgeving. Dit los je niet op met debugging, maar met een regel: één omgeving per taak, en het aanmaken en terugwinnen van omgevingen via de batch-API in plaats van ad hoc in scripts.
Enkele gewoonten bij het debuggen
Maak wachtvoorwaarden expliciet in de opdracht. “Klik op de verzendknop” bevat te weinig informatie. “Wacht tot de verzendknop klikbaar is en klik dan” werkt merkbaar betrouwbaarder. Het model bepaalt wat er moet gebeuren, maar jij moet aangeven wanneer het moet wachten.
Begin met read-only taken om de keten te testen. Omgevingen tonen, screenshots maken en paginatekst lezen hebben geen bijwerkingen, maar controleren tegelijk authenticatie, netwerk en service. Als de keten niet werkt, begin dan niet meteen met acties die wel bijwerkingen hebben.
Zet inloggegevens niet in code. Gebruik omgevingsvariabelen of lokale configuratiebestanden en voeg die bestanden toe aan de negeerlijst; roteer inloggegevens wanneer het team verandert. Als een lokale API zijn eigen validatie heeft uitgeschakeld, zorg er dan minstens voor dat hij alleen op de lokale machine luistert en niet extern toegankelijk is.
Tot slot de grens: MCP verbindt de technische keten, maar verandert de regels van het platform niet. Hoe soepel de integratie ook loopt, de taak moet nog steeds aan alle toepasselijke servicevoorwaarden voldoen.
