Skip to main content
Glama

new_page

Open a URL in Chrome, reusing an existing tab when possible and loading it in a background tab only if no matching tab exists.

Instructions

Open a page. It first looks for an already open tab: same URL is reused as is, same site is reused and navigated. A new background tab is opened only if none exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to load in a new page.
timeoutNo
forceNewNoSkip the tab reuse check and always open a new tab.
backgroundNoOpen in the background without bringing it to the front. Default is true.
isolatedContextNoNot supported by the extension bridge. Ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.3

TDQS

B3.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 usefully discloses the tab-reuse algorithm (same URL reused, same site reused-and-navigated, else new background tab), which is genuinely beyond the schema, but omits failure modes, load/timeout behavior, and permission needs.

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?

Front-loaded with the core action, then three dense clauses covering the reuse decision. No filler; appropriately sized for the behavior described.

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?

Covers the essential reuse behavior for a page-opening tool with no output schema, but leaves the critical distinction from navigate_page and any error/failure handling unstated. Adequate but with clear gaps.

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 coverage is 80%, so the schema already documents url, forceNew, background, and isolatedContext. The description's reuse narrative implicitly contextualizes forceNew and background but adds no new parameter-level detail. The undocumented timeout is not addressed.

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?

States a specific verb and resource ('Open a page') and conveys the reuse semantics that define the tool. It does not, however, distinguish itself from the sibling navigate_page, which an agent must otherwise infer.

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 explicit guidance on when to use new_page versus navigate_page, select_page, or list_pages. The reuse logic describes behavior but stops short of routing the agent between alternatives.

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