nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Select page

select_page

Idempotent

Select which open tab subsequent tool calls act on. Makes the active tab explicit and sticky when working across multiple sites or after a click opens a new tab.

Instructions

Choose which open tab every subsequent tool call acts on.

Without a selection, tools act on the most recently opened tab. Selecting makes that choice explicit and sticky — needed when a click opened a tab you now want to drive, or when working across several sites at once.

Indices come from list_pages and shift as tabs open and close, so the response lists them again. If the selected tab is later closed, the selection is dropped and the default applies again.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`browser`	No	Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.	default
`page_id`	Yes	Index of the page to select, as listed by list_pages.
`bring_to_front`	No	Also focus the tab in the real browser window. Default true. Many pages pause animations, timers and media while backgrounded, so leave this on unless you specifically want the page to stay hidden.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.5.0Sep 25, 2026

addedInput schema / properties / browser

Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}

First observedv1.7.2Aug 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

While annotations already note idempotentHint=true and destructiveHint=false, the description adds valuable behavioral context: the selection is 'sticky' and persists, indices shift as tabs open/close, and the selection is dropped if the tab closes. These details explain the lifecycle and side effects beyond what annotations convey, though it does not mention the focusing behavior of bring_to_front, which is documented in the schema.

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

Conciseness4/5

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

The description is concise and front-loaded, leading with the core action. It follows with default behavior, usage scenarios, and a caution about indices. It's a compact paragraph without redundancy, though a few sentences could be merged for even tighter structure. Overall, it's well-organized and each sentence earns its place.

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

Completeness5/5

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

Given the tool's moderate complexity and the presence of an output schema, the description covers all necessary aspects: what it does, when to use it, default behavior, index sourcing, and selection lifecycle. It does not need to explain return values because an output schema exists. The description is fully sufficient for an agent to invoke it correctly.

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?

With 100% schema description coverage, the baseline is 3, but the description adds value by explaining that page_id comes from list_pages and is unstable because indices shift. This contextualizes the parameter's meaning and warns agents about its volatility, which is not fully captured in the schema's brief description. It also clarifies the default for bring_to_front indirectly by referencing background behavior in the schema, though the description itself does not restate it.

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 states a clear verb and resource: 'Choose which open tab every subsequent tool call acts on.' It distinguishes this from sibling tools like list_pages (listing) and new_page (creating), and explicitly contrasts with the default behavior of using the most recent tab. This makes the tool's purpose unambiguous and separable from peers.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use scenarios: 'needed when a click opened a tab you now want to drive, or when working across several sites at once.' It also clarifies the default behavior when no selection occurs, which effectively tells when selection is unnecessary. This is strong guidance for an agent deciding between this tool and alternatives.

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

Deploy Server