Skip to main content
Glama

browser_new_tab

Opens a new browser tab and optionally navigates to a specified URL, letting AI clients start a blank tab or load a page for automation.

Instructions

Open a new browser tab, optionally navigating to a URL

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": "browser_new_tab"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoURL to open (defaults to about:blank)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the new tab becomes the active/focused tab, whether it is created in the foreground or background, whether it returns a tab identifier needed by browser_switch_tab, or whether the call waits for page load when a URL is supplied.

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?

One short sentence with the action front-loaded and the optional behavior trailing. Nothing is wasted and nothing is buried.

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 a one-parameter tool this is close to adequate, but with no annotations and no output schema the description should clarify whether a new tab becomes active and what handle (if any) is returned, since that determines whether browser_switch_tab or browser_list_tabs must follow. Those gaps matter in a large tab/navigation sibling set.

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 100% and the single url parameter already documents the about:blank default. The description's "optionally" reinforces that url is not required, but adds no format, scheme, or validation detail beyond the schema; baseline 3 applies.

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 gives a specific verb and resource ("Open a new browser tab") plus the optional navigation behavior, so the action is unambiguous. It does not, however, distinguish itself from the sibling browser_navigate, which an agent could easily confuse with opening a tab at a URL.

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?

There is no statement of when to use this versus browser_navigate, browser_switch_tab, or browser_list_tabs, nor any prerequisites or exclusions. The only hint is "optionally navigating to a URL," which describes the parameter rather than tool selection.

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