Skip to main content
Glama

scout_close

Close a browser session to free live resources while preserving disk memory; target the default, a named session, or all sessions, with lane reports protected until accepted.

Instructions

Close a session's browser (memory persists on disk). Default: the DEFAULT session. Pass session to close a specific one, or all=true to close every live session at the end of a multi-role run. A session that is a lane of a parallel run (named by scout_lane_brief or scout_lane_report) is not closed until its lane report has been accepted by scout_lane_report, since folding needs the session attached; the refusal names every such lane.

Input Schema

NameRequiredDescriptionDefault
allNoClose every live session
forceNoClose even a lane whose report has not been folded yet. Its decisions are then lost: nothing is kept for calibration and nothing checks its defects were filed. Prefer folding it with scout_lane_report first.
sessionNoSession to close (default: the default session)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed1 schema field changedv3.10.0
    • addedInput schema / properties / force
      Added value: +{
      +  "default": false,
      +  "description": "Close even a lane whose report has not been folded yet. Its decisions are then lost: nothing is kept for calibration and nothing checks its defects were filed. Prefer folding it with scout_lane_report first.",
      +  "type": "boolean"
      +}
  3. Addedv1.1.0

TDQS

A4/5.0
Behavior4/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 well: it discloses that memory persists on disk, that the default target is the default session, that lane sessions are held open until their report is accepted, and that refusals enumerate blocked lanes. It omits the destructive consequence of `force` (though the schema covers it), which is the main behavioral gap.

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?

The description is front-loaded with the core action, then proceeds through the default, the explicit parameters, and the lane constraint. Every sentence earns its place, including the longer lane caveat that prevents a real misuse.

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 3-parameter close tool with no output schema, the description covers purpose, default behavior, bulk closing, and the critical lane-report dependency. It is largely complete, though it could mention `force` and what happens to a session after closure (e.g., whether it can be reopened) to be fully self-contained.

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 the schema already documents all three parameters thoroughly, including the risky `force` behavior. The description largely restates the default and `all` semantics and adds only modest context (end-of-multi-role-run usage), so it does not add much beyond the structured schema.

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: 'Close a session's browser', with the important qualifier that memory persists on disk. It is immediately clear what the tool does, though it does not explicitly contrast itself with sibling tools such as scout_session that likely create or switch sessions.

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?

It gives clear routing: default closes the default session, `session` targets a specific one, and `all=true` is for the end of a multi-role run. It also states a when-not condition for lanes pending report folding, but never mentions the `force` escape hatch, so the agent reading only the description lacks the full set of options.

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