Jouw agenten besturen een echte browser.
Geen neppe.
AgentsRoom integreert een echte Chromium-browser in elk project en levert een AgentsRoom Browser MCP-server die jouw AI-agenten in staat stelt deze te besturen. Jouw QA-agent opent jouw localhost-site, klikt op de knoppen, vult de formulieren in, maakt schermafbeeldingen, leest de console en verifieert of de functie daadwerkelijk werkt voordat hij zegt dat het klaar is. End-to-end browserautomatisering voor Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe en Kimi Code, zonder Playwright-configuratie.
Combineer het met Agent Teams: een Dev-agent levert de functie, een QA-agent laadt de localhost-site in de ingebouwde browser, voert het verificatiescenario uit, maakt een schermafbeelding van het resultaat en keurt het goed. Native browserautomatisering staat ook op de roadmap, met toekomstige MCP-servers gepland voor React Native en Electron-apps zodat agenten ook mobiele en desktoptoepassingen kunnen testen.
AgentsRoom Browser MCP-demo: end-to-end webapp-testen aangestuurd door een Claude Code QA-agent via de ingebouwde Chromium-browser.
Browserautomatisering in AgentsRoom is twee dingen in één. Ten eerste, een echte Chromium-browser ingebed in elke projectruimte, met URL-balk, terug/vooruit, herladen, geschiedenis, schermafbeelding naar klembord, openen in standaardbrowser, persistente cookies en localStorage per project. Ten tweede, een AgentsRoom Browser MCP-server (agentsroom-browser) die die browser blootstelt aan jouw AI-agenten via het Model Context Protocol. De agent krijgt een schone, scriptbare interface: navigeren, klikken, typen, schermafbeelding maken, JavaScript evalueren, wachten op een element, de paginastatus ophalen, de consolelogs ophalen, teruggaan, vooruitgaan, herladen.
Waarom is dit belangrijk? Omdat de hele belofte van AI-coderingsagenten in duigen valt wanneer de agent zegt 'functie geleverd' maar nooit de pagina opent om te controleren. De meeste agenten vertrouwen tegenwoordig op het uitvoeren van unittests, en hopen dan maar. Met een echte browser MCP laadt de agent de localhost-server, doorloopt de gebruikersflow, ziet wat de menselijke gebruiker zou zien, en keurt het pas dan goed. De rol van QA Engineer-agent heeft eindelijk de tools die het nodig heeft om echte QA te doen, niet alleen statische analyse.
De technische setup is onzichtbaar voor jou. Wanneer je 'Browsertoegang' aanvinkt bij een agent, voegt AgentsRoom de agentsroom-browser-invoer toe aan het .mcp.json-bestand van jouw project en start de agent met de beschikbare browsertools. Een WebSocket-brug die draait op een loopback-poort (127.0.0.1, door het besturingssysteem toegewezen, bij elke start opnieuw gegenereerd, geauthenticeerd met een 32-byte hex-token) verbindt het MCP-subproces met de Chromium WebContentsView in de Electron-app. Elke klik, elke typeactie, elke schermafbeelding is een JSON-RPC-oproep. De agent ziet een echte browser, geen stub.
AgentsRoom Browserpaneel: URL-balk, geschiedenis, schermafbeelding, en volledige MCP-bedieningsoppervlak voor AI-agenten om te navigeren, klikken, typen en verifiëren.
Een echte browser, geen Playwright-stub
De meeste AI-agentdemo's die praten over browserautomatisering gebruiken een headless Playwright-instantie die bij elke tooloproep wordt gestart. Dat werkt voor benchmarks, maar is pijnlijk in het echte leven: je kunt niet zien wat de agent doet, elke navigatie start Chromium opnieuw, cookies gaan verloren, localStorage is leeg, jouw ontwikkelserver denkt dat elk bezoek een gloednieuwe sessie is. AgentsRoom kiest een andere invalshoek. De browser is al open in jouw projectruimte (je gebruikt het zelf, zoals een normale browser), en de agent bestuurt die browser. Sessies, cookies, localStorage, inlogstatus, alles blijft behouden.
Elke klik en typeactie van de agent triggert een echte native dispatch via Electron's WebContentsView, met juiste toetsevenementen, muisevenementen en DOM-mutaties. Schermafbeeldingen zijn echte PNG's vastgelegd van de daadwerkelijk gerenderde pagina (geen DOM-naar-afbeelding hack). Consolelogs worden gebufferd en doorzoekbaar, inclusief waarschuwingen en fouten. De agent ziet hetzelfde als jij zou zien als je de DevTools open had: echte prestaties, echt netwerkgedrag, echte CORS, echte authenticatie.
Kameroverschrijdende isolatie wordt afgedwongen. AgentsRoom creëert één Chromium WebContentsView per project, met zijn eigen sessiepartitie (persist:agentsroom-browser-<projectId>). De cookies van project A lekken nooit naar project B. Wanneer je van project wisselt, wordt de vorige browser verborgen en komt de nieuwe online met zijn eigen status. De agent landt altijd op het juiste project, met de juiste inloggegevens.
De MCP-laag is opzettelijk klein en afhankelijkheidsvrij. Het browser-mcp-server.cjs-subproces spreekt het MCP 2024-11-05-protocol via stdio (initialize, tools/list, tools/call) en vertaalt dit naar JSON-RPC-oproepen via de loopback WebSocket-brug. Vergeleken met een zware SDK-gebaseerde server blijft dit snel (eerste tooloproep is onder de 100 ms) en gemakkelijk te debuggen. Na elke actie die de pagina verandert (klikken, typen, navigeren, herladen, terug, vooruit), bevat de respons een base64 PNG-schermafbeelding beperkt tot 1,6 MB zodat de agent altijd het resultaat ziet van wat het net heeft gedaan. Dit bleek de grootste betrouwbaarheidsoverwinning te zijn: agenten die het scherm zien doen veel vaker het juiste dan agenten die hopen.
De Browser MCP-toolkit die jouw agenten krijgen
Elke AI-agent met browsertoegang start met deze tools beschikbaar. Ze worden blootgesteld via standaard MCP, zodat elke compatibele CLI ze ziet: Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code.
browser_navigate
Open een URL in de ingebouwde browser. Slimme URL-verwerking: localhost:3000 wordt http://localhost:3000 in plaats van een 'kan toepassing niet openen'-dialoogvenster te activeren. Retourneert de uiteindelijke URL en een schermafbeelding van de pagina na het laden.
browser_click
Klik op een element op basis van selector of zichtbare tekst. Echte native klikgebeurtenis, geen JavaScript-dispatch. Retourneert de schermafbeelding na de klik zodat de agent het resultaat van zijn actie ziet.
browser_type
Typ tekst in een invoer- of tekstvak. Ondersteunt sneltoetsen en verzenden. Echte toetsevenementen, de onChange-handlers van de pagina worden geactiveerd. Geeft de schermafbeelding terug na het typen.
browser_screenshot
Leg het huidige viewport vast als een PNG. Handig voor visuele regressiecontroles, ontwerp-kwaliteitscontrole, voor-en-na-vergelijkingen, of om de status van een bug te delen met de rest van het team.
browser_evaluate
Voer een JavaScript-expressie uit in de hoofdwereld van de pagina. Krijg het geserialiseerde resultaat terug. Gebruikt door agents om de paginastatus te lezen, de DOM te bevragen, een Redux-store te inspecteren, of een actie te activeren die geen zichtbare knop heeft.
browser_wait_for
Wacht tot een element verschijnt, de URL verandert, een netwerkverzoek voltooid is, of willekeurige JavaScript true retourneert. Vermijdt de klassieke 'agent klikt te snel' race.
browser_get_state
Lees de huidige URL, titel, viewport, scrollpositie en een gestructureerde momentopname van de toegankelijke elementen van de pagina. De primaire invoer van de agent wanneer deze zijn volgende actie moet plannen.
browser_get_logs
Haal de consolebuffer op (log, waarschuwing, fout). De agent kan dezelfde React-waarschuwingen, hydratatiefouten, netwerkstoringen en runtime-excepties zien die je in DevTools zou zien. Bugrapporten worden 'hier is de fout van de console'.
browser_go_back / forward / reload
Standaard browsernavigatie, scriptbaar. Gebruikt door agents om terug te gaan wanneer een stroom fout gaat, of om een pagina opnieuw te testen na een hot reload van Vite, Next.js of Expo Metro.
Wat agents daadwerkelijk doen met de browser
Echte workflows die je vandaag kunt bouwen, met de rol van QA Engineer en Agent Teams.
End-to-end rooktest bij elke overdracht
Verbind een Dev met een QA-team. De QA-agent navigeert naar je localhost dev-server, klikt door de kritieke paden (aanmelden, afrekenen, dashboard), maakt schermafbeeldingen van het resultaat en keurt alleen goed als er niets fout gaat. Vang regressies voordat een mens de pagina ooit opent.
Visuele regressie QA
Voor-en-na schermafbeeldingen bij UI-wijzigingen. De agent laadt de pagina op de vorige commit, maakt schermafbeeldingen, schakelt van branch, maakt schermafbeeldingen, vraagt Claude om te vergelijken. Goedkope visuele diff QA zonder Percy of Chromatic in de loop.
Consolefoutopsporing
De agent navigeert door de app, roept browser_get_logs aan, vindt React-hydratatiewaarschuwingen, useEffect-waarschuwingen, netwerk 404's, CORS-fouten, verouderingsmeldingen. Rapporteert ze als een lijst van risico's in de teamoverdracht, de volgende Dev-agent lost ze op.
Formulier validatietesten
De agent vult het formulier in met geldige gegevens, met lege velden, met randgevallen (XSS-strings, zeer lange invoer, niet-ASCII). Verifieert de validatieberichten, de netwerkverzoeken, de omleidingen. Echte formulier QA, geen unittests.
Toegankelijkheidsaudit
De agent doorloopt de pagina, bevraagt de toegankelijkheidsboom via browser_get_state en browser_evaluate, controleert alt-teksten, ARIA-attributen, focusbeheer, toetsenbordnavigatie. Rapporteert problemen met schermafbeeldingen.
Ontwerp QA tegen Figma
Combineer met de Figma naar AI agents functie. De agent laadt het Figma-frame, maakt schermafbeeldingen, laadt de localhost-pagina, maakt schermafbeeldingen, vergelijkt afstanden, lettertypen, kleuren, uitlijningen. Maakt een lijst van afwijkingen.
Live preview tunnel verificatie
Koppel met de AgentsRoom localhost tunnel. De agent navigeert naar de openbare HTTPS-preview-URL (niet localhost), verifieert dat de site bereikbaar is vanuit de buitenwereld, maakt schermafbeeldingen en bevestigt dat een belanghebbende de link daadwerkelijk kan openen.
Reproduceer een klantbug vanuit een openbaar backlogticket
Een openbaar backlogticket komt binnen met een URL en stappen om te reproduceren. De QA-agent opent de URL, volgt de stappen, legt de consolefout vast, voegt de screenshot bij en geeft het door aan Dev met een duidelijke reproductie. Geen 'kan niet reproduceren'-loops meer.
Wijs naar een element, stuur het direct naar de agent
De browser bedienen is slechts de helft van het verhaal. Soms ben jij degene die het probleem opmerkt: een knop die niet goed uitgelijnd is, een label met de verkeerde tekst, een kaart die breekt op mobiel. In plaats van het in woorden te beschrijven, wijs je ernaar. De ingebouwde browser heeft een wijsmodus: klik op elk element op de pagina en AgentsRoom legt de exacte CSS-selector vast uit de live DOM.
Voeg een korte notitie toe zoals 'verklein deze afstand' of 'verkeerde kleur hier', en het aangewezen element plus je annotatie worden naar de actieve agent gestuurd als een precieze, ondubbelzinnige wijzigingsverzoek. Geen 'de derde kaart van links' meer: de agent krijgt de selector, de omliggende context en je intentie in één keer.
Wijsmodus in de AgentsRoom browser: klik op een element, voeg een notitie toe, en de exacte selector plus je annotatie worden naar de agent gestuurd als een aangewezen wijziging.
Ga naar wijsmodus
Open de ingebouwde browser op je app en druk op de wijs-knop. Elk element licht op als je eroverheen zweeft.
Klik op het element
Klik op de knop, tekstblok of kaart die je wilt wijzigen. AgentsRoom vergrendelt erop en leest de exacte CSS-selector uit de live DOM.
Voeg een notitie toe en stuur
Typ wat er moet veranderen en bevestig. De selector, de omliggende context en je notitie worden aan de actieve agent overhandigd als een aangewezen wijziging.
Hoe een agent een browser krijgt
Open het Browsertabblad in je kamer
In je projectkamer onthult het rechterpaneel drie tabbladen: Bestanden, Wijzigingen, Browser. Klik op Browser. Het paneel wordt breder, de zijbalk klapt in en een echte Chromium-weergave verschijnt. Typ een URL of kies uit de projectgeschiedenis.
Vink 'Browser toegang' aan bij de agent
Open de Agent Bewerken-modus, breid Capaciteiten uit, vink Browser toegang aan. AgentsRoom voegt de agentsroom-browser vermelding toe aan de .mcp.json van je project en de agent zal de browsertools bij de volgende start zien.
<project>/.mcp.jsonDe agent start met de browser MCP
Bij het opstarten van de agent initialiseert Claude (of Codex, Antigravity, etc.) de agentsroom-browser MCP-server, somt zijn tools op (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload), en kan vanaf nu de browser aansturen.
De agent gebruikt de browser
De agent navigeert, klikt, typt, maakt screenshots, leest de console. Elke actie gaat via een loopback WebSocket-brug (127.0.0.1, door het OS toegewezen poort, 32-byte hex-token, opnieuw gegenereerd bij elke start van de desktop-app). Na elke pagina-wijzigende actie wordt een screenshot inline geretourneerd zodat de agent zijn beweging visueel kan verifiëren.
Automatisch localhost of je tunnel targeten
Als er een localhost-tunnel actief is, landt de eerste navigatie op de tunnel-URL. Anders de eerste gedetecteerde dev-server. Anders https://localhost:3000. Gecombineerd met Dev Terminals start de agent letterlijk de dev-server, opent deze vervolgens in de browser en test deze.
Verifiëren, screenshot maken, doorgeven
Wanneer aangesloten op Agent Teams, voert de QA-node zijn scenario's uit, maakt screenshots en stelt flags.qaPassed in de overdrachtspayload. De volgende agent erft het oordeel. Bij slagen gaat het naar de PM, bij falen gaat het terug naar Dev met de testaanwijzingen.
Onder de motorkap
Voor de nieuwsgierigen. De browserautomatiseringsstack is opzettelijk klein.
Elk project heeft één Chromium WebContentsView (de moderne Electron API, niet de verouderde BrowserView), overlaid op het hoofdvenster met grenzen gestreamd vanuit de React-renderer. Per-project sessiepartitie houdt cookies, localStorage en authenticatie geïsoleerd tussen projecten. Standaard offscreen-grenzen laten agents browsertools aanroepen zelfs voordat de mens het Browsertabblad opent, met een time-out van 5 seconden op screenshots om vastlopers te voorkomen.
Een lichte WebSocket-server (browser-bridge.ts) draait op een loopback-poort gekozen door het OS, gebonden aan alleen 127.0.0.1. Authenticatie gebruikt een 32-byte hex-token dat bij elke desktopstart opnieuw wordt gegenereerd. Het brugbestand ~/.agentsroom/browser-bridge.json bevat de huidige poort, token en PID, atomisch herschreven bij elke start, zodat het MCP-subproces altijd verse referenties oppikt met automatische herhaling.
De MCP-server zelf is browser-mcp-server.cjs, een zero-dependency Node-script dat het MCP 2024-11-05 protocol over stdio implementeert (initialize, tools/list, tools/call). Het spreekt JSON-RPC naar de WebSocket-brug via een handgemaakte WebSocket-client (geen ws, geen @modelcontextprotocol/sdk). Klein, snel, gemakkelijk te controleren. Gebundeld als een extraResources-bestand in de desktop-app, zodat elke installatie er klaar voor is.
Native browserondersteuning (een eersteklas browserfunctie buiten de MCP) staat op de AgentsRoom-roadmap. Verder omvat het langetermijnplan extra MCP's zodat agents ook niet-webdoelen kunnen aansturen: een React Native MCP voor mobiele apps en een Electron MCP voor desktop-apps. Zelfde idee, zelfde UX: de agent schrijft niet alleen code, maar oefent daadwerkelijk de draaiende app uit.
FAQ
Hoe verschilt dit van Playwright MCP of op Puppeteer gebaseerde browsertools?
Playwright- en op Puppeteer gebaseerde MCP's starten bij elke sessie een nieuwe headless browser. Dat is prima voor stateless taken, maar het verliest cookies, localStorage en authenticatie tussen oproepen, en de mens kan niet zien wat de agent doet. AgentsRoom Browser is dezelfde browser die de mens binnen de app gebruikt, met een persistente per-projectsessie, zichtbaar voor de gebruiker in realtime. De agent bestuurt een venster dat je op elk moment kunt zien en overschrijven. Het is een eerlijkere, beter te debuggen browserautomatisering.
Werkt dit met alle AI-providers, of alleen Claude Code?
Het werkt met elke provider die AgentsRoom ondersteunt: Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe en Kimi Code. Browsertools worden blootgesteld via het standaard Model Context Protocol, dat al deze CLI's lezen uit .mcp.json. De agent weet nooit dat het in AgentsRoom is, het ziet gewoon een set MCP-tools en gebruikt ze zoals het elke andere tool zou gebruiken.
Kan de agent een externe site aansturen, of alleen localhost?
Beide. Typ een URL en ga. Localhost (en host:port-vormen) worden slim gedetecteerd, voorafgegaan door http://, en direct geopend. Publieke sites werken zoals in elke normale browser, met cookies en inlogstatus per project bewaard. Gecombineerd met de AgentsRoom localhost-tunnel kan de agent ook je lokale dev-server aansturen via een openbare HTTPS-URL, wat handig is voor cross-netwerk en mobiele QA.
Is de browser MCP veilig? Wat voorkomt misbruik?
De brug bindt alleen aan 127.0.0.1, nooit aan 0.0.0.0. De poort wordt door het OS toegewezen (geen vaste poort voor botsingsgevoelige scanning). Een 32-byte hex-token is vereist bij elke verbinding, opnieuw gegenereerd bij elke desktopstart. Het MCP-subproces ontvangt de referenties alleen via omgevingsvariabelen, nooit in een vastgelegd bestand. Browsertoegang is opt-in per agent in de Agent Bewerken-modus. Als je het verwijdert, wordt de .mcp.json-vermelding verwijderd en kan de agent de tools niet meer gebruiken.
Ziet de agent de browserconsole (fouten, waarschuwingen, netwerk)?
Ja, via browser_get_logs. De buffer bevat console.log, console.warn en console.error berichten van de hoofdwereld van de pagina. Veel echte bugs (React hydration fouten, useEffect waarschuwingen, CORS fouten) komen alleen naar voren in de console, nooit in unit tests, dus dit blijkt een van de meest waardevolle tools voor de QA-agent te zijn.
Wat gebeurt er met de screenshots die naar de agent worden teruggestuurd? Kosten ze veel tokens?
Na elke actie die de pagina verandert, wordt een base64 PNG screenshot toegevoegd aan de toolrespons, met een limiet van 1,6 MB. Daarboven wordt in plaats daarvan een tekstmarkering verzonden. Screenshots zijn cruciaal voor betrouwbaarheid (een agent die het scherm ziet, maakt veel minder fouten), dus de afweging is de moeite waard. Als je screenshots wilt uitschakelen om budgetredenen, geven gewone browser_evaluate oproepen alleen tekst terug.
Kan de agent een inlogformulier invullen? Zijn sessie behouden?
Ja. Cookies en localStorage worden per project bewaard onder de persist:agentsroom-browser-<projectId> sessiepartitie. De agent kan eenmalig inloggen met browser_type en browser_click, en blijft ingelogd gedurende de rest van de sessie. Wanneer je van project wisselt, verandert de sessie, zodat inloggegevens nooit tussen projecten lekken.
Zal de agent vastlopen als de ontwikkelserver niet draait?
Het zal naar de URL navigeren en een Chromium-foutpagina zien. Het kan die fout lezen via browser_get_state en browser_get_logs en dienovereenkomstig reageren: je vragen om de server te starten, of een Dev Terminals commando aanroepen om het te starten. Met Agent Teams en Dev Terminals kun je een workflow opzetten die de server start, wacht, en vervolgens de browser opent, allemaal zonder menselijke tussenkomst.
Worden mobiele apps en desktopapps ook ondersteund?
Web wordt vandaag geleverd, via de ingebouwde Chromium en de AgentsRoom Browser MCP. De roadmap omvat een native AgentsRoom Browser als een eersteklas browserfunctie. Verder zijn er extra MCP-servers gepland: een React Native MCP zodat agents iOS en Android Expo-bundels kunnen aansturen, en een Electron MCP zodat agents desktopapps kunnen aansturen die geen web zijn. Dezelfde agentlogica, toegepast op niet-webdoelen.
Kan de mens de agent pauzeren en de browser overnemen?
Ja. De browser is dezelfde Chromium-weergave die de mens gebruikt. Op elk moment kun je in het Browser-paneel klikken en heb je de controle. Zodra je stopt met interactie, kan de agent zijn tooloproepen hervatten. Er is geen concept van 'agent-vergrendelde browser', het is een gedeeld oppervlak, precies zoals een pair-programmeringssessie.
Over: Agent Delegatie
Laat een goedkopere QA-agent de browser bedienen, niet je ontwikkelagent
De Browser MCP schittert het meest wanneer de ontwikkelagent het niet direct aanstuurt. Agentdelegatie stuurt de browsertest naar een aparte, goedkopere QA-agent via een enkele run_qa_test MCP-oproep. Je Opus of Codex blijft gefocust op het leveren van code, de QA-agent doet de klikken op een kleiner model, het oordeel komt terug als één regel. Dezelfde Browser MCP, lagere rekening, schonere context.
Lees de Agent Delegatie paginaGeef je agents echte browserogen
Vink Browser toegang aan bij elke agent in AgentsRoom. De Browser MCP start automatisch op. Je QA-agent test eindelijk wat het levert.
Companion-app: houd je agents onderweg in de gaten
Breng je eigen: Claude, Codex, Antigravity CLI of andere AI-provider.
Stuur bugs en verzoeken direct naar je openbare backlog.
Een glimp van AgentsRoom in actie.