Skip to main content
Glama

browser_claim_tab

Exclusively claim a tab from the latest discovery to control an open browser tab, with optional exact URL or title validation before claiming.

Instructions

Exclusively claim a tab_id from this connection's latest tab discovery; optional expected_url/title must match exactly.

Input Schema

NameRequiredDescriptionDefault
tab_idYes
browser_idYes
expected_urlNo
expected_titleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.24.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose two real traits — that claiming is exclusive (implying a lock/ownership state change) and that expected_url/expected_title must match exactly. It omits what happens on mismatch (error vs. no-op), whether another connection's claim blocks this one, and whether the claim is released.

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

Conciseness4/5

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

A single densely packed sentence with the core constraint (latest discovery) and the validation rule front-loaded. No filler, though 'Exclusively claim' is compact to the point of ambiguity.

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

Completeness2/5

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

For a 4-parameter mutation-ish tool with no annotations, no output schema, and no schema descriptions, the definition is thin. It leaves unaddressed what the claim returns, what error a mismatched URL yields, and how browser_id relates to 'this connection'.

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

Parameters3/5

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

Schema coverage is 0% across four parameters, so the description must compensate: it explains tab_id's origin and that expected_url/expected_title are exact-match guards. browser_id is required yet never explained, and no format or value examples are given for any parameter.

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 ('claim') on a specific resource ('tab_id') and pins the source to 'this connection's latest tab discovery', which separates it from browser_discover (finds tabs) and browser_open_tab (creates one). The word 'exclusively' hints at an ownership/locking semantic that is not quite nailed down.

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 'from this connection's latest tab discovery' implies a prerequisite call to browser_discover before this tool can be used, which is useful routing. It never states when not to use it or contrasts it with browser_open_tab / browser_tab_control, and no failure preconditions are given.

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