Skip to main content
Glama
Sign In
chromaphore-mcp

chromaphore-mcp

Official
by nodriver-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List tabs

tab_list
Read-only

Lists open browser tabs with IDs, titles, and URLs, and marks the selected tab to help identify and target tabs.

Instructions

The open tabs, with ids, titles and URLs; the selected one is marked.

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": "tab_list"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/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 earns credit for the extra context it adds: the response contains ids, titles, URLs, and a marker for the currently selected tab. Since there is no output schema, this return-content disclosure is genuinely load-bearing. It omits ordering behavior and whether tabs from all windows are included.

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 compact clause that front-loads the resource and then the payload fields. Nothing is redundant or padded.

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?

For a zero-argument read tool whose annotations already cover the safety profile, the description supplies the essential missing piece — the shape of the return value. Only marginal details (ordering, cross-window scope, whether hidden tabs appear) are absent.

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 there is nothing for the description to disambiguate beyond the empty schema. Baseline 4 applies.

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?

The description names the resource precisely ('the open tabs') and enumerates the fields returned (ids, titles, URLs) plus the selected-state marker, so an agent knows exactly what it gets back. It stops short of explicitly contrasting with siblings like tab_select or tab_close, so it lands at 4 rather than 5.

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

Usage Guidelines3/5

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

There is no explicit when-to-use statement or named alternative. Usage is only implied: the returned ids are obviously the inputs that tab_close/tab_select need, but the description never says so, nor does it exclude any situation.

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