One engine, three surfaces

browserlane is one engine behind three curated surfaces. The same WebDriver BiDi engine — the bl binary — answers to a human at a shell, to an agent over MCP, and to an agent that has been taught the CLI through a Skill. They drive Chrome the same way; they differ only in how you talk to them.

humans and scripts ── CLI ───────────────┐
                                         │
AI agents ────────── MCP ────────────────┼── bl engine ── WebDriver BiDi ── Chrome
                                         │
AI agents ────────── Skill ── CLI ───────┘

The three surfaces

The CLI is what you've seen throughout these docs. The MCP server, started with bl mcp, exposes the engine as a catalog of tools — register it once with bl add-mcp. The Skill, installed with bl add-skill, is one Markdown file that teaches an agent the CLI directly.

When to use which

• CLI — you're driving the browser yourself, scripting a repeatable task, wiring automation into CI, or prototyping a flow you'll hand to an agent.
• MCP — the agent has no shell, or you want browser actions exposed as first-class, individually described tools.
• Skill — the agent has shell access (e.g. Claude Code) and you want the smallest context footprint. The recommended default for CLI-capable agents.

Because every route ends at the same engine, a flow you work out by hand on the CLI behaves the same when an agent runs it through MCP or the Skill.

Curated surfaces, not spec mirrors

The engine's job is protocol coverage; the surfaces' job is ergonomics. The governing 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 the surfaces are not a 1:1 syntax mirror of each other or of the specification:

• The same verb can take a different shape. bl open takes an optional URL — omit it and it just launches a local browser (a convenience for humans). Its MCP counterpart browser_open requires a url, because a focused "navigate" tool is less ambiguous for an agent to call. To launch without navigating, an agent calls browser_start instead.
• Some single commands split into get/set tool pairs — bl viewport becomes browser_get_viewport plus browser_set_viewport.
• A few capabilities (like the page-clock controls) are MCP-only; the setup, daemon, and agent-wiring plumbing (bl install, bl daemon, bl add-mcp, bl add-skill) is CLI-only.
• Some protocol capabilities stay internal to the engine entirely — consumed events that power auto-waiting and recordings, for example. They count toward engine parity without earning a dedicated command or tool.

Related

• WebDriver BiDi — the engine's spec-parity story.
• Wire up an agent (MCP).
• MCP reference — the full tool catalog.
• Skill reference — what the agent reads.