This server provides stealth web browsing and search capabilities for LLMs, with anti-bot evasion, token-optimized content extraction, and residential proxy management.
stealth_fetch: Fetch any webpage with automated anti-bot & Cloudflare Turnstile evasion; returns clean, token-optimized Markdown. Optionally escalate to a headless stealth browser and use a sticky proxy session.
stealth_search: Search the web across DuckDuckGo and Google without API keys; returns ranked citations (titles, URLs, snippets) with configurable result count and optional proxy session.
proxy_status: Inspect the residential proxy pool health, active sticky sessions, and provider status.
rotate_proxy: Force a new residential IP lease for a specified session to avoid blocks or rate limits.
Bypasses Cloudflare Turnstile and anti-bot challenges to fetch protected web pages.
Used as a search engine in the multi-engine real-time web search tool, returning ranked citations without API keys.
Used as a search engine in the multi-engine real-time web search tool, returning ranked citations without API keys.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-stealth-browser Can you search for the latest research on LLM agents and summarize the top 3 results?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-stealth-browser)
💡 Facing IP Bans, Zero-View Shadowbans, or Captcha Loops? Need custom dedicated residential IP pools or enterprise setup assistance? 🎁 Claim 1GB Free Residential Proxy Trial | 💬 Telegram Support: @ip38888 | ✉️ Email: anton.li.pm@gmail.com | 📊 Live Benchmark
⭐ Love this project? Please consider starring it on GitHub! It helps keep the open-source residential IP anti-bot benchmark updated.
🔥 Check Out Our High-Performance AI & Agentic Suite:
🤖 llm-web-grounding-proxy: Universal OpenAI reverse proxy injecting real-time search & citations.
🧠 agentic-deep-researcher: Autonomous AI deep researcher with recursive multi-hop scraping.
🌐 mcp-stealth-browser: FastMCP 2.x stealth browser server for Claude Desktop, Cursor & Windsurf.
🛡️ antidetect-proxy-router: Profile-isolated residential proxy router for Playwright & Camoufox.
The High-Performance Stealth Web Browsing & Search MCP Server for Claude Desktop, Cursor, Windsurf & Cline.
Bypasses Cloudflare Turnstile, anti-bot shields, and JavaScript SPAs with dual-engine TLS/Playwright impersonation, dynamic residential proxy rotation, and token-optimized semantic Markdown extraction.
flowchart LR
A[LLM Agent<br/>Claude / Cursor / Cline] -->|JSON-RPC 2.0| B(MCP Stealth Server)
B -->|Task Router| C{Engine Dispatcher}
C -->|Tier 1: Fast Path <400ms| D[TLS Impersonator<br/>curl_cffi / JA3 / JA4]
C -->|Tier 2: Challenge Escalation| E[Stealth Playwright<br/>CDP Hooks + Turnstile Solver]
D --> F[Sticky Residential Proxy Router<br/>Ropond Proxy Cloud]
E --> F
F -->|Clean IP Lease| G((Target Website))
G --> H[Token Optimizer Engine<br/>HTML to Semantic Markdown]
H -->|80-95% Token Savings| ARelated MCP server: Stealth Browser MCP Server
Capability |
|
|
|
|
Cloudflare Turnstile Bypass | ✅ Native (<400ms / Dual-Engine) | ❌ (Throws 403) | ⚠️ (Requires manual script) | ❌ (Blocked) |
DataDome / Akamai Evasion | ✅ JA3/JA4 TLS Fingerprint | ❌ (No impersonation) | ❌ (Detectable CDP) | ❌ (Detectable) |
Multi-Engine Web Search | ✅ Built-in (Zero API Keys) | ❌ (None) | ❌ (None) | ❌ (None) |
Context Token Optimization | ✅ 80-95% Compression (Markdown) | ⚠️ (Basic Markdownify) | ❌ (Raw DOM dump) | ❌ (Raw dump) |
Sticky Residential Proxy Pool | ✅ Auto-Rotation on 403/429 | ❌ (Static proxy only) | ❌ (None) | ❌ (None) |
Response Latency | ⚡ < 400ms (TLS tier) | 1 - 3s | 5 - 12s | 5 - 15s |
1-Click Install | 🚀 Smithery ( |
|
|
|
mcp-stealth-browser?Standard web fetch and browser MCP servers (@modelcontextprotocol/server-fetch, playwright-mcp) fail on 70%+ of modern websites:
❌ Cloudflare & Anti-Bot Blocking: Hit with 403 Forbidden or Just a moment... CAPTCHA loops.
❌ Token Window Explosion: Dump raw HTML with bloated scripts, SVGs, and cookie modals, wasting 100k+ tokens.
❌ IP Rate-Limits: Repeated queries from data center IPs get permanently blocked.
❌ No Native Multi-Engine Web Search: Requires expensive Bing/Google API keys to search the web.
mcp-stealth-browser solves:✅ Dual-Engine Cascade: Fast TLS/JA4 browser impersonation (<400ms) with auto-escalation to headless Playwright when Cloudflare Turnstile or DataDome is detected.
✅ Built-in Real-Time Web Search: stealth_search crawls Google & DuckDuckGo simultaneously with zero API keys.
✅ Token-Optimized Markdown: Strips navigation, headers, footers, and scripts, compressing content by 80-95% while preserving tables, headings, and code snippets.
✅ Sticky Residential Proxy Pool: Dynamic residential proxy rotation with 10-30 minute sticky IP sessions and automatic block recovery.
✅ Universal 1-Click Integration: Drop-in configuration for Claude Desktop, Cursor IDE, Windsurf, and Cline.
Tool Name | Parameters | Description |
|
| Fetches any URL bypassing Cloudflare Turnstile, returns clean semantic Markdown with token estimation. |
|
| Multi-engine real-time web search (DuckDuckGo + Google) returning clean ranked citations with zero API keys. |
| none | Returns proxy pool health, active sticky sessions, and residential IP provider status. |
|
| Forces an immediate IP rotation for a specific sticky session. |
To automatically install for Claude Desktop, run:
npx -y @smithery/cli install @AntonLi-PM/mcp-stealth-browser --client claudeTo install for Cursor, run:
npx -y @smithery/cli install @AntonLi-PM/mcp-stealth-browser --client cursorpip install git+https://github.com/AntonLi-PM/mcp-stealth-browser.git
# Optional: Install Playwright for heavy Turnstile challenge solving
playwright install chromiumAdd to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"stealth-browser": {
"command": "uvx",
"args": ["--from", "git+https://github.com/AntonLi-PM/mcp-stealth-browser.git", "mcp-stealth-browser"],
"env": {
"ROTA_PROXY_URL": "http://user:pass@proxy.ropond.com:8080"
}
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"stealth-browser": {
"command": "python",
"args": ["-m", "mcp_stealth_browser"],
"env": {
"ROTA_PROXY_URL": "http://user:pass@proxy.ropond.com:8080"
}
}
}
}For high-concurrency scraping without IP blocks, mcp-stealth-browser natively integrates with dynamic residential proxies:
Obtain a residential proxy gateway (claim a 1GB Free Trial at Ropond Proxy Cloud).
Set the environment variable:
export ROTA_PROXY_URL="http://customer-xyz:pass@gw.ropond.com:8080"mcp-stealth-browser will automatically create sticky sessions per agent conversation and rotate automatically if a 403 or 429 block is encountered.
You can test the search and fetch capabilities directly from CLI:
# Test multi-engine search
python -m mcp_stealth_browser.cli --test-search "DeepSeek R1 reasoning architecture"
# Test stealth fetch on a webpage
python -m mcp_stealth_browser.cli --test-fetch "https://news.ycombinator.com"
# Check proxy pool health
python -m mcp_stealth_browser.cli --statusContributions, issues, and feature requests are welcome! Feel free to check the issues page.
This project is licensed under the MIT License - see the LICENSE file for details.
Explore our complete production-grade anti-bot & matrix marketing open-source ecosystem:
Category | Repository | Description |
Global Matrix | 12-platform multi-account cloud control with 1:1 sticky residential IP mesh | |
Telegram Growth | Multi-account Telegram fleet automation, warmup engine & lead harvester | |
WhatsApp Marketing | Multi-account WhatsApp Web cloud sender with session residential routing | |
TikTok Automation | Anti-detect TikTok video batch uploader with isolated proxy sessions | |
E-Commerce Scraper | Competitor price monitor & review scraper for Amazon, Shopee & Shopify | |
AI Deep Research | Autonomous Deep Research engine utilizing heavy multi-hop residential scraping | |
AI Realtime Search | Real-time web search API for DeepSeek-R1, Ollama & Open-WebUI | |
MCP Browser Tool | FastMCP 2.x stealth browsing server for Claude Desktop, Cursor & Windsurf | |
Anti-Bot Gateway | Rotating residential proxy shield for SearXNG, Perplexica & Open-WebUI | |
Profile Router | Profile-isolated residential proxy router for AdsPower, BitBrowser & Playwright | |
Turnstile Bypass | Turnstile & DataDome bypass scraper with residential session harvesting | |
Live Benchmark | Empirical anti-bot benchmark comparing datacenter vs residential proxy yields |
Inspect current residential proxy pool health, active sticky sessions, and provider status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Inspect' suggests a read-only operation with no side effects, and no annotations are present to clarify behavior. The description does not explicitly state whether the tool returns data, mutates state, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, direct, and free of unnecessary detail. It lists exactly what is inspected in a compact sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status-check tool, the description adequately conveys the core purpose and scope. It does not describe the output format, but the presence of an output schema and the simple inspection nature make the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline score applies. The description is consistent with a parameterless status inspection tool and requires no additional parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects current residential proxy pool health, active sticky sessions, and provider status. It uses a specific verb and resource scope, and is easily distinguishable from the sibling tools fetch, search, and rotate proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies this is for status inspection rather than fetching, searching, or rotating proxies, but it does not explicitly state when to prefer this tool over alternatives. No direct usage conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force an immediate lease rotation to a new residential IP for the specified session.
Args: session_id: Session identifier to renew.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool forces an immediate lease rotation, which implies a side effect on the proxy IP. However, it does not mention potential consequences, rate limits, or whether the operation is synchronous or asynchronous, so behavioral transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a single clear sentence for the tool purpose and a short, focused argument description. No unnecessary words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and parameter, but it does not mention return values, error conditions, or any output schema details. Given that an output schema exists, some additional context about expected results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, session_id, is described as 'Session identifier to renew,' which clarifies its purpose. However, the description does not elaborate on whether it is required, how it is validated, or what happens if it is missing or invalid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: forcing an immediate lease rotation to a new residential IP for a specified session. This is specific and unambiguous, and it distinguishes the tool from the sibling tools that fetch, search, or check proxy status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like proxy_status or stealth_fetch. It only states what the tool does, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any webpage with automated anti-bot & Cloudflare Turnstile evasion. Returns clean, token-optimized Markdown ready for LLM consumption.
Args: url: The web URL to fetch. bypass_challenge: Whether to escalate to headless stealth browser if Cloudflare or anti-bot challenge is detected. session_id: Optional sticky proxy session ID for persistent IP browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| session_id | No | ||
| bypass_challenge | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description assumes full responsibility. It mentions evasion and return format but does not disclose potential side effects (e.g., proxy rotation, session persistence) or explicitly confirm read-only behavior. While a fetch is inherently non-destructive, the description lacks explicit details about side effects or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, using only two sentences to convey the core functionality and output format. It avoids unnecessary verbosity and presents information in a clear, direct manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides essential info (purpose, output) but omits details such as error handling, rate limits, or when to use the tool in conjunction with siblings. The presence of an output schema is noted, but its contents are not described. Overall, it covers the basics but misses edge-case guidance, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for parameters, and the tool description merely lists them without explaining their meaning or expected values. For instance, 'bypass_challenge' is not defined, and 'session_id' is unclear. With 0% schema coverage and no explanatory text, the agent has no guidance on how to appropriately set or use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching any webpage with automated anti-bot evasion and returning Markdown. The verb 'Fetch' and resource 'webpage' are explicit, and the scope is well-defined without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pages that may require anti-bot or Cloudflare evasion, but it does not explicitly state when to prefer this tool over sibling tools like stealth_search or proxy_status. The guidance is implicit rather than explicit, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the real-time web across multiple engines (DuckDuckGo, Google) without requiring any API keys. Returns ranked citations with titles, URLs, and snippets.
Args: query: Search query terms. num_results: Number of results to return (default: 5, max: 15). session_id: Optional sticky proxy session ID.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| session_id | No | ||
| num_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool's behavior: it searches the web and returns ranked citations. It does not explicitly mention side effects like proxy rotation or network activity, but the optional session_id parameter hints at proxy usage. No annotations are present, so the description carries the full burden and covers the primary behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear opening sentence followed by a parameter list. No unnecessary information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to decide when to use this tool. It does not explicitly state that it is read-only or non-destructive, but the nature of a search implies that. An output schema is present, so return format is already defined. Overall, sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the tool description: query (search terms), num_results (count with default and max), and session_id (optional sticky proxy session). Even though the schema has no per-parameter descriptions, the tool description fully covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a web search across multiple engines (DuckDuckGo, Google) and returns ranked citations with titles, URLs, and snippets. It explicitly distinguishes it from potential alternatives by mentioning no API keys required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general web search tasks, mentioning real-time results and multi-engine support. While it does not explicitly contrast with sibling tools (stealth_fetch, proxy_status, rotate_proxy), the purpose is distinct and the sibling names are self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0proxy_statusrotate_proxystealth_fetchstealth_searchScored across 4 tools
Each tool has a distinct purpose: fetching a URL, searching the web, checking proxy status, and rotating proxies. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with underscores (stealth_fetch, stealth_search, proxy_status, rotate_proxy), maintaining uniformity.
Four tools is well-scoped for a stealth browsing/proxy management server, covering core actions without unnecessary bloat or gaps.
The tool set covers fetching, searching, and proxy lifecycle management, but could potentially include a method for clearing session data or managing more proxy options. Still, it is largely complete for its stated purpose.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
