browser_tabs

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

The description adds meaningful behavioral context beyond the annotations: tabs opened by the page appear in observations automatically, indexes are positional and get renumbered, `target_id` is a `#handle`, and `url` is validated against the domain envelope. This goes well beyond the readOnly/openWorld/destructive hints. It is not contradictory to the annotations; closing tabs is consistent with destructiveHint=false since no data destruction is implied.

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?

The description is compact, front-loaded with the primary purpose, and each subsequent sentence earns its place by clarifying tab handles, index semantics, current-tab behavior, and URL validation. There is no filler or repetition of schema data.

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?

The description explains the trickiest aspects of tab management and an output schema exists, so return values are not required. But it still omits the allowed `action` values (beyond inferring them from the first sentence) and leaves `session` undefined, so an agent cannot fully determine correct invocation for all intended uses.

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?

With 0% schema description coverage, the description carries the burden of explaining parameters. It does this well for `target_id`, `index`, and `url`, explaining the handle mechanism, positional instability, and domain-envelope check. However, it never documents `action` values beyond `action="list"` or explains the `session` parameter at all, leaving meaningful gaps for a 5-parameter tool.

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?

The description opens with a clear verb-resource pair: 'List, open, switch to, or close tabs.' This makes the tool's domain obvious and distinguishes it as tab-focused from siblings like browser_open or browser_observe. It loses the top score because it advertises multiple operations rather than one specific verb and does not explicitly contrast itself with overlapping siblings.

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 description gives concrete direction on how to use the tool: prefer `target_id` over `index`, use `index` only when listing and acting in the same breath, and omit both to mean the current tab. It also explains the domain-envelope check for `url`. It stops short of explicit when-not-to-use or alternative-tool routing, so it earns a 4 rather than a 5.

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