Skip to main content
Glama

tabs_ungroup

Remove specified tabs from a Firefox tab group without activating them or focusing windows; the group is deleted automatically when its last tab leaves.

Instructions

Remove tabs from their tab group

Never activates a tab or focuses a window. Requires Firefox 138+. Firefox deletes a group once its last tab leaves it.

profile_id is required: obtain it from profiles_list. All object IDs are local to that profile; never reuse them in another profile.

Input Schema

NameRequiredDescriptionDefault
tab_idsYesTab ID, or several as a list (`[12, 15]`) or a JSON string (`"[12, 15]"`).
profile_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it declares the no-side-effect guarantee ('Never activates a tab or focuses a window'), the cascade consequence ('Firefox deletes a group once its last tab leaves it'), a version requirement, and a cross-profile ID scoping warning.

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?

Four short sentences, front-loaded with the action and the most surprising consequence, then the safety guarantee, version, and profile sourcing. No filler; every sentence conveys something an agent would otherwise have to guess.

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

Completeness5/5

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

Output schema exists, so return values need no explanation. For a small two-parameter mutation the description covers the side-effect profile, the group-deletion consequence, the version gate, and the ID scoping rule — nothing material is missing.

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?

Schema coverage is 50%: tab_ids is documented in the schema, but profile_id has no schema description and the description compensates by declaring it required, naming where to obtain it, and warning that object IDs are profile-local. It cannot add much to tab_ids since the schema already covers the accepted formats.

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 ('Remove tabs from their tab group') with unambiguous scope. It is clearly distinct from tabs_group (the inverse), tabs_close (closes tabs), and tabs_groups_update, so an agent can select it without opening the schema.

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?

Provides useful prerequisites ('Requires Firefox 138+', 'obtain profile_id from profiles_list'), but never states when to use this rather than tabs_close or tabs_groups_update, nor any when-not conditions. Usage is inferable from the purpose but not explicitly routed.

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