Turbo-Browser-MCP Consolidates Browser Primitives into 10 Batched Tools
Turbo-Browser-MCP is a Playwright-based MCP server that consolidates 25-33 fine-grained browser primitives into 10 batched tools, cutting token waste and multi-turn latency via delta DOM snapshots, single-turn form prefill and direct disk file uploads. Benchmarks show dense UI snapshots dropping from 18,654 to 1,135 tokens and post-click deltas at just 56 tokens, with a human-in-the-loop submit guard enabled by default.
Related Entities
Full Report
Contents2 sections
turbo-browser-mcp
turbo-browser-mcp is a Playwright-based Model Context Protocol (MCP) server built to cut LLM token waste and multi-turn latency in browser automation. It consolidates 25-33 fine-grained browser primitives into 10 batched tools featuring delta DOM snapshots, single-turn React/Shadow DOM/iframe form prefill, direct disk file uploads (no Base64 in context), parallel tab sessions, network blocking presets, and a default human-in-the-loop Submit guard.
At-a-Glance Performance & Token Scorecard
All figures below come from benchmarks/benchmark.mjs (npm run benchmark) running headless Chromium locally with exact OpenAI o200k_base tokenization (tiktoken 0.14.0):
| Capability | Typical Baseline | turbo-browser-mcp | Speed / Turn Gain | Token Savings (o200k_base) |
|---|---|---|---|---|
| Dense UI Snapshot (140-btn SaaS console) | 18,654 tok HTML / 3,568 tok full ARIA | 1,135 tok compact (28 ms) | 1 call | 93.9% vs HTML (68.2% vs ARIA) |
Post-Click Delta Snapshot (onlyChanged: true) | 3,582 tok full ARIA rescan | 56 tok changed lines (18 ms) | 1 call | 98.4% vs ARIA (99.7% vs HTML) |
10-Field Complex Form + Snapshot (smart_fill_form) | 11 turns (574 ms, 12,197 dir / 72,614 cum tok) | 1 turn (82 ms, 811 tok) | 7x faster, 11 -> 1 turns | 93.4% direct / 98.9% cumulative |
48 KiB PDF Upload (49,152 bytes) | 44,728 tok inline Base64 tool arg | 85 tok disk path (68 ms) | Zero Base64 generation | 99.8% saved |
6-Step Interactive UI Flow (batch_actions) | 6 turns (411 ms, 955 dir / 3,162 cum tok) | 1 turn (357 ms, 406 tok) | 1.15x faster, 6 -> 1 turns | 57.5% direct / 87.2% cumulative |
Open 6 Tabs Concurrently (open_many) | 6 turns sequential (998 ms) | 1 turn batched (420 ms) | 2.38x faster, 6x fewer turns | 5 fewer prompt replays |
Heavy Media Load (preset: "turbo", 304 KiB assets) | 252 ms, 9 media requests (304 KiB) | 165 ms, 0 media requests (0 KiB) | 1.53x faster | 100% media bandwidth cut |
Article Markdown Scraping (extract_clean_text) | 3,595 tok raw HTML (10,844 chars) | 156 tok clean Markdown (641 chars) | Clean reader output | 95.7% saved |
Diagnostics Triage (page_diagnostics errors-only) | 3,460 tok unfiltered (32 req / 26 console) | 601 tok default errors (2 req / 6 console) | Zero noise scrolling | 82.6% saved |
| Static MCP Tool Schema (every turn overhead) | 3,917 tok Playwright / 6,737 tok DevTools | 3,010 tok stripped (3,314 full w/ annotations) | 10 tools vs 25 / 33 | 23.2% vs Playwright / 55.3% vs DevTools |
Note on latency vs LLM inference turns: Eliminating
10round-trips on a 10-field form saves both7xin browser execution (574 ms -> 82 ms) and10separate LLM inference round-trips (2-5sper turn in agent loops) plus~71,800replayed history tokens.
Why Browser Agents Stall: Side-by-Side Workflow
Standard MCP servers charge an LLM round-trip for every snapshot, field fill, <select> choice, upload, and verification check. Each turn re-sends the growing conversation history back into the model.
（注：更多技术实现细节与完整 API 文档请查阅原项目 README）