Browser Session MCP

Overview Schema Source Related Servers Discussions Admin

new_page

Opens a new browser tab and makes it active, optionally loading a URL, so subsequent navigation, click, type, and screenshot actions target that tab.

Instructions

Open a new tab in the session and make it the active tab, so later navigate/click/type/screenshot calls act on it. Use navigate instead to load a URL in the current tab, and switch_tab to go back to an existing one. Tabs stay open until close_tab or close_browser_session, so close ones you no longer need. With url, the tab loads it and the call returns after the load event; if the URL fails to load, the call errors but the new tab still exists and is active. The returned index is the new tab's list_pages index.

Input Schema

Name	Required	Description	Default
`url`	No	Absolute URL to load in the new tab. Omit for about:blank.
`sessionId`	Yes	The id returned by open_browser_session. Errors if no open session has it.

Output Schema

Name	Required	Description	Default
`url`	Yes
`index`	Yes	The tab's 0-based list_pages index.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Oct 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "index": {
+      "description": "The tab's 0-based list_pages index.",
+      "format": "uint",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "index",
+    "url"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / sessionId / description

Added value: +"The id returned by open_browser_session. Errors if no open session has it."

addedInput schema / properties / url / description

Added value: +"Absolute URL to load in the new tab. Omit for about:blank."

First observedv0.1.2Oct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (which only declare it is a non-readonly, non-idempotent, open-world, non-destructive mutation) by disclosing the load-event timing semantics, the partial-failure behavior ('the call errors but the new tab still exists and is active'), and the persistence model. The error-still-mutates detail is exactly the kind of trait that prevents an agent from retrying blindly and creating duplicate tabs.

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?

Front-loads the core action and its activation side effect in the first clause, then layers routing, lifecycle, and error semantics in decreasing order of importance. Every sentence carries distinct information — routing, cleanup, load timing, failure mode, return value — with no repetition of the schema or annotations.

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?

With only 2 parameters and an output schema present, the description covers everything an agent needs: what is created, that it becomes active, how long it lives, what happens on load failure, and how the returned index relates to list_pages. Nothing material is left to inference.

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 schema already documents both parameters and the about:blank default, making the baseline 3. The description adds real meaning on top: that supplying `url` blocks the call until the load event and how failure is surfaced. It does not restate sessionId semantics, which is fine since the schema covers them.

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?

States a specific verb and resource ('Open a new tab in the session') plus the side effect that matters most ('make it the active tab'), and immediately explains the downstream consequence for navigate/click/type/screenshot calls. It explicitly names the siblings it is not (navigate, switch_tab), so an agent can route correctly without opening any schema.

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?

Gives explicit when-to-use versus alternatives: 'Use navigate instead to load a URL in the current tab, and switch_tab to go back to an existing one.' It also names the two cleanup paths (close_tab, close_browser_session) and warns that tabs persist otherwise, covering the resource-leak avoidance case an agent would otherwise miss.

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