Turbo-browser-mcp batches browser actions into single MCP calls, claims up to 99% token savings

What the project does

turbo-browser-mcp is a new open-source Model Context Protocol (MCP) server built on Playwright, introduced through a Show HN post on Hacker News. Its goal is to attack two chronic costs of LLM-driven browser automation: token bloat and multi-turn latency. According to the project's README on GitHub, it collapses the 25 to 33 fine-grained primitives that typical Playwright- or DevTools-based MCP servers expose into 10 batched tools.

The underlying argument is that standard setups charge the agent a full model round-trip for every snapshot, field fill, dropdown choice, upload and verification check, and each turn re-sends the ever-growing conversation history back to the model. turbo-browser-mcp pushes that orchestration down into the tool layer.

The benchmark claims

The README ships a benchmark suite, run via npm run benchmark, that executes headless Chromium locally and counts tokens using OpenAI's o200k_base tokenizer through tiktoken 0.14.0. Reported figures include:

• A dense snapshot of a 140-button SaaS console costs 1,135 tokens in compact form versus 18,654 tokens of raw HTML, a 93.9% reduction, and 3,568 tokens for a full ARIA tree, a 68.2% reduction.
• A post-click delta snapshot, requested with onlyChanged set to true, returns 56 tokens of changed lines in 18 ms instead of a 3,582-token ARIA rescan.
• Filling a 10-field complex form plus a snapshot takes one turn, 82 ms and 811 tokens with smart_fill_form, against 11 turns, 574 ms and 12,197 direct tokens, or 98.9% cumulative savings, when done field by field.
• Uploading a 48 KiB PDF costs 85 tokens when passed as a disk path, versus 44,728 tokens for the same file inlined as Base64 in a tool argument.
• Opening six tabs concurrently in one batched call takes 420 ms, versus 998 ms across six sequential turns.
• The static tool schema itself is 3,010 tokens stripped down, compared with 3,917 tokens for a Playwright MCP server and 6,737 for a DevTools equivalent, and this overhead is paid on every turn.

The project also stresses that the real latency win exceeds the millisecond figures: removing ten round-trips on a form also removes ten separate LLM inference calls, estimated at two to five seconds each in agent loops, plus roughly 71,800 replayed history tokens. These are the project's own measurements, not an independent evaluation.

How the batching works

Three mechanisms carry most of the load. First, delta snapshots: an inspect_compact tool flattens the main frame, child iframes and open Shadow DOM into compact output with short element references, and a flag emits only the elements added or changed since the previous snapshot. The server injects an init script that hooks Element.prototype.attachShadow so that closed Shadow roots created after page load remain inspectable.

Second, single-turn form filling: smart_fill_form prefills an entire form in one call, including React-controlled inputs handled through native property setters and synthetic events, ARIA comboboxes and switches, contenteditable editors, Gmail compose dialogs, and controls inside iframes. A returnSnapshot option returns the updated form state in the same response, so verification does not require another round-trip.

Third, disk-side uploads: file paths are passed straight to Playwright's setInputFiles, keeping binary data and Base64 encoding out of model context entirely.

Guardrails and sessions

A Submit guard is enabled by default, pausing for human confirmation before irreversible actions, and batched action chains stop safely when the guard triggers. The server supports four connection modes, including attaching to an already-signed-in browser through the Chrome DevTools Protocol, persistent profiles, and per-tab isolated contexts with separate cookies and storage that can batch-open up to ten URLs at once. Network blocking presets round out the toolset; a preset the README calls turbo cut a 304 KiB media-heavy page load to zero media requests.

Why it matters

Browser control is fast becoming a default agent capability, and this project's numbers argue that the dominant costs are not browser execution, measured in milliseconds, but model context measured in tokens and inference round-trips measured in seconds. Batching primitives, diffing the DOM instead of rescanning it, and keeping binaries out of the context window are direct engineering responses to that cost structure. If the self-reported figures hold up under third-party testing, the pattern generalises well beyond browsers: any MCP server built from chatty, fine-grained tools could adopt the same delta-plus-batch design. It is also a concrete data point in a broader shift away from giving models more tools, toward giving them fewer but denser ones.