Navigate to a URL and get the page title and final URL. Fetches static pages without a full browser, then automatically uses Chrome DevTools for JavaScript-heavy sites.
Navigate to a URL. Returns page title and URL. v4: static-first — plain pages are fetched + extracted with zero Chromium; JS pages escalate to CDP automatically (see mode field).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to navigate to |
Changes observed during successful MCP inspections.
v2.0.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully explains the static-first fetch strategy, automatic escalation to CDP for JavaScript-heavy pages, and that the result includes title and URL. It does not mention side effects such as replacing the current page state or wait-for-load behavior.
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 front-load the core purpose and return values, then add a compact, relevant note about static-first behavior. Every sentence earns its place with no filler or repetition.
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 one-parameter navigation tool, the description covers the essential inputs, outputs, and the static-vs-JS handling strategy. The main gap is the reference to a 'mode field' without explaining its possible values, especially since no output schema is provided to fill that in.
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 single parameter is already fully described in the schema ('URL to navigate to'), and the description only repeats the notion of a URL. Since schema coverage is 100%, the baseline of 3 applies; the description adds no extra guidance about URL formats or edge cases.
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 a specific action ('Navigate to a URL') and identifies key return values ('Returns page title and URL'). It is easy to tell this is the core navigation tool, but it does not explicitly differentiate itself from sibling navigation-related tools such as browser_newTab or browser_back.
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 intended use is implied: an agent should call this when it needs to navigate to a URL. However, the description gives no explicit guidance on when to prefer browser_goto over alternatives like browser_newTab, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.