Skip to main content
Glama

Dock release

dock_release
Destructive

Release a browser tab back to the user: close agent-opened tabs by default, or keep them open with close=false; user-shared tabs are only removed from the agent group, never closed.

Instructions

Hand a tab back when you are done. Tabs you opened are closed (close=false keeps them for the user); tabs the user shared are only removed from the agents group, never closed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
closeNoClose the Dock session after releasing the tab (default: keep it open)
tab_idYesTab id from dock_tabs or dock_open.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds real value beyond that: it tells the agent exactly what gets destroyed (tabs you opened are closed) versus what is merely detached (user-shared tabs removed only from the agents group, never closed) and notes the close=false opt-out. This is meaningful ownership-dependent behavior not derivable from annotations.

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, zero waste, front-loaded with the action and its ownership-dependent consequences. Every clause carries distinct information.

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 destructive, 2-param tool with no output schema, the description covers the key decision points: when to release, what happens to opened vs shared tabs, and the close opt-out. Nothing critical is missing, though the return/protocol outcome is left unstated.

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 100%, so the baseline is 3 and the schema carries both parameters. The description still adds nuance by spelling out the effect of close=false in the ownership context, which clarifies the counterintuitive default (schema lists default true while its own text says 'keep it open').

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 concrete verb+resource (hand a tab back / release) and immediately qualifies behavior by ownership, which distinguishes it from dock_open and dock_tabs. It does not name a sibling explicitly, but an agent can infer the release role.

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?

"Hand a tab back when you are done" gives a clear trigger condition for using the tool. It doesn't name an alternative tool or state when NOT to use it, so it falls short of the explicit-alternatives bar.

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