Skip to main content
Glama

wb_navigate

Open or navigate to a URL in a real Chrome browser, using group_title on the first task call and newTab:true when pages must coexist.

Instructions

Open or navigate to a URL in the real browser. First call of a task should pass group_title. Use newTab:true when pages should coexist.

Input Schema

NameRequiredDescriptionDefault
urlYesFull URL to open
newTabNoOpen in a new tab (default false)
sessionNoPer-call session override (does not change the process default)
group_titleNoHuman-readable tab group label

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.2/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. It adds useful behavioral context: the browser is 'real', group_title is expected on first call, and newTab controls tab coexistence. However, it does not disclose whether navigation waits for page load, what happens to the current tab by default, or any other side effects, leaving some uncertainty.

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 two sentences, front-loaded with the core purpose, and every clause adds value. There is no redundancy or filler.

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

Completeness4/5

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

The tool has 4 parameters without an output schema or annotations, but the description plus schema fully document all parameters and provide key usage guidance. It is adequate for a navigation tool, though it could mention whether navigation is synchronous or waits for load for greater completeness.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds operational meaning beyond the schema by clarifying when to use group_title (first call of a task) and newTab (when pages should coexist), which enhances schema descriptions like 'Human-readable tab group label' and 'Open in a new tab (default false)'.

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

Purpose5/5

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

The description uses a specific verb ('Open or navigate to') and identifies the resource ('a URL in the real browser'). It clearly distinguishes the tool from siblings like wb_go_back, wb_go_forward, and wb_reload, which handle navigation history rather than direct URL entry.

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

Usage Guidelines4/5

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

The description provides explicit usage context: 'First call of a task should pass group_title' and 'Use newTab:true when pages should coexist.' This tells the agent when to use the tool and how to apply options, though it does not explicitly discuss alternatives or exclusions relative to sibling navigation tools.

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