Skip to main content
Glama
munimtechnologies

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Select browser tab

browser_select_tab
Idempotent

Switches the visible Chrome tab to a specified agent tab so you can capture it with a screenshot or inspect it. Other actions work in the background, so use only when the window view matters.

Instructions

Make one of the agent's tabs the visible one in its window, for example before capturing it with screenshot. browser_snapshot, browser_click and browser_type work on background tabs, so most tasks never need this. The agent's group lives in the user's Chrome window, so this changes which tab that window shows; use it sparingly. The user's own tabs are never selected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexNo1-based position within the agent's tabs; fallback mode only, when tab_id is unavailable
tab_idNotab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs
session_idNoStable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.3
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Stable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}
  2. Changed2 schema fields changedv0.3.1
    • changedInput schema / properties / index / description
      Previous value: -"1-based index, fallback mode only"New value: +"1-based position within the agent's tabs; fallback mode only, when tab_id is unavailable"
    • changedInput schema / properties / tab_id / description
      Previous value: -"From browser_list_tabs"New value: +"tab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs"
  3. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the real-world side effect: the agent's tab group lives in the user's Chrome window, so selecting a tab changes what the user sees. It also clarifies that the user's own tabs are never selectedholistically and that the action is idempotent, matching idempotentHint=true.

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 description is three sentences with no filler. It front-loads the core purpose, then adds usage guidance and side-effect warnings, with every sentence earning its place.

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?

For a simple tab-selection tool, the description covers purpose, when to use it, when not to use it, side effects, and scope boundaries. The input schema fully documents all parametersable, and there is no output schema, so no return-value explanation is required.

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%, so the baseline is 3. The description does not add parameter-level meaning beyond what the schema already provides, but it does reinforce the fallback relationship for index and the source of tab_id indirectly through the tool description.

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 description states a specific verb and resource: 'Make one of the agent's tabs the visible one in its window.' It also differentiates from related browser tools by noting that browser_snapshot, browser_click, and browser_type work on background tabs, clarifying why this tool is rarely needed.

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?

The description explicitly gives a usage example ('before capturing it with screenshot'), explains that most tasks never need it because other browser actions work on background tabs, and warns to use it sparingly because it changes the user's Chrome window. This is strong when-to-use guidance.

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