list_tabs

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully states that URLs are only returned to the local MCP client, addressing a privacy-relevant behavior. Yet it does not explicitly confirm the operation is read-only or describe any other side effects, though 'List' strongly implies a non-mutating action.

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 remarkably efficient: a single action statement followed by a one-sentence behavioral note. Every word contributes meaning, with the core purpose front-loaded and no filler or redundant schema repetition.

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 parameterless tool, the description gives enough to invoke it correctly: what it lists, which tabs it covers, and a privacy constraint on the returned URLs. It does not describe return structure beyond URLs, but the absence of an output schema means some details are left unspecified; this is a minor gap for such a simple tool.

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?

The tool has zero parameters, so parameter semantics are essentially moot. The description provides all necessary context for invocation, and the schema's 100% coverage of an empty parameter set requires no further elaboration.

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 uses a specific verb ('List') and resource ('normal Chrome tabs'), making the tool's function immediately clear. It also adds a meaningful scope qualifier ('normal') and a privacy note about URLs, which helps distinguish it from broader browser-state tools like browser_status.

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 phrase 'normal Chrome tabs' implies when the tool is appropriate, suggesting it is meant for ordinary tab enumeration rather than special or internal tabs. However, it gives no explicit guidance about alternatives or when not to use it, leaving the agent to infer usage context from sibling tool names.

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