Open, navigate or activate a tab

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

Annotations declare destructiveHint=true and openWorldHint=true; the description usefully adds policy-level behavior beyond that — the permission precondition for create, the http/https restriction, the same-site constraint on user tabs, and the guarantee that the user's tabs are never closed. What it omits is retry/idempotency behavior and the consequence of reload on unsaved state.

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?

Five compact clauses, one per action, ordered to match the enum, with the most restrictive constraint (permission requirement) attached to the first action. No filler sentences and nothing repeated 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?

For a six-parameter, five-action mutation tool with no output schema, the description covers the decision-relevant behavior for every action and the safety boundaries around user-owned tabs. It could still say what create/navigate return (e.g. tab id for later context_id use) since there is no output schema to fall back on.

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 67% and the schema itself documents active, context_id, request_id and browser_instance_id, including the retry guidance for request_id. The description adds no parameter-level detail (no mention of url format, context_id source, or when browser_instance_id is needed), so it neither compensates nor regresses. Baseline 3 applies given the schema already carries the parameter load.

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?

Each enum action is given a concrete verb and scope: create opens a new tab, navigate goes to a URL, activate brings a shared tab forward, close_owned closes a tab you created. It distinguishes own tabs from the user's tabs, which is the key resource boundary. It stops short of explicitly differentiating itself from siblings like browser_contexts or browser_handoff.

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?

Per-action conditions are stated inline: create only 'if the user allowed it', navigate is 'any site' for your own tabs but 'same site only' for the user's tabs, and close_owned is 'never the user's tabs'. That is strong when-to-use guidance. It never names an alternative sibling tool or an exclusion case where a different tool should be chosen.

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