Skip to main content
Glama
Sign In
Computer Use

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Select browser tab

browser_select_tab
Idempotent

Brings one of the agent's Chrome tabs into view for native keyboard input or screenshots. Most actions work on background tabs, so use it only when visibility is required.

Instructions

Make one of the agent's tabs the visible one in its window, for example before native keyboard input or a screenshot. browser_snapshot, browser_click, browser_type and browser_press_key work on background tabs, so most tasks never need this. The agent's tabs live in the user's Chrome window, so by default the tab is only shown when the user is already looking at one of the agent's tabs; otherwise it stays in the background, the user keeps their tab, and the reply says it was not brought to front. Pass bring_to_front=true to show it and raise its window regardless; that takes the window from the user, so use it sparingly. The user's own tabs are never selected.

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_select_tab"
  }
}

Input 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.
bring_to_frontNoShow the tab and raise its Chrome window even when the user is on one of their own tabs. Default false: the tab is only shown when the user is already on an agent tab.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.3
    • addedInput schema / properties / bring_to_front
      Added value: +{
+  "description": "Show the tab and raise its Chrome window even when the user is on one of their own tabs. Default false: the tab is only shown when the user is already on an agent tab.",
+  "type": "boolean"
+}
  2. 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"
+}
  3. 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"
  4. First observedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the default no-op-visible behavior, that the call still succeeds but the reply reports it was not brought to front, and that bring_to_front steals the window from the user. That is exactly the kind of consequence detail an agent cannot infer from readOnlyHint=false / idempotentHint=true, and nothing contradicts those hints.

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?

Front-loads the core action, then the when-not-needed note, then the user-impact caveat, then the scope bound. Every sentence carries a decision-relevant fact and there is no filler or restatement of the title.

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 4-parameter, zero-required, no-output-schema tool, the description covers trigger conditions, default behavior, the failure-to-raise outcome, and the user-disruption tradeoff. An agent can call this correctly without opening anything else.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3; the description earns more by adding the cost and scarcity guidance for bring_to_front ('takes the window from the user, so use it sparingly') and framing index as a fallback path. It does not add format or selection-precedence rules for index vs tab_id beyond what the schema states.

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?

Opens with a precise verb+resource+scope: makes one of the agent's tabs visible in its window. It also delimits scope ('The user's own tabs are never selected'). It does not distinguish itself from the similarly named browser_use_tab sibling, which is the one genuinely ambiguous boundary.

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?

Gives the positive case ('before native keyboard input or a screenshot'), the explicit when-not ('browser_snapshot, browser_click, browser_type and browser_press_key work on background tabs, so most tasks never need this'), and the escalation condition for bring_to_front with a caution to use it sparingly. Nothing is left to inference.

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