list_tabs

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

With zero annotations, the description bears the full burden of behavioral disclosure, and it delivers. It explicitly declares the read-only contract ('Side effects: none (read-only registry snapshot)'), documents the return shape ('active_tab_id', 'tabs' array with tab_id, label, target_id, url), explains the non-obvious semantic that active_tab_id is the default target for other tools, and discloses the edge-case fallback to a default single-tab connection when no tabs are registered. No annotation contradiction exists.

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?

Six sentences, each earning its place: purpose, safety contract, return structure, edge-case fallback, usage intent, and alternative. There is zero filler and the most decision-relevant facts (what it lists, that it's read-only) come first. Dense yet never bloated.

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?

Given there is no output schema, the description fully compensates by specifying the return contract in detail, including the 'note' fallback field for the empty-tab edge case. With a single optional parameter, no annotations, and no output schema, only the param semantics could be considered covered by the schema — everything an agent needs to call this tool correctly is present.

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 100%, and the instance_id parameter already carries a solid description ('Chrome instance id from open_instance/list_instances. Omit for the default instance.'). The tool description adds marginal param context ('in the specified Chrome instance') but doesn't need to do so since the schema covers it. Baseline 3 applies as the schema does the heavy lifting here.

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 specific verb and resource — 'Lists all tabs currently open and registered in the specified Chrome instance' — which immediately distinguishes it from siblings like open_tab, close_tab and switch_tab. It further disambiguates itself by naming the sibling 'list_instances' that could be confused with it. This is a textbook case of precise scoping.

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?

It gives an explicit task-level directive: 'Use this to discover Tab IDs before passing tab_id to other tools', telling the agent exactly when in a workflow to invoke it. It also names the closest alternative ('Alternatives: list_instances to enumerate Chrome instances') with the condition that selects it (instance-level vs tab-level enumeration). This leaves nothing to inference.

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