Click on "Install 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., "@stealth-agent-browser-mcp navigate to https://example.com and get hybrid snapshot"
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.
A Model Context Protocol (MCP) server that gives AI agents a stealth-grade Chromium browser with a hybrid Accessibility-Object-Model + Set-of-Mark vision interface. Built for Claude, works with any MCP-compatible host.
Stealth first. Uses rebrowser-playwright to patch the Runtime.Enable CDP leak that bypasses playwright-extra-class stealth plugins. Passes modern bot-detection suites (CreepJS, bot.sannysoft.com) where vanilla Playwright fails.
Token-lean by default. browser_snapshot returns Playwright aria snapshot YAML (~2–5 KB) instead of raw HTML (100KB+). Every interactive element carries a [ref=eN] id that actions consume directly — no selectors, no drift.
Hybrid vision when it matters. Ask for mode: "hybrid" and the server overlays numbered red boxes on the screenshot so the model can ground visually (Set-of-Mark prompting, Yang et al.). The ref ids on the image match the ids in the YAML. No parallel numbering scheme to go out of sync.
Readability-based content extraction. browser_scroll_read runs Mozilla Readability through JSDOM and returns clean Markdown — optionally delta-only, so re-reads cost nothing when nothing changed.
Proxy-ready. Per-session proxy auth, useful with residential pools.
Authorized use only. Stealth tooling has legitimate applications (accessibility auditing, your-own-account automation, QA against sites you own or have permission to test). Do not use this server to violate a site's terms of service or applicable law. See SECURITY.md.
npm install -g stealth-agent-browser-mcp
# Chromium binary is fetched automatically on first launch
npx playwright-core install chromiumOr run without install via npx stealth-agent-browser-mcp.
Related MCP server: BrowserGenie MCP Server
Add to your MCP config:
{
"mcpServers": {
"stealth-browser": {
"command": "npx",
"args": ["-y", "stealth-agent-browser-mcp"],
"env": {
"SAB_HEADLESS": "true",
"SAB_STEALTH_LEVEL": "patched"
}
}
}
}Restart the host. The agent will see the tools listed below.
Tool | Purpose |
| Navigate a URL and return a snapshot. |
|
|
| Click an element by its |
| Type into an input/textarea by ref. |
| Choose options in a |
| Scroll and return Readability Markdown (delta-only by default). |
| Wait for text or a ref to become visible. |
|
|
| Evaluate a JS expression in the page's MAIN world; JSON result. |
| Update single-proxy config (effective after |
| Replace residential proxy pool at runtime (effective after |
| Fallback captcha solver (CapSolver / 2Captcha). Detects Turnstile/hCaptcha/reCAPTCHA on the page. |
| Close + re-open the active browser session with current config. |
All action tools are addressed by the ref emitted in the last AOM snapshot. Refs are Playwright's own aria-ref=eN ids — there is no parallel numbering scheme.
All via environment variables:
Var | Default | Notes |
|
|
|
|
|
|
| — | Single-proxy mode. e.g. |
| — | |
| — | Residential pool. Comma-separated URLs ( |
|
|
|
| — | Username template for sticky-IP providers. |
|
| Bezier-path click with pre-click hesitation. Defeats Datadome trajectory analysis. |
|
|
|
| — | Provider API key. |
| — | Persistent profile directory (cookies build reputation). |
|
| Per-action timeout. |
|
| Max labelled boxes in hybrid mode. |
|
| |
|
| |
|
| |
|
|
|
src/
├── index.ts # Entry (stdio)
├── server.ts # MCP server + tool registration
├── tools.ts # Tool handlers
├── browser.ts # Stealth Chromium launcher (rebrowser-playwright)
├── session.ts # Per-connection browser/context/page state
├── snapshot.ts # AOM + Set-of-Mark pipeline
├── annotate.ts # SVG overlay compositing (sharp)
├── reader.ts # Readability → Markdown (pierces open shadow roots)
├── fingerprint.ts # Rotatable UA/viewport/timezone profiles
├── proxy.ts # Residential pool + rotation + sticky-session template
├── human-mouse.ts # Bezier-curve cursor paths (ghost-cursor math)
├── captcha.ts # CapSolver / 2Captcha REST adapters
├── config.ts # Zod-validated env config
└── logger.ts # pino → stderr (never stdout)All logs go to stderr — stdout is reserved for JSON-RPC. Never add console.log.
A common ask for scrapers is: "spoof the TLS ClientHello (JA3) to look like Chrome, via curl-impersonate or node-tls-client."
That applies to Node-layer HTTP scrapers (fetch, got, axios) where the TCP connection originates from Node's OpenSSL, which emits a ClientHello signature distinct from Chrome's BoringSSL — and Cloudflare / Akamai Bot Manager drop it at the network layer before a single byte of JavaScript runs.
This MCP does not have that architecture. Every request exits through Chromium. Chromium's TLS stack is Chrome's TLS stack (literally the same BoringSSL build), so the ClientHello JA3 is Chrome's JA3 by construction. No JS-level rewriting is possible or necessary.
The one place TLS can still betray you is if you route through a proxy that terminates and re-initiates TLS (MITM). Residential proxy providers (Bright Data, DataImpulse, Oxylabs residential, SOAX) route at TCP — they do not MITM TLS — and the Chromium handshake reaches the origin unmodified. The products that do MITM TLS are managed scraping browsers (Bright Data's Scraping Browser, Oxylabs Web Unblocker), which ship their own headless Chrome and replace this MCP rather than layering on top of it.
Bottom line: with rebrowser-playwright + residential pool (P1) + human mouse (P2), the TLS fingerprint, CDP runtime, DOM surface, and behavioral layer all match real Chrome. Captcha solving (P3) is a fallback for the 1–5% of sessions that still get flagged.
npm run bench:stealth launches the configured browser against public bot-detection test pages (bot.sannysoft.com, CreepJS, pixelscan, BrowserLeaks WebRTC) and reports pass/fail. These are the same harnesses used by the rebrowser-patches and Patchright projects — see rebrowser-bot-detector for the reference suite.
Typical local-fixture test run (see test/):
Test | Result |
AOM YAML contains refs for all interactive elements | ✓ |
| ✓ |
| ✓ |
Readability extracts article to Markdown | ✓ |
Delta-only scroll returns | ✓ |
stealth-agent-browser-mcp | ||||
CDP-level stealth (Cloudflare/DataDome) | ✓ | ✗ | partial | ✗ |
Accessibility-tree snapshots | ✓ | ✓ | ✓ | ✗ |
Set-of-Mark vision (ref-labeled screenshot) | ✓ | ✗ | ✗ | pure vision |
Readability-based scroll-and-read | ✓ | ✗ | ✗ | ✗ |
Token-lean by default | ✓ | ✓ | ✗ | ✗ |
Bundled agent loop | ✗ (host's model drives) | ✗ | ✓ | ✗ |
npm install
npx playwright-core install chromium
npm run build
npm testSee CONTRIBUTING.md. All contributions under Apache-2.0.
Click an element addressed by its ref. When SAB_HUMAN_MOUSE=true (default), the cursor travels via a Bezier path with pre-click hesitation — this defeats trajectory analyzers like Datadome that flag teleporting mice.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | A [ref=eN] id taken from the last aom/hybrid snapshot. | |
| button | No | left | |
| clickCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals a key behavioral trait: the Bezier path with hesitation to defeat trajectory analyzers when SAB_HUMAN_MOUSE is true. Since no annotations are provided, this disclosure is valuable, though it omits other traits like waiting, retry logic, or failure outcomes.
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?
Two efficient sentences: first states purpose, second adds critical behavioral detail. No unnecessary words, information is front-loaded.
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?
Covers purpose and a key behavioral trait, but lacks details on parameters (button, clickCount), preconditions (snapshot dependency), error handling, and output (none provided). For a simple click tool with no annotations, the description is adequate but has notable gaps.
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 33% (only ref described). Description adds minimal parameter context: it mentions ref addressing but does not explain button (left/right/middle) or clickCount (double-click, triple-click). The description does not compensate for the low 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?
Clearly states 'Click an element addressed by its ref', identifying the action and target. Distinguishes from sibling tools like browser_type (typing) and browser_select (selection) but doesn't explicitly contrast them.
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?
No guidance on when to use this tool versus alternatives (e.g., browser_type or browser_select). The mention of SAB_HUMAN_MOUSE suggests a scenario for evasion, but no explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JS EXPRESSION in the page's MAIN execution world. Observable by page scripts; use sparingly. Prefer AOM + action tools.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | JS expression (not a statement). Executes in the page's MAIN execution world — observable by page scripts. Use sparingly; prefer AOM + actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that execution is observable by page scripts, which is a key behavioral trait. Without annotations, the description should provide more about error handling, return value, or side effects, but it does not.
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?
Two concise sentences, front-loaded with the core purpose. Every sentence provides unique value without 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?
Given high schema coverage, single parameter, and no output schema, the description adequately covers purpose and usage guidelines. It could improve by noting that the tool returns the expression's evaluated result, but overall is sufficiently complete for its simplicity.
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 100% for the single parameter. The tool description adds minimal value beyond the schema, merely restating the same information. Baseline score of 3 applies.
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?
Clearly states it evaluates a JS expression in the page's main execution world. Verb 'evaluate' and specific resource differentiate it from sibling tools that perform other browser actions.
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?
Explicitly advises to use sparingly and prefer AOM + action tools, providing clear when-to-use guidance. However, it lacks explicit exclusions or detailed alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the active browser session and start a fresh one with the current config. Required after 'browser_set_proxy' to actually route new requests through the proxy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states that the tool closes the active session and starts a fresh one, which implies destructiveness (session state is lost). This is sufficient for a restart tool. No contradictions.
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 consists of two concise sentences. The first sentence states the main action, and the second adds a crucial use case. No redundant 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?
Given no parameters and no output schema, the description is complete. It explains the tool's purpose, the fact that it uses current config, and a key scenario (after set_proxy). This is all needed for a simple restart tool.
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 input schema has zero parameters, so schema coverage is 100%. The baseline for 0 parameters is 4. The description does not need to add parameter semantics since there are none.
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 function: close the active browser session and start a fresh one. This distinguishes it from sibling tools like browser_navigate (navigates within same session) and browser_set_proxy (changes proxy, but requires restart). The verb 'restart' and resource 'browser session' are specific.
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 explicitly notes that this tool is required after 'browser_set_proxy' to route new requests through the proxy. This provides clear context for when to use it. However, it does not mention any scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll and return a Readability-extracted Markdown view. With deltaOnly=true, returns '(no change)' if nothing new became visible — keeps context windows lean.
| Name | Required | Description | Default |
|---|---|---|---|
| pixels | No | ||
| deltaOnly | No | Return markdown only if the readable content changed since the last call. | |
| direction | No | down |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the deltaOnly behavior and its effect on output ('(no change)' if nothing new). However, it does not mention scrolling mechanics, boundary conditions, or what happens if the page is not fully loaded.
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?
Two short sentences that are front-loaded with the main purpose. Every sentence adds value with no redundancy. Highly efficient.
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 3 parameters, no annotations, and no output schema, the description covers the core functionality but omits details about scrolling behavior, pixel amounts, direction options, and return format structure. Adequate but with clear gaps.
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 only 33% (deltaOnly described). The description adds value by explaining deltaOnly's behavior, but it does not describe the 'pixels' or 'direction' parameters, which remain undocumented. The description partially compensates for low 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's action ('Scroll and return') and the output format ('Readability-extracted Markdown view'). It uniquely identifies the tool among siblings which are different browser actions (click, type, navigate, etc.).
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 scrolling and reading content but does not explicitly state when to use this tool over alternatives like 'browser_snapshot' or 'browser_eval'. No when-not or alternative usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select one or more options in a addressed by ref.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | ||
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether it clears previous selections, supports multiple selections (implied by array but not stated), or waits for elements. The agent has no information on side effects or error handling.
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 one short sentence, which is concise and front-loaded with the action. However, it lacks structure and could benefit from additional details without being verbose.
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 no output schema, no annotations, and minimal parameter explanation, the description is incomplete. It does not describe return values, error conditions, or behavioral nuances like handling of multiple selections or invalid references.
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 the description must compensate, but it only says 'addressed by ref' and 'Select one or more options'. It does not explain what 'ref' is (selector format) or what 'values' represent (option values, labels, or indices). Minimal added meaning.
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 'Select' and the resource 'options in a <select>' addressed by 'ref'. It distinguishes from sibling tools like browser_click or browser_type which do different actions. However, it does not clarify what 'ref' refers to (e.g., CSS selector), slightly reducing clarity.
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?
No guidance on when to use this tool versus alternatives or when not to use it. The description does not mention that it is specifically for <select> elements, nor does it exclude other uses. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the proxy config. Call 'browser_restart' after this for the change to take effect (browser-level constraint — an existing context cannot be re-routed).
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | e.g. http://host:port — omit to clear. | |
| password | No | ||
| username | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the need for a restart and the constraint on existing contexts, but omits details on authentication requirements, destructiveness, or 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 two sentences with no redundant words. It front-loads the main action and immediately provides the critical follow-up step.
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 three parameters, no output schema, and no annotations, the description is adequate but incomplete. It explains the update and restart requirement but lacks parameter semantics and comprehensive behavioral context.
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 has low description coverage (33% with only 'server' described). The tool description does not explain any parameters beyond the general 'proxy config', failing to add meaning for 'username' or 'password'.
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 'Update the proxy config', which is a specific verb and resource. It is distinct from the sibling 'browser_set_proxy_pool' by name, but no explicit differentiation is provided.
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 advises calling 'browser_restart' after setting the proxy and mentions a browser-level constraint, implying a specific workflow. However, it does not discuss when to use this tool versus alternatives like 'browser_set_proxy_pool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the residential proxy pool at runtime. Takes effect on the next 'browser_restart'. Supports sticky sessions via SAB_PROXY_STICKY_TEMPLATE.
| Name | Required | Description | Default |
|---|---|---|---|
| pool | No | Residential proxy pool: comma-separated URLs (http://u:p@host:port) or a JSON array. Omit to clear. | |
| rotation | No | Rotation strategy. Default: per-restart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that changes are deferred until restart and mentions sticky session support via environment variable, which are important behavioral traits. However, it does not detail error conditions or immediate 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 two sentences, front-loading the purpose and then adding crucial timing and sticky session info. 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?
Given no output schema and simple parameter set, the description adequately covers when effect applies and sticky session support. It could mention required permissions or error handling, but overall it is complete for its purpose.
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?
Input schema covers both parameters with descriptions. The description adds context about sticky sessions and runtime replacement, enhancing understanding beyond the schema. Baseline 3 raised due to this additional context.
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 explicitly states the action ('Replace the residential proxy pool') and the context ('at runtime'), clearly distinguishing it from sibling tools like browser_set_proxy which likely handles individual proxies.
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 informs that changes take effect after 'browser_restart' and supports sticky sessions, providing clear usage context. It does not explicitly list when not to use, but for a simple configuration tool this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a snapshot of the current page. 'aom' returns the accessibility YAML (token-lean); 'hybrid' adds a Set-of-Mark screenshot with numeric red boxes matching each ref.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'aom' = accessibility YAML only (cheap). 'vision' = raw screenshot. 'hybrid' = YAML + screenshot with red-boxed refs overlaid. | aom |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what each mode returns (YAML for aom, screenshot with overlays for hybrid) and implies read-only snapshot behavior. Lacks explicit statement about non-destructiveness or performance costs, but sufficient for a snapshot tool.
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?
Two sentences, front-loaded with primary purpose, then details about modes. No redundant 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?
With no output schema, description partially explains return values (aom and hybrid) but omits 'vision' mode return. Lacks complete coverage of all modes despite having only one parameter.
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 covers mode parameter with enum values and descriptions (100% coverage). Tool description adds useful context like 'token-lean' and 'Set-of-Mark screenshot', but 'vision' mode is only described in schema, not in main description.
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?
Clearly states 'Take a snapshot of the current page' with specific verb and resource. Lists three distinct modes, differentiating from sibling tools like browser_scroll_read or browser_click which do other actions.
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or use cases relative to siblings like browser_scroll_read for reading text or browser_wait_for for waiting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fallback captcha solver. Detects Turnstile/hCaptcha/reCAPTCHA on the current page (or takes an explicit sitekey), submits to the configured provider (CapSolver or 2Captcha per SAB_CAPTCHA_PROVIDER + SAB_CAPTCHA_API_KEY), polls for a token, and injects it into the widget's response field.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Override auto-detection. Otherwise the active page is scanned for a known widget. | |
| pageUrl | No | Page URL the captcha is bound to. Defaults to the current page. | |
| sitekey | No | Provide explicitly when auto-detection fails. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the process but omits behavioral details like rate limits, costs, timeouts, or what happens on failure. The dependency on env vars (CapSolver/2Captcha) is mentioned but not explained.
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 a single sentence that efficiently conveys the main workflow. It is clear and front-loaded with the tool's role, though slightly dense with multiple clauses.
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?
No output schema exists, but description does not explain return values (e.g., success flag or token). Input parameters are well-covered. Absence of failure/error handling info and provider configuration details makes it adequate but not 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?
Schema description coverage is 100%; the description adds little beyond schema descriptions (e.g., 'Override auto-detection' for type). Baseline 3 applies as schema already documents parameters adequately.
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 the tool is a fallback captcha solver for Turnstile/hCaptcha/reCAPTCHA, with specific steps: detect, submit to provider, poll, inject. Verb and resource are explicit, and it is distinct from all sibling browser tools.
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 term 'fallback' implies usage when other methods fail, but no explicit guidance on when to use this tool versus alternatives, nor when not to use it. No mention of prerequisites like provider configuration beyond env var names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage browser tabs: list, new, close, switch.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| index | No | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only lists actions but does not disclose behavioral traits such as side effects (e.g., closing a tab loses state), prerequisites (e.g., index required for switch/close), or authorization needs. The actions are named but their exact behavior is vague.
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 extremely concise (one line). While concise, it sacrifices clarity and structure. A list of actions without elaboration is too terse to be fully helpful, but it does front-load the key purpose.
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 lacks details about return values, prerequisites, and action-specific behavior. For a tool with 3 parameters and multiple actions, this is insufficient. No output schema or annotations exist to compensate.
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 input schema has 0% description coverage, and the tool description does not add meaning beyond the schema. The description lists actions but does not explain the roles of 'url' and 'index' parameters, leaving ambiguity about which actions require 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 'Manage browser tabs: list, new, close, switch.' It specifies both the resource (tabs) and the actions, distinguishing it from sibling tools like browser_navigate or browser_click.
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?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention that browser_navigate is for changing the current tab's URL, while browser_tabs with action 'switch' changes the active tab. The description lacks context for when to use each action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type into an input or textarea addressed by ref.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Ref of an input/textarea element. | |
| text | Yes | ||
| clear | No | Clear the field before typing. | |
| submit | No | Press Enter after typing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'type into' but does not disclose behavioral details like waiting for element, clear behavior (though default in schema), keyboard event simulation, or error handling when ref not found.
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?
Single sentence, front-loaded with purpose, no redundant information. Every word is meaningful.
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 simple typing action, the description covers the basic purpose but omits critical context like whether it waits for the element, what happens if ref is invalid, and how special keys are handled. Adequate but not 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?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The description adds the context that ref addresses an input/textarea, but doesn't explain the 'text' parameter. Baseline 3 due to high coverage, but no extra value 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 the action ('type') and the target ('input or textarea addressed by ref'). It distinguishes from sibling tools like browser_click (click) and browser_select (select).
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?
No guidance on when to use this tool vs alternatives, no prerequisites, and no conditions for appropriate usage. The description lacks any context about when to type versus when to use other browser interaction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until either some text appears on the page or a given ref resolves to a visible element.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Ref that must resolve to a visible element. | |
| text | No | Substring to wait for in page text. | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks details on timeout behavior, return value, polling mechanism, or what happens when both conditions are true.
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?
Single sentence, no redundancy, well-formed.
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?
No output schema, no annotations, and description omits return value, error handling, and behavior edge cases. Incomplete for a tool with 3 parameters and implicit complexity.
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 67% (low), and the tool description adds no extra meaning beyond the schema descriptions. Does not explain how 'ref' resolves or what 'visible element' means.
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?
Clear verb 'wait' and specific conditions: text appearance or visible element. Distinct from siblings like browser_click or browser_navigate.
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?
No guidance on when to use versus alternatives or when not to use. Does not explain when to choose text vs ref condition.
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. Dates show when Glama detected each change.
v0.2.0browser_clickbrowser_evalbrowser_navigatebrowser_restartbrowser_scroll_readbrowser_selectbrowser_set_proxybrowser_set_proxy_poolbrowser_snapshotbrowser_solve_captchabrowser_tabsbrowser_typebrowser_wait_forScored across 13 tools
Each tool targets a distinct action: scrolling, waiting, navigation, snapshot, clicking, typing, selecting, tab management, JS evaluation, proxy configuration, and captcha solving. No overlapping purposes.
Tools consistently use the browser_ prefix with verb or verb+noun patterns (e.g., browser_navigate, browser_set_proxy). The exception is browser_tabs (noun) which deviates slightly but remains clear.
13 tools cover the core browser automation tasks without being excessive. Each tool has a clear role, and the count is well-scoped for the server's purpose.
Covers navigation, interaction, proxy management, and captcha solving comprehensively. Minor gaps exist, such as missing back/forward navigation or visual screenshot (snapshot returns AOM only), but most workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
A paid remote MCP for AI agent browser MCP session, built to return verdicts, receipts, usage logs,
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ykshah1309/stealth-agent-browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server