Your Agent Starts from Scratch Every Time It Operates the Browser—Someone Built a Key to Directly Open the Door You’re Already Using

104,401 stars. That's the GitHub number for browser-use—the brightest star in the AI browser automation track.

But there's a problem almost nobody mentions: these tools all operate "someone else's browser".

Every time it starts, the agent opens a clean browser instance from scratch—logging in again, loading again, locating pages again. The Xiaohongshu backend, CSDN editor, or enterprise management system you already have open in Chrome? The agent can't see any of them. There's always a wall between the agent and your real working environment.

CDP Bridge MCP is here to tear down that wall. 272 stars, MIT license, and one core idea: let the agent directly operate the browser you're already using.

Architecture: Three Bridges, Not a Rebuilt Browser

CDP Bridge MCP is not another browser automation framework. It doesn't launch browsers, manage browser lifecycles, or even render pages. It does just one thing: bridge.

LLM / Agent
    │ stdio or streamable-http
    ▼
CDP Bridge MCP Service (middle layer)
    │ WebSocket / HTTP
    ▼
Chromium Browser Extension (the Chrome you're using)
    ▼
The webpage you are browsing

Three layers, each with a clear responsibility:

• MCP Server: receives tool calls from the agent and forwards them to the browser extension
• Browser Extension: executes actions in the real page; when CSP restrictions are encountered, automatically degrades to CDP Runtime.evaluate
• Token Isolation: in streamable-http mode, different users use different tokens; the server isolates session spaces by token

This means: the Xiaohongshu page, backend management system, or customer service workbench you've already logged into in Chrome—the agent can directly read and operate them without re-logging in or moving cookies to the cloud.

Measured Performance: Where It's Faster, Where It's Slower

The project team conducted V2 comparative evaluations with the same model, same task, and same tool-calling loop:

Key finding: CDP Bridge is not a silver bullet. When the task doesn't need to read the user's current page context (e.g., simply querying a tab), Playwright is actually faster—because it doesn't have to go through the extra bridge of the extension.

CDP Bridge's strength lies in scenarios that "reuse existing context": already-logged-in websites, already-loaded pages, already-rendered frontend content. In these cases, Playwright has to relaunch the browser → log in → navigate → wait for rendering, while CDP Bridge starts from the current state.

Competitor Landscape: Full Picture of the Browser Agent Track

By 2026, "browser harness" has become an independent category—a tool layer between agent frameworks and cloud browsers. Notte's taxonomy clearly divides the track:

The track is divided into three niches:

1. Clean browser automation (Playwright MCP, browser-use): launches independent instances, suitable for testing and batch tasks
2. Cloud browser services (Stagehand, Browserbase): hosted browsers, session-based billing, suitable for production deployment
3. Real browser bridging (CDP Bridge, Webfuse, mcp-chrome): connects to the browser the user is using, suitable for collaborative scenarios

CDP Bridge sits in the third niche, with the fewest stars but the clearest thinking.

Token Economics: Saving More Than Just Time

A typical browser automation task with Playwright MCP consumes approximately 114,000 tokens. Playwright CLI (snapshot-to-disk mode) requires only about 27,000 tokens—a 76% savings. These are Microsoft's own measurements.

CDP Bridge's token-saving logic is different: instead of reducing the information returned to the model, it reduces the detours the model has to take.

Typical Playwright flow: launch browser → navigate → wait for load → screenshot / get accessibility tree → parse → click → wait → screenshot → parse again… Each step is a tool call, and each call brings the full page snapshot into context.

CDP Bridge flow: scan current page (browser_scan returns simplified HTML) → perform action → return result. Fewer startup and navigation steps, fewer wait-for-load rounds, and naturally fewer tokens.

The 10,315 vs 18,647 token gap in the NumPy tutorial scenario comes mainly from this.

10 Tools: Enough, But Not Abundant

Compared to Playwright MCP's 23 tools, CDP Bridge's tool set is relatively streamlined. There are no high-level interaction tools like click, type, or fill—you have to use browser_execute_js to manually write selectors and trigger events. This requires the agent to have JS capability, and also makes debugging harder.

The Price to Be Clear-Eyed

The source article is written by the project team themselves. Sanhuang Studio is the development team behind CDP Bridge MCP. The evaluation data in the source article comes from "single example runs," not multi-round statistical testing. The 56% time savings and 45% token savings are single results under specific scenarios, not general conclusions. The source article also acknowledges this at the end.

Token explosion is a known problem. Issue #6 is titled "Token Explosion!" The simplified HTML returned by browser_scan can still be very large on complex pages—an e-commerce homepage's simplified DOM can easily exceed 50K characters. If the agent needs to scan the same page multiple times, token consumption accumulates quickly.

CSP restrictions are a hard limitation. Issue #11 reports that entering Google Stadia (now stich) gets blocked. Although the extension has a CDP Runtime.evaluate degradation mechanism, not all CSP policies can be bypassed. Financial, medical, and other high-security websites usually have stricter CSP.

The security model requires trust. CDP Bridge lets the agent operate the real browser you're using—which means it operates your real accounts. If the agent makes a mistake (clicking the wrong button, submitting an incorrect form, deleting data), the consequences are real, not sandboxed. The source article mentions "waiting for confirmation before executing risky actions," but this depends on the agent's judgment, not a hard technical guarantee.

Bus factor ≈ 2. Unagi-cq contributed 54 commits, FlowerBirds contributed 5, idonecc contributed 1. Core development is highly concentrated.

Playwright 1.59's browser.bind(). The latest Playwright version already supports session sharing—any MCP server can share a browser session with the test script via browser.bind(). This blurs the line between "independent browser" and "real browser," and CDP Bridge's differentiated advantage may be eroded.

Decision Guide

It's not "Playwright retires," it's which key opens which door:

There is no absolute good or bad tool. The key is which browser your agent needs to operate—a clean test instance, or the one you're already using.

GitHub: https://github.com/Unagi-cq/cdp-bridge-mcp