Silbercue/public-browser

Silbercue

TypeScript18updated 1mo ago

Lets Claude Code and Cursor drive Chrome. Blind benchmark vs agent-browser: -33% tokens, -33% cost, -24% tool calls, +48% speed, 30/30. Direct CDP, a11y-tree refs, server-side plan executor. MIT, no paid tier.

ClaudeCodexCursorMCP

agentic-aiai-agentbrowser-automationcdpchromechrome-devtools-protocolclaude-codecursorllm-toolsmcpmcp-servermodel-context-protocol

View on GitHub

README

<img src="https://raw.githubusercontent.com/Silbercue/public-browser/master/.github/assets/logo-400.png" width="30" alt=""> Public Browser

Lets Claude Code and Cursor drive Chrome — with your real, logged-in profile. On the same 30-test benchmark page it used 30% fewer tokens, 25% less money, 41% fewer tool calls and 40% less time than Playwright MCP at the same pass rate — two runs each, 2026-09-03, driver Claude Opus 5, raw data in the repo (Benchmarks, including where it loses). Its own tool definitions are 34% smaller since v2.10.4 (7,607 → 4,990 tokens, reproduce with node scripts/token-count.mjs). Direct CDP, a11y-tree refs, multi-tab ready — 2,360 TypeScript tests, 237 Python tests.

Built for Claude Code, Cursor, and any MCP-compatible client.

Looking for an alternative to Playwright MCP, Browser MCP, or claude-in-chrome? Public Browser talks to Chrome directly via the DevTools Protocol — no Playwright dependency, no Chrome extension bridge, no single-tab limit. One command to install, zero config. See benchmark comparison below.

Why Public Browser?

Every Chrome MCP server has the same problem: bulky responses, too few reliable refs. Screenshots return 10-30x more context payload than text trees. Selector-based refs break the second the DOM rerenders. Extension bridges (Browser MCP) get stuck on t