Stealth Browser MCP: a nodriver-backed MCP server for Cloudflare-gated pages
The only browser automation that bypasses anti-bot systems. AI writes network hooks, clones UIs pixel-perfect via simple chat.
At a glance
- What is it?
- Stealth Browser MCP wraps nodriver and the Chrome DevTools Protocol in a FastMCP server so an AI agent can drive a real Chrome-family browser. It is a reasonable fit if your agent already speaks MCP and keeps hitting bot checks; it is the wrong tool if you need a stable, documented API surface.
- Who is it for?
- Adopt it if you run a local MCP client such as Claude Code or Claude Desktop, you need a real Chrome-family browser to get past Cloudflare-style interstitials, and you can accept a tool surface that changes between releases. Do not adopt it if you need a frozen API for production pipelines, if you cannot audit Python that runs hooks and CDP commands against your sessions, or if you expect a hosted service.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: agents that stall on an interstitial
Most browser automation for AI agents assumes the page will load. Playwright and Selenium drive a browser that announces itself as automation, and sites that care about that distinction answer with a challenge page instead of content. The agent then sees a wall it cannot reason about, and the run ends in a retry loop.
Stealth Browser MCP targets that specific gap. The README frames it as stealth browser automation for MCP-compatible AI agents, aimed at navigating Cloudflare challenges, anti-bot checks, and login walls. The intended user is someone running an MCP client locally who wants the agent to reach the page behind the check, then read or manipulate it. This is not a general scraping framework. It is a tool provider for one class of client.
nodriver plus CDP is the actual mechanism
The project does not implement its own stealth patches. It delegates to nodriver, which drives a real Chrome-family browser instance, and speaks to that browser over the Chrome DevTools Protocol. FastMCP is the layer that exposes the resulting operations as MCP tools.
That division matters when you are judging the project. Anything nodriver does about fingerprinting is inherited, not invented here. Anything the project adds sits above the CDP connection: element extraction, network inspection, hook execution, and the tool schema the model sees. So the useful question is not whether the stealth is good in the abstract, but whether the CDP-level operations are exposed cleanly enough for an agent to use without guessing.
The README claims Cloudflare and Queue-It style challenges have been passed in testing, with the explicit caveat that results vary by site, region, browser version, and detector version. Treat that as the honest framing it is. Challenge outcomes are not a property of this repository; they are a property of the browser build, the network path, and whatever the detector changed last week.
97 tools across 11 sections, and why the count is a liability
The default surface is 97 tools across 11 sections, with a minimal 20-tool core available and sections that can be disabled. That number is the single most important thing to understand before installing, because every tool you expose is schema the model has to hold in context and choose between. A 97-tool surface invites wrong-tool selection on tasks where a narrower set would have been unambiguous.
The modular loading is the mitigation, and it is the right design decision. Running the core and enabling sections as needed is the mode that makes this practical. The README does not lay out the full section list in the material available here, so you should read the server configuration section of the repository to see which sections exist and what disabling one actually removes.
Beyond navigation, the notable capabilities are element cloning (extracting an element with its CSS, DOM structure, events, animations, and assets via CDP), network inspection of requests, responses, headers, payloads, and captured bodies, and a dynamic hook system where restricted Python hooks can intercept, block, redirect, fulfill, or modify request and response flows. The hook system is the most interesting part and also the part that deserves the most scrutiny.
Getting it running: clone, venv, then one MCP registration
The install path in the README is conventional. Clone the repository, create a virtual environment, activate it, and install requirements:
git clone https://github.com/vibheksoni/stealth-browser-mcp.git cd stealth-browser-mcp python -m venv venv
On Windows, venv\Scripts\activate. On macOS or Linux, source venv/bin/activate. Then pip install -r requirements.txt. Python 3.10 or newer is required, along with Chrome, Chromium, or Microsoft Edge already installed.
The recommended registration is through the Claude Code CLI, which takes a JSON blob describing a stdio server:
claude mcp add-json stealth-browser-mcp "{\"type\":\"stdio\",\"command\":\"C:\\path\\to\\stealth-browser-mcp\\venv\\Scripts\\python.exe\",\"args\":[\"C:\\path\\to\\stealth-browser-mcp\\src\\server.py\"]}"
On macOS and Linux the same command takes a single-quoted JSON string pointing at venv/bin/python and src/server.py. The README is explicit that you replace the example path with your real clone path, and that is the step people get wrong: an absolute path to the venv interpreter, not the system python, because the dependencies live in the venv.
For Claude Desktop, Cursor, and similar clients, the manual route is an mcpServers entry with command, args, and an empty env object. On Windows that file is %APPDATA%\Claude\claude_desktop_config.json; on macOS it is ~/Library/Application Support/Claude/claude_desktop_config.json. There is also an experimental FastMCP CLI install path, which the README presents as an alternative for people who prefer that tooling. Nothing here requires a broker or a hosted component.
The trust model is the part to read twice
The README carries a trust model section, and the feature list is blunt about the reason: CDP execution lets you run JavaScript, direct CDP commands, and pre-document scripts through trusted local MCP clients. Restricted Python hooks can rewrite request and response flows.
That is a lot of capability pointed at whatever the agent decides to do. A hook that fulfills or redirects requests sits between the browser and the network, and a pre-document script runs before the page's own code. If your MCP client is not something you fully control, or if the model can be steered by page content it is reading, you have given an untrusted input a path to code that runs in your browser session. The README's own framing, trusted local MCP clients, is the constraint to respect rather than a marketing line to skim.
There is a second, quieter cost. The repository is MIT licensed, which permits commercial use, modification, and redistribution with the licence and copyright notice retained. That covers the code in this repository. It does not cover nodriver, FastMCP, or the browser you point it at, each of which carries its own terms, and it says nothing about whether the sites you automate permit it. Those are separate questions from the licence file, and the licence file will not answer them. This is not legal advice; if the automation targets a service with terms of use, read them.
Where it breaks, and the case for Playwright instead
The clearest limitation is stated by the project itself: challenge results vary by site, region, browser version, and detector version. That means a workflow that passes today can fail tomorrow without a single line of your code changing. If your pipeline needs a predictable success rate, this tool cannot give you one, and you should not build a business process on top of it without a fallback path.
The second failure mode is version drift. The project is at v0.2.5, released 2026-02-10 with a changelog entry reading Protocol Fix, Edge Support, Repo Cleanup. A protocol fix in a point release, on a project whose whole value proposition is a moving target, tells you the tool surface and the underlying behaviour are both still settling. Pin a commit if you depend on it.
The real alternative is Playwright MCP. The difference is not quality, it is approach. Playwright drives a browser it controls and exposes a documented, stable tool surface with an accessibility-tree model that agents handle well. It does not try to look like a human-operated browser, so sites with bot detection will reject it more often. Choose Playwright when you need reproducibility and the target sites do not care; choose this project when the target sites do care and you can tolerate variance. There is also the option of driving nodriver directly from your own script, which trades the MCP tool layer for full control and removes the 97-tool selection problem entirely.
Who should wire this in, and what to check first
This fits a developer running a local MCP client who has a specific, recurring need to reach pages behind Cloudflare-style checks and wants the agent to inspect network traffic or clone a UI element while it is there. The element cloning and network inspection are the features that distinguish it from simply scripting nodriver by hand, because they put CDP-level detail into the model's context in a structured form.
It does not fit production pipelines that need a frozen API, teams that cannot review Python that executes hooks and CDP commands against live sessions, or anyone expecting a managed service. There is no homepage listed, so the repository is the documentation.
Three things to verify before you commit. First, the current tool count and section names at your pinned commit, since the README's 97 and 11 are a snapshot and the modular loading config controls what you actually expose. Second, which browser binary the automatic discovery selects on your platform, because Chrome, Chromium, and Edge are all supported and the choice affects your fingerprint. Third, the hook execution path itself. That is the code that can rewrite your traffic, and it is the code most worth reading line by line before you let a model near it.
Editorial conclusion
Adopt it if you run a local MCP client such as Claude Code or Claude Desktop, you need a real Chrome-family browser to get past Cloudflare-style interstitials, and you can accept a tool surface that changes between releases. Do not adopt it if you need a frozen API for production pipelines, if you cannot audit Python that runs hooks and CDP commands against your sessions, or if you expect a hosted service. Before wiring it in, verify three things against the repository at the commit you plan to pin: the current tool count and section names, which browser binary the auto-discovery picks on your OS, and the exact contents of the hook execution path, since that is the code with the widest blast radius.
Community notes