Skip to main content
Glama

Browser Tab Select

browser_tab_select

Select a browser tab by its index to make it active for subsequent automation actions.

Instructions

Make another tab active (subsequent tools act on it).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYes
sessionNodefault

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description must supply behavioral context; it does state a persistent side effect—'subsequent tools act on it'—which tells the agent that the selection changes the target of later calls. It does not disclose error behavior for invalid indices or confirm whether the operation is non-destructive, so more depth would help.

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?

The entire description is one short sentence and gets the key information up front. There is no filler, no restatement of the tool name, and the parenthetical adds essential behavioral context without redundancy.

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?

The description is enough to understand the high-level purpose, but for a correct invocation you still need to know how to obtain a valid `index` and what `session` means; those are absent. The presence of an output schema reduces the need to describe return values, so the main gap is around parameter sourcing.

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?

Schema description coverage is 0%, and the description says nothing about the `index` or `session` parameters beyond the word 'tab'. An agent cannot tell how indices are ordered, whether they are 0-based, or how `session` relates to the default session.

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 phrase 'Make another tab active' is a specific verb-resource statement, and the parenthetical 'subsequent tools act on it' clarifies the operational effect. It clearly separates this from siblings like browser_tab_close, browser_tab_new, and browser_tab_list, even though it does not name them.

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

Usage Guidelines4/5

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

The parenthetical gives a concrete usage context: call it before other browser tools when you want those tools to target a different tab. It does not explicitly state when not to use it, but the intended position in a sequence of browser actions is clear.

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