Skip to main content
Glama

Clone a tab

browser_duplicate_tab

Duplicate a Firefox tab while preserving its history and state, opening the clone next to the original so agents can continue from the same page without losing context.

Instructions

Duplicate a tab, keeping its history and state (Firefox tab cloning, gBrowser.duplicateTab). The clone opens next to the original. Duplicating is the cheapest way to keep "where I was" while the agent continues in the new copy — close the extra tab when you are done.

Input Schema

NameRequiredDescriptionDefault
contextNoTab context id to clone (default: the active tab)
backgroundNoOpen the clone in the background (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

readOnlyHint=false is consistent with a tool that creates a tab, and the description adds real context the annotation cannot: the clone inherits history and state and is inserted adjacent to the source tab. It also warns about leaving stray tabs open. It stops short of saying whether the source tab or the clone becomes active, which is the main behavioral unknown for an agent.

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?

Two sentences, front-loaded with what the tool does, with the key behavioral property (history/state retained) before the operational advice. The gBrowser.duplicateTab reference earns its place by disambiguating against a plain new tab.

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?

No output schema, and the description never says what the call returns — most importantly whether the new tab's context id is handed back so the agent can act in the clone, which its own advice ('continue in the new copy') depends on. It also leaves focus/activation behavior unstated.

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 description coverage is 100%, so both parameters (context, background) are already documented in structured form; baseline 3 applies. The description implies default targeting ('the active tab') and background opening only indirectly, adding little beyond the schema.

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?

States a specific verb and resource ('Duplicate a tab') plus the defining property that separates it from browser_new_tab: it keeps history and state. The parenthetical naming gBrowser.duplicateTab anchors the exact semantics, and 'opens next to the original' pins the placement behavior.

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

Usage Guidelines4/5

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

Gives a clear use case ('cheapest way to keep where I was while the agent continues in the new copy') and a follow-up instruction to close the extra tab when done. It does not explicitly name browser_new_tab as the alternative for a fresh tab, so the exclusion is implied rather than stated.

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