tab_select

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

Annotations declare a non-read-only, non-destructive, open-world mutation, so the agent knows this changes browser state. The description adds nothing about what actually changes: whether the previously active tab is affected, whether the browser window is raised, or whether the tab must exist in the current session. It does not contradict the annotations, but for a state-changing tool it discloses no behavior beyond the label.

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?

One short sentence, front-loaded with the action and the key, with the sibling pointer placed where it is immediately actionable. There is no waste, though the terseness borders on under-specification rather than tight conciseness.

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 need not be explained, and the tool surface is a single parameter, which keeps the burden low. Still, for a state-changing navigation-style tool, the description never says what "current" means afterwards or how failure (bad id, closed tab) is surfaced.

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 description coverage is 0% for the single tab_id parameter, so the description must compensate, and it partially does by pointing to tabs_list as the source of valid ids. It still gives no type/format hint (integer), no statement about what happens with an invalid or stale id.

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?

"Make a tab current by id" names a specific action (activate/switch) and the addressing key (id), and the "(see tabs_list)" pointer separates it from siblings like tab_new and tab_close. It is clear, but the slightly unusual phrasing "make current" leaves a small ambiguity about whether it means activate/focus or merely mark as selected.

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?

The parenthetical reference to tabs_list implies the prerequisite of obtaining a tab id first, which is genuinely useful routing. However, there is no statement of when not to use it, no note about which window/tab context applies, and no alternative named for other tab operations.

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