Switch to a specific browser tab by providing its tab ID and the required profile_id from profiles_list, keeping tab IDs scoped to that profile.
Switch to a specific browser tab
profile_id is required: obtain it from profiles_list. All object IDs are local to that profile; never reuse them in another profile.
| Name | Required | Description | Default |
|---|---|---|---|
| tab_id | Yes | ID of the tab to switch to | |
| profile_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds genuinely valuable context about identifier scoping (object IDs are local to a profile). But it doesn't disclose side effects an agent would care about: whether switching activates/focuses the containing window, what happens if the tab is in a background window, or failure modes for invalid tab_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action front-loaded and the prerequisite guidance following. Nothing is padded or restated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the ID-provenance rule is covered. But for a state-changing browser action with zero annotation coverage, the description leaves the agent guessing about side effects (window focus/raise) and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — tab_id is documented in the schema, profile_id is bare there. The description compensates by telling the agent where to get profile_id and warning against cross-profile reuse, which is more than the schema provides. However, the baseline for a partially-covered two-parameter schema lands at 3 since no format/range detail is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'switch to a specific browser tab' — which is unambiguous and distinguishable from window-level siblings like focus_window and from tabs_list/tabs_create. It stops short of explicitly naming those alternatives, but the tab-vs-window scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a real prerequisite workflow: obtain profile_id from profiles_list, and don't reuse IDs across profiles. That is useful usage guidance. However, it never says when to use this versus focus_window, or whether the tab must already exist in an open window, so the when-to-use decision is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.