Undetected, anti-bot-resistant Chrome automation. 57 tools. Stealth chrome-devtools-mcp alternative.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
An undetected, anti-bot-resistant browser automation MCP server β a drop-in, stealth alternative to chrome-devtools-mcp for AI agents like Claude, Claude Code, Cursor, Windsurf, and any Model Context Protocol client. Powered by nodriver so your agent can browse, scrape, and automate real Chrome without tripping Cloudflare, hCaptcha, or WebDriver fingerprint detection.
Keywords: MCP server Β· browser automation Β· undetected chromedriver Β· anti-bot Β· Cloudflare bypass Β· web scraping Β· Claude Β· Cursor Β· nodriver Β· chrome-devtools-mcp alternative Β· Playwright/Puppeteer alternative Β· AI agent tools.
If you drive a browser from an AI agent, you have probably run into one of these:
navigator.webdriver returns true, and the site quietly serves you different content because of itNone of that is your script being wrong. It is anti-bot detection β Cloudflare, DataDome, PerimeterX, Akamai, hCaptcha β recognising the automation stack itself. It shows up with chrome-devtools-mcp, playwright-mcp, Puppeteer, Selenium and browser-use alike, because they all drive Chrome in ways that leave a detectable signature: a ChromeDriver binary, WebDriver markers, CDP artifacts.
nodriver is the successor of undetected-chromedriver. It speaks the CDP protocol directly β no ChromeDriver binary, no Selenium/WebDriver markers β so navigator.webdriver reads false rather than true, and a session looks like a person using Chrome.
This server exposes that through the same tool surface as chrome-devtools-mcp (65 tools), so your agent keeps a familiar API and simply stops getting blocked. Swapping is a config change, not a rewrite.
What it will not do, so you can judge before installing: it does not solve image or text captchas for you, it cannot defeat every protection on every site, and it will not rescue a scraper that hammers a server. If a site blocks you for what you do rather than what you are, no driver fixes that. cf_verify handles the common Cloudflare checkbox challenge; it is not a captcha-solving service.
Claiming "undetected" is easy, so here is what the standard fingerprint suite reports when this server drives the page itself. Reproduce it in one line: point your agent at https://bot.sannysoft.com and take a snapshot.
| Check | Result |
|---|---|
bot.sannysoft.com β Intoli + fingerprint suite | 58 checks, 0 failed |
navigator.webdriver | false β a boolean on Navigator.prototype, not an own property, exactly as in a normal browser |
window.chrome | present |
navigator.plugins | 5 |
navigator.languages | 4 entries |
| User agent | no Headless token |
What this does and does not prove. It shows the browser presents no automation artifacts to client-side fingerprinting, which is what these suites test and what most blocks key off. It does not prove any particular site will let you in: server-side signals such as IP reputation and request rate are outside what any driver controls, and captchas are not solved (see above). Measured on Chrome 150 / Windows 11, headful, with the default profile.
navigator.webdriver reads false, exactly as in a browser a person is using, and there are no CDP or WebDriver artifacts to find.cf_verify, needs the [cf] extra).list_frames plus a frame argument on the readers, and take_snapshot splices each iframe's tree in under the element hosting it, so a payment field or consent wall inside one gets a uid and can be clicked and filled like anything else.browser: "agent-a" to any tool and that name gets its own Chrome, in its own process, with its own cookies, tabs and uids. Parallel agents stop stealing each other's selected tab. Omit it and nothing changes: the default browser runs in the server process, exactly as before. How it workstake_snapshot) β searchable page text with a uid per element. Measured on the Hacker News front page: 27 KB against 97 KB unfiltered, 72% smaller, with every link, URL and text preserved. Same-origin URLs are printed relative to the page, which is lossless because the root node keeps the absolute one. That saving lands on every single agent step.use_running_browser) β drive your real Chrome profile over its debugging port instead of rebuilding logins in a fresh one.fill reads the value back, set_checked reads the checked state back, and click, press_key and type_text report when no input event reached the page. A tool that cannot confirm what it did says so instead of reporting success.Requires uv for the first and third form. To track the development branch instead of a release:
Also listed in the official MCP Registry as io.github.andresolbach/nodriver-mcp-server, so clients and marketplaces that read the registry can find and install it directly.
Uses upstream
nodriver>=0.50.3, which contains the Chrome 146+ CDP fixes (samePartyremoved fromCookie,privateNetworkRequestPolicyβlocalNetworkAccessRequestPolicy) β verified working against Chrome 150.pip installalso works, butuv tool installkeeps it isolated.
You'll also need a local installation of Google Chrome (auto-detected).
Every tool in this server was tested end-to-end against Google Chrome 150 with nodriver 0.50.3 on Python 3.12.11 / Windows 11 (macOS and Linux are supported too). Because nodriver talks to Chrome directly over CDP and tracks upstream Chrome changes, it keeps working as Chrome auto-updates.
| Component | Requirement | Verified version |
|---|---|---|
| Python | 3.12+ | 3.12.11 |
| Google Chrome | any recent stable | 150.0.7871.101 |
| Operating system | Windows / macOS / Linux | Windows 11 |
nodriver | >= 0.50.3 | 0.50.3 |
mcp (MCP SDK) | >= 1.26.0, < 2 | 1.26.0 |
pillow | >= 12.1.1 | 12.1.1 |
tomli-w | >= 1.0.0 | 1.2.0 |
The pip packages/versions are also listed in requirements.txt (pip install -r requirements.txt), though uv tool install is recommended for a fully pinned, reproducible install.
Supported clients: Claude Desktop, Claude Code, Cursor, Windsurf, Codex, Gemini CLI, Copilot CLI, Kiro, VS Code, Cline, Roo Code, Amazon Q, Warp, Opencode, Trae.
The Claude Code VS Code extension shares Claude Code's config (
~/.claude.json), so installing toclaude-codecovers both the CLI and the extension.
If you'd rather paste it yourself, this works in any MCP client (claude_desktop_config.json, ~/.claude.json, .cursor/mcp.json, .mcp.json, β¦):
| Variable | Description | Default |
|---|---|---|
NODRIVER_HEADLESS | Headless mode (true/false) | false |
NODRIVER_USER_DATA_DIR | Explicit persistent Chrome profile dir (overrides the default) | Ephemeral temp profile, auto-deleted per session |
NODRIVER_BROWSER_PATH | Chrome executable path | Auto-detected |
NODRIVER_PROXY | Proxy server address | None |
NODRIVER_BROWSER_URL | Attach to a Chrome already running at this address (e.g. http://127.0.0.1:9222) instead of launching one | Launch our own |
NODRIVER_ENABLE_TRANSLATE | Set true to re-enable Chrome's Google Translate popup | Disabled |
NODRIVER_ENABLE_EXTENSIONS | Set true to allow externally-installed Chrome extensions (and their prompts) | Disabled |
By default the browser starts clean for automation: the Google Translate popup is suppressed and externally-installed Chrome extensions are blocked (so you don't get "an extension requires your attention" prompts). Re-enable either via the env vars above or at runtime with the set_browser_flags tool β which can also set any other Chrome launch flags (e.g. --lang=de-DE, --window-size=1280,800) via its extra_args parameter. The browser also auto-recovers if Chrome is closed or crashes between calls β tools relaunch it instead of failing.
Chrome also starts on about:blank rather than the New Tab page, so the NTP's own Google requests never show up in list_network_requests, and new_page reuses that empty startup tab instead of leaving a stray blank page behind.
manage_extensions handles extensions at runtime:
manage_extensions("list") β extensions installed in the active profile (name, version, id) plus the current statemanage_extensions("on") / ("off") β the master switch (--disable-extensions); restarts Chrome. It covers unpacked extensions too, so "off" really means offmanage_extensions("load", path) / ("unload", path) β unpacked extensions from a folderTo use an extension permanently, switch to a persistent profile, install it once from the Chrome Web Store in that browser, and turn extensions on β it then loads on every launch.
Unpacked extensions need Chromium or Chrome for Testing. Official Chrome builds dropped
--load-extensionin v137, and as of Chrome 151 neither--enable-unsafe-extension-debuggingnor disablingDisableLoadExtensionCommandLineSwitchbrings it back β the flag is accepted and the extension is silently never registered.manage_extensionsdetects a branded build and says so instead of pretending it worked. PointNODRIVER_BROWSER_PATHat Chromium / Chrome for Testing if you need unpacked loading.
One agent working alone can skip this section: without the browser argument everything runs on a single shared browser, exactly as before.
Point two agents at one browser, though, and they collide. They share the selected tab, so a select_page or a navigation by one silently changes what the other sees, and every uid the other is holding goes stale. Nothing errors β the second agent simply acts on the wrong page.
So every tool takes an optional browser argument, and a name that does not exist yet creates one on the spot:
Each name is a separate Chrome in a separate process, with its own profile, cookies, tabs, snapshot uids and console/network capture. Isolation is structural rather than careful: there is no shared state left to collide over, and a Chrome that hangs or crashes takes down nothing but its own browser.
The default costs nothing. "default" runs inside the server process itself, so a session that never opens a second browser is the same single process and the same code path it always was. Only extra names spawn anything.
| Tool | |
|---|---|
list_browsers | What is open: names, whether Chrome runs, profile, tabs and their URLs. Reports without starting anything. |
shutdown_browser | Quits one browser's Chrome and frees its name. close_browser only quits Chrome and keeps the browser's profile and flags for next time. |
Each extra browser is a Python process plus a full Chrome β roughly 200 MB and about a second to start. Up to 12 can be open at once, including the default. Two callers sharing one name still share one Chrome: the isolation is per browser, not per caller, so parallel agents each need their own.
By default every browser launches Chrome with a fresh temporary profile that is created and deleted automatically. That also means you can run nodriver from Claude Desktop, Claude Code and the VS Code extension at the same time β each gets its own isolated Chrome, and they never fight over a shared profile. No configuration, no detection logic, nothing to clean up.
When you want to reuse a login across sessions, create a named persistent profile and switch to it:
list_profiles β list persistent profiles and show the active onecreate_profile(name, activate=false) β create a reusable profileuse_profile(name) β switch to a persistent profile (""/"temp" returns to ephemeral)use_temp_profile β switch back to a fresh ephemeral profiledelete_profile(name) β remove a persistent profilePersistent profiles live under ~/.nodriver-mcp/profiles/<name>. You can still force a fixed profile globally with the NODRIVER_USER_DATA_DIR env var.
Chrome locks its user-data-dir, so the profile holding your real logins cannot be opened a second time. The way in is to attach to the browser that already has it open β then you skip rebuilding every login through automation.
Start Chrome yourself, once:
Then attach, either at runtime with use_running_browser(port=9222), or up front by setting NODRIVER_BROWSER_URL=http://127.0.0.1:9222. Every tool then acts on that browser and its real tabs.
While attached, this server never closes a browser it did not start: close_browser and profile switches only detach. Go back to a self-launched browser with use_temp_profile or use_profile.
β οΈ That profile becomes part of the agent's reach. Whatever it is signed into β mail, bank, company systems β is reachable from here, because a cookie jar is all or nothing. Point this at a profile you are willing to expose, not your everyday one.
Network collection is enabled automatically on each tab. Console collection is opt-in: call enable_console_collection when you want list_console_messages / get_console_message to start collecting events. This keeps Runtime.enable() disabled by default for sites that detect attached debuggers.
For mobile-only sites, pass device directly to new_page(...) or navigate_page(...) so the first real request already carries mobile signals.
click sends real CDP input events, so the page sees isTrusted=true. Because those are delivered by coordinate, it scrolls the element into view and then hit-tests several points inside it, since a sticky header or cookie banner can own the centre pixel β on docs.pypi.org that affects 43 of 54 visible links. If no point reaches the element, if_covered decides: "report" (default) refuses and names the blocker, leaving the page untouched and the session undetectable; "synthetic_click" clicks the element directly, which works through anything but makes the page see isTrusted=false. Either way the response says which path was taken, so a detectable click is never silent.
| Category | Tools |
|---|---|
| Several browsers (2) | list_browsers Β· shutdown_browser |
| Input automation (12) | click Β· click_at Β· hover Β· fill Β· fill_form Β· set_checked Β· select_option Β· type_text Β· press_key Β· drag Β· upload_file Β· handle_dialog |
| Navigation (10) | navigate_page Β· new_page Β· close_page Β· close_browser Β· list_pages Β· select_page Β· wait_for Β· wait_for_selector Β· scroll_page Β· scroll_to_selector |
| Snapshots & debugging (12) | take_screenshot Β· take_snapshot Β· get_page_content Β· query_selector Β· list_frames Β· evaluate_script Β· get_computed_styles Β· save_pdf Β· enable_console_collection Β· disable_console_collection Β· list_console_messages Β· get_console_message |
| Network monitoring (3) | list_network_requests Β· get_network_request Β· block_resources |
| Device emulation (4) | emulate Β· emulate_device Β· reset_emulation Β· resize_page |
| Performance (3) | performance_start_trace Β· performance_stop_trace Β· take_memory_snapshot |
| Cookies & storage (5) | get_cookies Β· set_cookie Β· clear_cookies Β· get_local_storage Β· set_local_storage |
| Session management (3) | save_session Β· load_session Β· list_sessions |
| Profiles & browser (9) | list_profiles Β· create_profile Β· use_profile Β· use_temp_profile Β· use_running_browser Β· delete_profile Β· set_browser_flags Β· set_proxy Β· manage_extensions |
| Anti-detection helpers (2) | cf_verify Β· bypass_insecure_warning |
π Full tool reference β β every tool with its exact parameters, types, defaults and enum values, generated straight from the live schemas.
An MCP tool is only as good as what the model can see of it. Most servers hand over a name, a sentence, and untyped parameters β leaving the agent to guess whether it's type="url" or type="goto", and burning a failed call to find out.
Here, the schema does that work:
navigate_page(type=β¦) advertises exactly url, back, forward, reload. A wrong value is rejected by validation before it ever reaches Chrome, instead of returning an error the agent has to interpret.quality is 0β100, wait_for(text=β¦) requires at least one entry.fill_form publishes {uid, value} rather than an opaque list[dict].readOnlyHint, destructiveHint, idempotentHint). Clients use these to group permissions β so a client can auto-approve take_snapshot while still prompting for delete_profile.take_screenshot tells the model to prefer take_snapshot; click_at points back to click.| Feature | chrome-devtools-mcp | nodriver-mcp-server |
|---|---|---|
| Browser backend | Puppeteer (ChromeDriver) | nodriver (direct CDP) |
| WebDriver fingerprint | β Exposed | β None |
navigator.webdriver | β true | β
false, as in a normal browser |
| Cloudflare bypass | β | β
Built-in cf_verify |
| Install method | npx | uvx / pip |
| Language | TypeScript / Node.js | Python |
| Parallel browsers | one | up to 12, isolated |
| Tool coverage | 29 tools | 65 tools |
| Per-parameter schema docs | partial | β all 65 tools |
| Tool behaviour hints | β | β read-only / destructive |
Tools not implemented: performance_analyze_insight (needs the DevTools frontend trace parser), lighthouse_audit (needs the Lighthouse Node API), screencast_start/stop (needs ffmpeg + Puppeteer), extension management (experimental).
Is this an undetected alternative to chrome-devtools-mcp?
Yes. It exposes the same tool surface but drives Chrome through nodriver (direct CDP), so navigator.webdriver reads false β the same value a browser a person is using reports β and there are no WebDriver/CDP fingerprints for anti-bot systems to detect.
Can it bypass Cloudflare?
It ships a cf_verify tool that solves the Cloudflare "verify you are human" challenge, and its undetected profile avoids most bot checks. (No tool can guarantee bypassing every protection.)
I already use chrome-devtools-mcp or playwright-mcp and keep getting blocked. How do I switch?
Replace the server entry in your MCP config with the one under Manual config β that is the whole migration. The tool names and arguments match chrome-devtools-mcp, so existing prompts, scripts and agent instructions keep working unchanged. You can also run both side by side and point the agent at whichever suits the site.
The site works in my normal browser but not under automation. Why?
Because anti-bot systems fingerprint the driver, not your behaviour: a ChromeDriver binary in the process tree, navigator.webdriver === true, CDP artifacts in the page. Your manual browser has none of those, so it is served the real page. nodriver drives Chrome without leaving them.
Does it help with captchas?
Only the Cloudflare "verify you are human" checkbox, via cf_verify. Image grids, text captchas and hCaptcha puzzles are not solved β this is a stealth driver, not a captcha service. In practice, staying undetected means far fewer captchas are shown in the first place.
Which clients are supported? One command installs it into 15+ MCP clients: Claude Desktop, Claude Code, Cursor, Windsurf, Codex, Gemini CLI, Copilot CLI, Kiro, VS Code, Cline, Roo Code, Amazon Q, Warp, Opencode, Trae.
Can I run it in several clients at the same time? Yes. Each instance uses its own ephemeral Chrome profile by default, so Claude Desktop, Claude Code and the VS Code extension can all use nodriver simultaneously without colliding.
Headless or visible browser?
A real Chrome window by default; set NODRIVER_HEADLESS=true for headless.
How do I keep a login between sessions?
Create a persistent profile with create_profile and switch to it with use_profile, or use save_session / load_session.
Does it work on Windows / macOS / Linux? Yes, all three. Tested on Windows 11 with Chrome 150 and Python 3.12.
See CHANGES.md. Highlights: ephemeral-by-default Chrome profiles so multiple instances run at once (+ named persistent profiles), migrated to upstream nodriver 0.50.3 (Chrome 150 verified), and fixed several previously-broken tools β fill/fill_form, evaluate_script with element args, select_page tab switching, press_key modifier chords (Ctrl+A/C/V), network/console lookup indexing, and Windows installer crashes.
Based on nodriver-mcp by Saber-CC (MIT). Browser backend by nodriver (ultrafunkamsterdam). Tool surface mirrors chrome-devtools-mcp.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/nodriver-undetected-browser-automation)<a href="https://allmcps.com/mcp/nodriver-undetected-browser-automation"><img src="https://allmcps.com/api/badge/nodriver-undetected-browser-automation?style=directory" alt="Nodriver β undetected browser automation on AllMCPs" /></a>