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., "@cloakbrowser-mcp Get the text from https://example.com"
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.
把 CloakBrowser（在原始碼層改過、繞過 bot 偵測的隱形 Chromium）包成 MCP server，讓 Claude Code（或任何 MCP client）直接拿來做網頁檢索。
底層是真正修改過二進位的 Chromium，連 headless 模式都能通過 sannysoft 的 WebDriver 進階偵測，比 JS 注入式的 stealth 方案穩。
工具 | 用途 |
| 開網址回傳渲染後的可見純文字（餵 LLM 分析）；可給 |
| 回傳渲染後 HTML 原始碼（結構化解析 / 抽連結） |
| 整頁或單一元素截圖存 PNG |
| 單一 session 內依序執行 click/fill/scroll/wait… 再擷取 |
每個工具都吃共用反偵測參數：
參數 | 預設 | 說明 |
|
| 模擬人類滑鼠曲線 / 鍵盤時序 |
|
| 代理 URL，例如 |
|
| 依代理 IP 自動對齊時區 / 語系 |
|
| 有些站會偵測 headless，硬站設 |
|
| 手動指定 IANA 時區 / BCP 47 語系 |
要繞 Cloudflare / reCAPTCHA / FingerprintJS 時建議組合：住宅 proxy + geoip=true + humanize=true，再不行加 headless=false。
每次呼叫都是「開瀏覽器 → 做事 → 關閉」的無狀態模式；需要跨步驟（登入、填表、翻頁）請用一次 cloak_interact 把動作串起來。
Related MCP server: Local-MCP-server
Python ≥ 3.10（建議 3.12）
macOS arm64/x64、Linux x86_64/arm64、Windows x86_64
首次執行會自動下載隱形 Chromium 二進位（~200MB，快取在 ~/.cloakbrowser/）
git clone https://github.com/Oliver0804/cloakbrowser-mcp.git
cd cloakbrowser-mcp
python3.12 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/python -c "import cloakbrowser as cb; cb.ensure_binary()" # 預先下載 Chromiumclaude mcp add --scope user cloakbrowser "$(pwd)/.venv/bin/cloakbrowser-mcp"確認連線：
claude mcp list | grep cloakbrowser # 應顯示 ✔ Connected註冊後重開一次 Claude Code session，mcp__cloakbrowser__* 四個工具就會出現。
直接用自然語言叫工具即可，例如：
用 cloak_get_text 幫我抓 https://news.ycombinator.com 的標題
把 https://example.com 用 cloak_screenshot 截整頁存到 /tmp/shot.png
這個站有 Cloudflare，請帶 proxy 跟 humanize 再抓actions 是動作清單，第一個通常是 goto：
[
{"type": "goto", "url": "https://example.com", "wait_until": "domcontentloaded"},
{"type": "fill", "selector": "#email", "value": "a@b.com"},
{"type": "type", "selector": "#q", "value": "hello", "delay": 40},
{"type": "press", "selector": "#q", "keys": "Enter"},
{"type": "click", "selector": "button#go"},
{"type": "select", "selector": "#country", "value": "TW"},
{"type": "scroll", "dy": 1500},
{"type": "wait_selector", "selector": ".results", "timeout_ms": 15000},
{"type": "wait_ms", "ms": 1500}
]extract：text | html | none（最終回傳形式）
selector：extract=text 時只取此元素文字
screenshot_path：給定則動作跑完後再截一張整頁圖
任何支援 stdio 的 MCP client 都能用，把指令指到 entrypoint：
{
"mcpServers": {
"cloakbrowser": {
"command": "/abs/path/cloakbrowser-mcp/.venv/bin/cloakbrowser-mcp"
}
}
}本倉庫包裝程式碼：MIT
CloakBrowser 二進位：免費使用但禁止重新發佈（見上游 BINARY-LICENSE.md）。本倉庫不含二進位，安裝時由 cloakbrowser 套件自動下載。
開啟 url 並回傳渲染後的 HTML 原始碼（適合做結構化解析 / 抽取連結）。
selector 省略時回傳整頁 page.content()；給 selector 則回傳該元素 outerHTML。 其餘反偵測參數同 cloak_get_text。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| selector | No | ||
| wait_selector | No | ||
| wait_ms | No | ||
| wait_until | No | domcontentloaded | |
| timeout_ms | No | ||
| max_chars | No | ||
| humanize | No | ||
| headless | No | ||
| proxy | No | ||
| geoip | No | ||
| timezone | No | ||
| locale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as mutability, authentication needs, rate limits, or side effects. It only mentions anti-detection parameters by reference, leaving the agent to infer behavior from context.
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?
Description is short and front-loaded with the core purpose. Every sentence adds value, referencing another tool for boilerplate parameters to avoid duplication. No unnecessary words.
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?
Despite having an output schema, the description does not explain return values beyond 'HTML source code' or 'outerHTML'. The 11 parameters not described here are left to cross-reference, making this tool's description insufficient for an agent to use all features correctly without external knowledge.
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?
Description explains the effect of 'url' and 'selector' parameters (return full page vs. outerHTML). However, with 0% schema coverage and 13 parameters, only the first two are described; the remaining 11 are merely cross-referenced to another tool, which adds incompleteness.
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?
Description clearly states it opens a URL and returns rendered HTML source code, with option to select a specific element via CSS selector. This distinguishes it from siblings (cloak_get_text for text, cloak_interact for interaction, cloak_screenshot for screenshots).
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?
Description implies use for structured parsing and link extraction, and mentions that anti-detection parameters are same as cloak_get_text, giving context. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用隱形 Chromium 開啟 url 並回傳可見純文字（適合餵給 LLM 分析）。
會執行 JavaScript，能拿到 SPA / 動態渲染後的內容。需要繞過 Cloudflare / reCAPTCHA 時，設定 proxy（住宅代理）+ geoip=True + humanize=True，必要時 headless=False。
Args: url: 目標網址。 selector: 只取此 CSS selector 的 innerText；省略則取整個 。 wait_selector: 導航後等待此元素出現再擷取（給動態內容用）。 wait_ms: 導航後額外固定等待毫秒數。 wait_until: load | domcontentloaded | networkidle | commit。 max_chars: 內容上限，超過會截斷並標記 truncated。 humanize / proxy / geoip / headless / timezone / locale: 反偵測設定。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| selector | No | ||
| wait_selector | No | ||
| wait_ms | No | ||
| wait_until | No | domcontentloaded | |
| timeout_ms | No | ||
| max_chars | No | ||
| humanize | No | ||
| headless | No | ||
| proxy | No | ||
| geoip | No | ||
| timezone | No | ||
| locale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: uses Chromium, executes JavaScript, returns visible plain text, handles SPA/dynamic content, and includes anti-detection settings. With no annotations provided, it carries the full burden and does so adequately, though it lacks details on error handling or session management.
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: a short paragraph for purpose and behavior, followed by a bullet list of parameters. It is front-loaded and contains no unnecessary words. Every sentence adds value.
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?
Given the tool has an output schema (so return values are covered) and 13 parameters with no schema descriptions, the description covers the essential context: purpose, usage hints, parameter explanations, and anti-detection settings. It lacks error handling details but is otherwise complete for practical use.
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 description explains 12 of 13 parameters with meaningful context (e.g., selector limits to CSS selector, max_chars truncates). It does not describe timeout_ms, missing from the bullet list. The explanations add value beyond the schema, which has 0% description coverage.
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 opens a URL with an invisible Chromium browser and returns visible plain text, suitable for LLM analysis. It distinguishes itself from sibling tools (cloak_get_html, cloak_interact, cloak_screenshot) by focusing on plain text extraction with JavaScript execution for dynamic content.
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 provides specific guidance for bypassing Cloudflare/reCAPTCHA by setting proxy, geoip, humanize, and headless. It implies the tool is for text extraction from dynamic pages but does not explicitly compare with siblings for when to use alternatives. The context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在單一 session 內依序執行多個瀏覽器動作，最後擷取結果。
actions 是動作清單，第一個通常是 goto。每個動作是一個 dict，type 可為： {"type":"goto","url":"...","wait_until":"domcontentloaded"} {"type":"click","selector":"button#login"} {"type":"fill","selector":"#email","value":"a@b.com"} {"type":"type","selector":"#q","value":"hello","delay":40} {"type":"press","selector":"#q","keys":"Enter"} {"type":"select","selector":"#country","value":"TW"} {"type":"scroll","dy":1500} {"type":"wait_selector","selector":".results","timeout_ms":15000} {"type":"wait_ms","ms":1500}
extract: text | html | none（最終要回傳的內容形式）。 selector: extract=text 時只取此元素文字。 screenshot_path: 給定則動作跑完後再截一張整頁圖。 其餘反偵測參數同 cloak_get_text；表單 / 登入流程建議 humanize=True。
| Name | Required | Description | Default |
|---|---|---|---|
| actions | Yes | ||
| extract | No | text | |
| selector | No | ||
| screenshot_path | No | ||
| timeout_ms | No | ||
| max_chars | No | ||
| humanize | No | ||
| headless | No | ||
| proxy | No | ||
| geoip | No | ||
| timezone | No | ||
| locale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details action types, extraction modes, anti-detection parameters, and humanization. No annotations exist, so description carries burden. Missing some edge-case behavior like error handling or session lifecycle, but generally thorough.
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?
Well-structured with bullet-pointed action types. A bit lengthy but every part adds value. No redundant information.
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?
Given 12 parameters and complexity, description covers core functionality. References sibling for anti-detection details. Has output schema so return values not needed. Minor gaps like missing timeout_ms details.
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?
Schema coverage is 0%, but description explains actions format, extract, selector, screenshot_path, humanize, headless, proxy, etc. Timeout_ms and max_chars are not explained, but overall adds significant meaning beyond schema.
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 it executes a sequence of browser actions and extracts results. It differentiates from sibling tools which are for direct extraction, establishing a distinct purpose.
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?
Provides guidance such as 'first action is usually goto' and suggests humanize=True for forms. However, lacks explicit when-to-use vs when-not-to-use compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
開啟 url 並截圖存成 PNG 到 path（回傳實際存檔路徑）。
full_page=True 截整頁；給 selector 則只截該元素。path 請用絕對路徑。 其餘反偵測參數同 cloak_get_text。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| path | Yes | ||
| full_page | No | ||
| selector | No | ||
| wait_selector | No | ||
| wait_ms | No | ||
| wait_until | No | load | |
| timeout_ms | No | ||
| humanize | No | ||
| headless | No | ||
| proxy | No | ||
| geoip | No | ||
| timezone | No | ||
| locale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It mentions the return value and that anti-detection parameters are similar to cloak_get_text, but does not disclose any side effects, whether it is read-only, or behavior on error. Adequate but not comprehensive.
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 very concise: three sentences clearly front-loading the main purpose and then providing key usage tips. No wasted words.
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 tool has 14 parameters but only 2 are required. Description covers the main behavior, return value, and the most critical parameters. However, many parameters (wait, timeout, humanize, etc.) rely on cross-reference to sibling tool. Given the output schema exists, completeness is good but not exhaustive.
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?
Schema description coverage is 0%, so description must add meaning. It explains 'full_page' and 'selector' fully, and states path must be absolute. Other parameters are grouped under 'anti-detection parameters same as cloak_get_text', which is helpful but not detailed. Baseline 3 is appropriate given the cross-reference.
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 verb (open URL, screenshot, save as PNG) and the resource (URL, path), and specifies the return value (actual file path). It effectively distinguishes from siblings like cloak_get_html and cloak_get_text which retrieve content rather than screenshots.
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 explains when to use full_page vs selector, and requires absolute paths for the path parameter. It also references cloak_get_text for anti-detection parameters, providing context. However, it does not explicitly state when not to use this tool or alternatives.
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.
v0.1.0cloak_get_htmlcloak_get_textcloak_interactcloak_screenshotScored across 4 tools
Each tool has a clearly distinct purpose: get_html returns raw HTML, get_text returns visible text, interact performs multi-step browser actions, and screenshot captures images. No overlap exists.
All tools share the 'cloak_' prefix and follow a consistent verb_noun pattern (get_html, get_text, interact, screenshot), making naming predictable and intuitive.
With only 4 tools, the server is well-scoped for browser automation. Each tool covers a core operation without redundancy or unnecessary complexity.
The tool set covers the full lifecycle of browser automation: loading pages (HTML/text), interacting with dynamic content, and capturing screenshots. No obvious gaps for typical scraping tasks.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Hyperbrowser MCP — wraps the Hyperbrowser AI-agent browsing API
Scrape, crawl and search the web for AI agents via MCP.
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…