Overview
What browserlane is — the Browser Automation Engine for AI Agents — and how to use it through the CLI, MCP, and Skill surfaces.
browserlane is the Browser Automation Engine for AI Agents. It packages
browser automation into one Rust binary, bl, that
drives Chrome over the W3C-standard WebDriver BiDi protocol — and is
distributed through three supported surfaces over that one engine:
- A CLI for humans and scripts —
bl open,bl click,bl screenshot,bl expect,bl record, and more, with structured JSON output and real exit codes. - An MCP server for AI agents —
bl mcpspeaks JSON-RPC 2.0 over stdio, exposing structured tools that represent useful intentions. - A Skill for token-efficient agents —
bl add-skillinstalls one file that teaches a shell-capable agent the CLI. It is not a separate engine; it reuses the CLI surface with a fraction of the context cost.
Everything runs on your machine — no cloud: the browser, sessions, data, and every captured artifact stay local. Chrome is the supported browser.
Built toward complete specification parity
The engineering objective is 100% capability parity with the official WebDriver BiDi specification — every module, every command, every event — and the progress is tracked in public: what is implemented, how, what stays internal, what is verified on Chrome, and what is still missing.
The tracking follows one principle:
Every WebDriver BiDi capability must be reachable through the engine. Only capabilities representing a useful user intention should receive dedicated CLI commands or MCP tools.
So engine parity and surface exposure are separate concerns: the CLI and MCP are curated interfaces, not 1:1 mirrors of the specification, and a missing dedicated command is not necessarily an engine gap. See WebDriver BiDi for the full story.
Why WebDriver BiDi
Most agent-facing browser tools sit on the Chrome DevTools Protocol (CDP) — Chrome's vendor-specific side-channel, the same plumbing Playwright and Puppeteer use underneath. browserlane instead drives the browser over WebDriver BiDi, the bidirectional W3C standard. Building on a protocol with a public specification is what makes honest, capability-level parity tracking possible: "complete" has an external definition.
What makes it different
One static binary, no runtime
bl ships as a single native executable for macOS, Linux, and Windows.
There is no Node or JVM runtime to install — download it, put it on your
PATH, and run.
Public BiDi parity
Every specification capability is accounted for — implemented, internal, exposed, or still missing — with Chrome verification tracked separately from implementation.
Three surfaces, one engine
CLI, MCP, and Skill are curated ways into the same engine. A flow you prototype by hand behaves the same when an agent runs it.
Evidence on every run
Assertions with real exit codes, structured diffs, and recordings that carry console and network context — captured locally.
Three ways to start
Pick the on-ramp that matches how you want to use browserlane:
Start with the CLI
Drive a real browser yourself — navigate, screenshot, map elements, click, read text, and assert.
Connect through MCP
Register the MCP server with your coding agent and let it drive Chrome through structured tools.
Install the Skill
Teach a shell-capable agent the CLI with one file — the token-efficient route to the same engine.
New to browserlane? Start with Install.