real-browser-mcp-server

navigate

Open URLs and manage browser tabs with configurable wait conditions, retries, timeouts, and automatic Cloudflare-style challenge handling.

Instructions

Navigate to a URL or manage browser tabs (list, switch, new tab, close tab). Supports configurable wait conditions, timeout, automatic retry on failure, and waitForChallenge to auto-solve Cloudflare-style JS challenges.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "navigate"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	URL to navigate to (required unless tabAction is list, new, or close without url)
`retries`	No	Retry count on failure
`timeout`	No
`tabIndex`	No	Zero-based index of the tab to switch to or close
`smartWait`	No	Wait for page content to stabilize before returning
`tabAction`	No	Tab management action: navigate (default), list (show all tabs), switch (switch active tab), new (open new tab), close (close tab)	navigate
`waitUntil`	No		networkidle
`autoSwitchNewTab`	No	Automatically switch to newly opened popups or blank target tabs
`challengeTimeout`	No	Max ms to wait for challenge to clear (with waitForChallenge)
`waitForChallenge`	No	After navigation, wait for Cloudflare-style JS challenge ("Just a moment") to auto-solve; returns challenge status + clearance cookies
`challengePollInterval`	No	Poll interval ms while waiting for challenge

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.3.14Oct 23, 2026
- addedInput schema / properties / challengeTimeout / maximum
```
Added value: +90000
```
- addedInput schema / properties / retries / maximum
```
Added value: +3
```
- addedInput schema / properties / timeout / maximum
```
Added value: +60000
```

Changed3 schema fields changedv3.3.10Oct 21, 2026

addedInput schema / properties / challengePollInterval

Added value: +{
+  "default": 2000,
+  "description": "Poll interval ms while waiting for challenge",
+  "type": "number"
+}

addedInput schema / properties / challengeTimeout

Added value: +{
+  "default": 90000,
+  "description": "Max ms to wait for challenge to clear (with waitForChallenge)",
+  "type": "number"
+}

addedInput schema / properties / waitForChallenge

Added value: +{
+  "default": false,
+  "description": "After navigation, wait for Cloudflare-style JS challenge (\"Just a moment\") to auto-solve; returns challenge status + clearance cookies",
+  "type": "boolean"
+}

First observedv3.2.13Sep 5, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosing behavior. It usefully mentions automatic retry, configurable wait conditions, timeout, and waitForChallenge auto-solving Cloudflare-style challenges, but it does not explicitly state side effects such as changing the active tab, closing tabs, or whether navigation requires browser initialization.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that first states the core action and then summarizes supporting capabilities. There is no wasted prose, and the parenthetical tab actions add useful detail without disrupting readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter browser automation tool with no output schema and no annotations, the description covers the main capabilities but omits return behavior, tab-index semantics, and prerequisites such as browser initialization. It is adequate alongside the detailed schema but not fully complete on its own.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 82%, so the schema already documents most parameters. The description mentions several capabilities (wait conditions, timeout, retry, waitForChallenge), but it does not add substantial meaning beyond the schema's own parameter descriptions, consistent with the baseline 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Navigate to a URL") and enumerates tab-management actions ("list, switch, new tab, close tab"), making the tool's scope clear. It does not explicitly name sibling tools to distinguish itself from get_content, wait, or browser_close, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool can do but gives no guidance on when to use it versus alternatives such as wait, get_content, browser_close, or solve_captcha. It does not state when-not to use navigation or how the tab actions should be selected in context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.