Skip to main content
Glama
Sign In
sommus-laptop

sommus-laptop

by Jashan-Mshadow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_browser_tabs

Read-only

Retrieve every open Chrome tab with its window/tab number, title, and URL to quickly audit or locate pages across browser windows.

Instructions

List every open Chrome tab with its window.tab number, title and URL.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_browser_tabs"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, so the description's added value is disclosing the return shape (window.tab number, title, URL). It adds nothing about ordering, tab scope, or whether it covers all windows, so it beats the annotation floor only modestly.

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?

A single front-loaded sentence with no filler; the resource and the returned fields are stated immediately, and nothing is repeated from the schema or annotations.

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

Completeness4/5

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

With no parameters and no output schema, the description is the only place the return shape can be conveyed, and it does so correctly. Minor gaps remain: nothing about ordering, limits, or whether multiple windows are included.

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 zero parameters, so per the baseline this dimension scores 4. There is no argument syntax the description could usefully clarify.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('every open Chrome tab') and even enumerates the returned fields (window.tab number, title, URL). This distinguishes it implicitly from siblings like list_page_links and read_browser_tab, though it never names those alternatives explicitly.

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

Usage Guidelines2/5

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

The description gives no when-to-use, when-not-to-use, or alternative guidance. An agent must infer from the scope statement alone that this is the right tool for enumerating open tabs rather than reading one tab's content or listing in-page links.

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

Deploy Server

Other Tools