Skip to main content
Glama

Close a browser session

browser_close
Destructive

Use for: ending a session and freeing its browser. Sessions also expire automatically after 10 idle minutes. Free on every door — closing is never charged.

Input Schema

NameRequiredDescriptionDefault
session_idYesSession ID. Reuse the same ID to keep cookies, login state and page position across calls; a new ID starts a fresh browser.

Output Schema

NameRequiredDescriptionDefault
closedYes
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

The description adds genuinely non-annotation information: idle auto-expiry and that closing is never billed ('Free on every door — closing is never charged'). However, it omits the key destructive consequence — that closing discards cookies, login state and page position, which the session_id schema hints at but the description never states. With destructiveHint=true already flagged, this is a partial but not complete disclosure.

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?

Three short sentences, front-loaded with 'Use for:', and every sentence carries information (purpose, idle expiry, cost). The phrasing 'Free on every door' is slightly idiosyncratic but still parses as a cost statement.

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?

An output schema exists, so return values need no explanation, and annotations already declare destructiveness and non-read-only behavior. Combined with clear purpose, idle-expiry and billing notes, the description is sufficient to call the tool correctly; only the state-loss implication is left implicit.

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 100% and there is only one parameter, whose schema description already explains ID reuse and state persistence. The tool description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

The description states a specific verb and resource: 'ending a session and freeing its browser.' That is unambiguous and clearly distinct from the navigation/extraction siblings. It doesn't explicitly name a sibling to contrast with, which keeps it just short of a 5.

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?

'Use for: ending a session' gives the triggering condition directly, and the note that sessions expire automatically after 10 idle minutes helps an agent decide whether an explicit close is even necessary. There are no explicit 'when not to use' exclusions, but the primary guidance is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources