Vercel's agent-browser: Waarom een CLI MCP Verslaat voor Browser Automation

Vercel's agent-browser haalde 22.000 GitHub-sterren in twee maanden. Het is een browser automation tool specifiek gebouwd voor AI agents, geschreven in Rust, die direct via CDP met Chrome verbindt. Maar het interessante is niet de star count of de taalkeuze. Het is wat ze bewust niet hebben gebouwd: een MCP-server.

In een wereld waar elke tool MCP-integraties shipt, koos Vercel de andere richting. Ze bouwden een CLI. Een simpele, saaie, Unix-philosophy CLI die commando's accepteert en tekst naar stdout schrijft. En de performancedata maakt het lastig om daar iets tegenin te brengen.

De Context Window-Belasting

Browser automation via MCP heeft een tokenprobleem. Volgens community-benchmarks laadt Playwright MCP bij het starten van een sessie naar schatting ~13.700 tokens aan tool-definities in het context window van de agent, nog voor er ook maar één pagina bezocht is. Chrome DevTools MCP is naar verluidt erger met ~17.000 tokens. Dat is ruwweg 9% van een 200K context window verbruikt voordat de agent iets nuttigs doet.

Dan zijn er de kosten per actie. In een empirische test van Engin Diri bij Pulumi woog een enkele Playwright MCP klik-response 12.891 tekens. Dezelfde klik via agent-browser? Zes tekens: Done. Paginacomplexiteit speelt mee, maar het ordeverschil is consistent.

Over een echte workflow stapelt dit snel op. Third-party benchmarks schatten de tokenkosten van een 10-staps automatiseringsflow over drie tools:

94% tokenreductie. Dat is het verschil tussen een agent die na drie pagina's door z'n context heen is en een die een complete multi-step workflow afrondt met ruimte over.

Hoe agent-browser Werkt

De architectuur heeft twee hoofdlagen. Een Rust CLI handelt argument-parsing af in minder dan een milliseconde. Daarachter draait een native Rust daemon die direct met Chrome communiceert via CDP (Chrome DevTools Protocol), zonder Node.js of Playwright. De daemon blijft warm draaien tussen commando's via Unix domain sockets, wat browser-startupkosten elimineert. Je kunt Chrome ook vervangen door Lightpanda, een headless browser geschreven in Zig die volgens eigen benchmarks ruwweg 10x snellere performance en 10x minder geheugengebruik claimt.

Het eerste commando in een sessie kost ongeveer 500ms om de daemon te starten en de browser te lanceren. Daarna draait elk commando in sub-100ms. Vergelijk dat met Playwright MCP, waar elke actie een volledige JSON-RPC round-trip vereist met tool-schema's, parameters en uitgebreide response-objecten.

Snapshots en Refs: De Kerninnovatie

De ontwerpkeuze die alles laat werken is het snapshot + refs systeem. In plaats van CSS-selectors, XPath of volledige DOM-dumps, vangt agent-browser de accessibility tree van de pagina op, filtert op interactieve elementen, en kent elk element een stabiele referentie toe.

button "Sign In" [ref=e1]
textbox "Email" [ref=e2]
textbox "Password" [ref=e3]
link "Forgot password?" [ref=e4]
link "Create account" [ref=e5]

Vijf elementen, vijf refs. De agent zegt agent-browser click @e1 om op Sign In te klikken, of agent-browser fill @e2 "user@example.com" om een e-mailadres in te vullen. Geen CSS-selectors. Geen pixelcoordinaten. Geen vision model dat een screenshot parst. Refs worden opgelost door matching op accessibility role en name via CDP's Accessibility API, conceptueel dezelfde aanpak als Playwright's getByRole .

Ter vergelijking, dit is wat Playwright MCP teruggeeft voor een vergelijkbare pagina:

- heading "Welcome back" [level=2]
  - paragraph: "Sign in to your account"
- form:
  - textbox "Email" [required] (ref=s1e4)
  - textbox "Password" [required] (ref=s1e5)
  - button "Sign in" (ref=s1e6)
- navigation:
  - link "Forgot password?" (ref=s1e7)
  - link "Create account" (ref=s1e8)
  - link "Terms of Service" (ref=s1e9)
  - link "Privacy Policy" (ref=s1e10)
  ... (gaat door voor hele pagina)

Playwright MCP dumpt de volledige accessibility tree. Elke heading, paragraaf, landmark en decoratie op de pagina. agent-browser's -i flag (interactive only) filtert het tot alleen de elementen waar je daadwerkelijk op kunt klikken, in kunt typen of kunt toggling. In Engin Diri's tests was een homepage-snapshot ~280 tekens met agent-browser versus ~8.247 met Playwright MCP. Je cijfers zullen variëren per paginacomplexiteit, maar het patroon houdt stand.

De Accessibility Tree, Opnieuw

Als je ons stuk over hoe AI agents je website zien hebt gelezen, voelt dit bekend. De accessibility tree is de door de browser gegenereerde vereenvoudigde weergave van je pagina: roles, names, states, descriptions. Oorspronkelijk gebouwd voor schermlezers, nu de primaire interface voor AI agents bij elk groot framework.

agent-browser maakt deze connectie expliciet. Het snapshot commando is een accessibility tree query. Wanneer een agent agent-browser snapshot -i aanroept, krijgt het dezelfde tree die schermlezers consumeren en die Playwright-tests queryen met getByRole . Het enige verschil is het outputformaat: compacte tekst in plaats van YAML.

De implicaties voor website-eigenaren zijn niet veranderd. Als je button een <div onclick> is in plaats van een <button>, verschijnt het niet in de snapshot. Als je formuliervelden geen labels hebben, ziet de agent textbox "" en heeft geen idee wat er ingevuld moet worden. Als je navigatie is opgebouwd met niet-semantische divs, kan de agent je pagina's niet vinden. Dezelfde regels als eerder, maar nu met een tool waar 22.000+ developers naar kijken.

De annotated screenshot-functie maakt dit nog tastbaarder. agent-browser screenshot --annotate legt genummerde labels over elk interactief element, waarbij elk label naar een ref verwijst. Het is een visuele debugger voor je accessibility tree. Multimodale AI-modellen kunnen redeneren over layout terwijl ze dezelfde deterministische refs gebruiken voor interactie.

Less Is More: De Contra-intuïtieve Data

De ontwerpfilosofie achter agent-browser weerspiegelt bevindingen uit Vercel's eigen D0 text-to-SQL agent-onderzoek. Beide projecten delen hetzelfde moederbedrijf en dezelfde kerninzicht: minder tooling, beter redeneren. De D0-resultaten zijn oprecht verrassend. Ze testten twee architecturen: een met 17 gespecialiseerde tools en een met slechts 2 general-purpose tools.

De 17-tool versie: 80% slagingspercentage, 274,8 seconden uitvoeringstijd, ~102.000 tokens verbruikt. De 2-tool versie: 100% slagingspercentage, 77,4 seconden, ~61.000 tokens. Minder tools, hoger slagingspercentage, snellere uitvoering, lagere kosten. Elke metriek verbeterde.

Vercel's D0-team in eigen woorden: "We were constraining reasoning because we didn't trust the model to reason." Agents 17 specifieke tools geven dwong ze om bij elke stap de "juiste" te kiezen. Ze 2 flexibele tools geven liet ze zelf de beste aanpak uitzoeken. agent-browser past hetzelfde principe toe op de browser: minimale output, minimaal tool-oppervlak, maximale reasoning-ruimte.

Dit sluit aan bij wat Andrej Karpathy betoogde over CLI's als de ideale agent-interface . CLI's zijn inherent simpel. Flags, stdin, stdout. Geen tool schema-onderhandeling, geen capability discovery-dans. De agent voert een commando uit en leest de output. agent-browser nam die filosofie en paste het toe op de browser: 50+ commando's, maar elk doet precies één ding en geeft de minimale output terug die nodig is.

Wat Dit Betekent voor je Website

agent-browser wint snel aan adoptie. Het werkt met Claude Code, Cursor, GitHub Copilot, OpenAI Codex, Google Gemini, en elke andere agent die shell-commando's kan uitvoeren. Geen MCP-configuratie nodig. Gewoon npm install -g agent-browser. Dat betekent dat meer AI agents je site gaan browsen via de accessibility tree, of je daar nu voor geoptimaliseerd hebt of niet.

Dezelfde patronen die je site laten werken met Playwright MCP gelden hier. Semantische HTML, correcte formulierlabels, accessible names op knoppen en links, een schone heading-hiërarchie. Maar agent-browser maakt de feedbackloop nog strakker. Wanneer een agent snapshot -i draait op je homepage en twee refs terugkrijgt in plaats van twaalf, weet je precies waar het probleem zit.

Onze scanner meet precies deze signalen. Elk checkpoint in de Content & Semantics categorie verwijst direct naar wat agent-browser kan parsen: semantische HTML (3.3), heading-hiërarchie (3.2), alt-tekst (3.5), ARIA-gebruik (3.4), formulierlabels (4.6), beschrijvende links (3.7) en SSR-detectie (3.1). Een hoge score op die checkpoints correleert direct met een rijkere accessibility tree, en dus meer refs waar agent-browser mee kan werken.

agent-browser wordt geleverd met een AGENTS.md-bestand en een skills/-directory die AI coding agents direct consumeren om de commandoset te leren. Het ondersteunt ook multi-session isolatie met aparte sockets, cookies en ref-caches per sessie, zodat agents parallel kunnen werken zonder elkaar te storen. Met meerdere releases per dag en honderden open issues beweegt dit project snel. En het trekt de browser automation-ruimte naar een duidelijke conclusie: de accessibility tree is de interface, en eenvoud wint van feature count.

Bronnen

• vercel-labs/agent-browser — GitHub — 22.000+ sterren, Apache-2.0, Rust CLI voor AI browser automation
• agent-browser.dev — Officiële Documentatie — Commando's, architectuur, engine-ondersteuning (Chrome, Lightpanda)
• Why agent-browser Is Winning the Token Efficiency War — DEV Community — Benchmarkvergelijking: tokenverbruik over 10-staps flow
• Self-Verifying AI Agents: agent-browser in Practice — Pulumi — Empirische tokenvergelijking: 12.891 tekens (Playwright MCP) vs 6 tekens (agent-browser) per klik
• DeepWiki — agent-browser Architectuuranalyse — Native Rust daemon, snapshot + refs systeem, ref-resolutie via CDP
• We Removed 80% of Our Agent's Tools — Vercel — D0-onderzoek: 17 tools (80% succes) vs 2 tools (100% succes)
• IsAgentReady: Hoe AI Agents je Website Zien — De Accessibility Tree Uitgelegd
• IsAgentReady: Playwright — Van Testrunner naar AI Agent-Interface
• IsAgentReady: Build for Agents — Waarom CLI's het Nieuwe Distributiekanaal Zijn