Skip to main content
Glama
Sign In
chromaphore-mcp

chromaphore-mcp

Official
by nodriver-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Open a tab

tab_new

Opens a new browser tab and selects it as the active target so other tools operate on that tab. Use it to start work in a fresh page context.

Instructions

Opens a tab and selects it; the other tools act on the selected tab.

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

Input Schema

NameRequiredDescriptionDefault
urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 behavioral burden. It usefully discloses the side effect that the new tab becomes selected and therefore changes the target of all subsequent tools, but it says nothing about whether an existing tab is reused, what happens on failure, or whether browser installation/initialization is required.

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 primary action front-loaded and the state consequence attached. Nothing is redundant or padded.

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

Completeness2/5

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

The tool is simple, but with no annotations, no output schema, and an entirely undocumented optional parameter, the description leaves real gaps: what url does, what is returned (e.g. a tab handle or index), and whether prerequisites like a running browser apply.

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

Parameters2/5

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

The single 'url' parameter has 0% schema description coverage, and the description never mentions it at all. An agent cannot tell from the definition what value to pass or whether omitting this optional parameter yields a blank tab, so the description fails to compensate for the schema gap.

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 states a specific verb and resource ('Opens a tab') plus a key effect ('selects it'), so an agent can distinguish creating a tab from switching to one (tab_select) or closing one (tab_close). It stops short of explicitly contrasting itself with browser_open or tab_select, so it is clear but not fully sibling-differentiated.

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

Usage Guidelines3/5

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

'the other tools act on the selected tab' conveys the important state model that makes opening a tab meaningful, and implies this is the way to create a new browsing context. However, it never says when to prefer this over tab_select or browser_open, nor what happens when a tab is already open.

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

Deploy Server

Other Tools