Chrome Browser Control

by vKongv

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Release claimed tab

release_tab

Release a previously claimed tab by its ID, making it available for other tasks while keeping the browser tab open.

Instructions

Release a previously claimed tab by sessionTabId or tabId without closing the browser tab.

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

Input Schema

Name	Required	Description	Default
`tabId`	No
`sessionTabId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Sep 10, 2026

TDQS

A3.7/5.0

Behavior2/5

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

Without any annotations, the description carries full responsibility for disclosing behavior. It mentions that the tab is not closed, which is a useful side-effect, but it does not explain what 'release' does to the claim state, whether the operation is idempotent, or any other implications. This is a minimal disclosure given the absence of structured behavioral hints.

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?

The description is a single, front-loaded sentence with no waste. It states the action, the resource, the identifiers, and the key behavioral qualifier, all efficiently without redundancy.

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

Completeness3/5

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

For a tool with no annotations and no output schema, the description is bare-bones. It covers the main action and identifier options, but omits preconditions, detailed side effects, and error behavior. While the tool is simple, an agent might need more detail to act safely and correctly.

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?

With 0% schema description coverage, the description adds meaning by stating that the tab can be identified by sessionTabId or tabId, clarifying that these are alternative selectors. It does not explain each parameter's exact role or priority, but it provides more than the schema alone.

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 uses a specific verb-resource pair, 'Release a previously claimed tab', distinguishing it from claim_tab and other tab management tools. It also specifies the identifiers used (sessionTabId or tabId) and the critical side-effect constraint that the browser tab is not closed, clearly conveying the tool's function.

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?

The phrase 'previously claimed tab' implies the tool is used after a tab has been claimed via claim_tab, but it does not explicitly state this condition or compare with alternatives. No explicit when-not-to-use or alternative routing is provided, leaving usage to inference.

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