Skip to main content
Glama

list_tabs

List all open Safari tabs with their window and index handles, showing titles and URLs, to identify which tab to control.

Instructions

List every open Safari tab, with the handle you use to address it.

Call this first. Every other tool takes a tab argument, and this shows you what is addressable: a 1-based index within window 1, or any distinctive substring of a tab's URL or title.

Returns one line per tab as [w<window>:t<index>] <title> — <url>.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden itself. It discloses the addressing scheme (1-based index within window 1 or URL/title substring) and the exact one-line return format. It doesn't spell out side-effect-freedom or edge cases, but 'List' and the output format make the read-only behavior clear enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, focused paragraphs with no filler. The main purpose is front-loaded, and each sentence adds a distinct piece of information: purpose, when to call it, handle format, and output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with an output schema, the description is complete: it states scope, return format, and how the result should be used downstream. No critical information is missing for an agent to select and call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the empty schema is already complete. The description adds useful context about what the returned handle means, which is the closest analog to parameter semantics for this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 Safari tab') and immediately explains what makes this tool distinct: it returns the handle needed by other tab-based tools. It differentiates from siblings by framing itself as the discovery/entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit directive ('Call this first') and explains why, stating that other tools take a tab argument and need the handle this tool provides. This tells an agent when to invoke it relative to every sibling.

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