List all open browser tabs, returning each tab's ID, title, and URL so you can target specific tabs with other tools.
List every open tab. Returns an array of {id, title, url}. The ids are what every other tool's optional tabId argument accepts; omit tabId and a tool acts on the active tab, which is rarely what you want once you have opened tabs of your own.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: the returned ids are the shared contract used by all sibling tools, and omitting tabId selects the active tab, which is rarely desired. This is precisely the kind of cross-tool behavior an agent needs to know.
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?
Two sentences with no wasted words. The core action and return format are front-loaded, and the second sentence earns its place by explaining the practical relationship to every other tool's tabId argument.
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 zero-parameter list tool, the description is complete: it names what is returned, the fields in each item, and how those fields are used by sibling tools. Even without an output schema, the agent has everything needed to call this tool and interpret its results correctly.
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?
This tool has zero parameters and an empty input schema, so there is nothing for the description to clarify about parameters. The schema description coverage is 100% and the description avoids inventing parameter details, matching the baseline for a zero-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 specific verb and resource ('List every open tab') and then specifies the exact return shape as an array of {id, title, url}. It clearly distinguishes this tool from siblings like session_read_page or session_snapshot by focusing on tab enumeration and the ids consumed by other tools.
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 explains when this tool is useful: to obtain tab ids for other tools' optional tabId arguments. It also gives an explicit caution against relying on the active-tab default once you have opened your own tabs, effectively telling the agent when not to omit tabId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.