andresolbach/nodriver-mcp-server

**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.
Is this the problem you have?
If you drive a browser from an AI agent, you have probably run into one of these:
- The page sits on **"Just a moment…"** or **"Checking your browser before accessing"** and never loads
- A **"Verify you are human"** checkbox that reappears every single time you click it
- **"Unusual Activity Detected"**, **"Access Denied"**, or a plain **HTTP 403** — from a site that opens perfectly in your normal browser
- navigator.webdriver returns true, and the site quietly serves you different content because of it
- The login works when you do it by hand, and fails the moment automation does the same steps
- It all worked for weeks, then the site started returning an empty page or a captcha wall
None 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.
Why this fixes it
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** (70 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.
Does it actually pass? Here is the evidence
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 151 / Windows 11, headful, with the default profile.
Features
- 🕵️ **Undetected by design** — navigator.webdriver reads false, exactly as in a browser a person is using, and there are no CDP or WebDriver artifacts to find.
- ☁️ **Built-in Cloudflare challenge solver** (cf_verify, needs the [cf] extra).
- 🖼️ **Frames are not a blind spot** — 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.
- 🔍 **A network log that says what happened** — status, response headers, a DevTools-style timing breakdown (DNS, connect, TLS, time to first byte, download), the script and line that started each request, transfer size, redirect hops and failures, plus WebSocket frames and server-sent events. A 500, a 404, a redirect and a DNS failure are different lines, not the same one.