Skip to main content
Glama
LCV-Ideas-Software

cross-review

by LCV-Ideas-Software
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Sweep Idle Sessions

session_sweep
DestructiveIdempotent

Finalize unfinished sessions idle for at least 24 hours, closing stalled cross-review workflows with a stated outcome and reason. Optionally prunes stale corrupt-session entries.

Instructions

Finalize unfinished sessions whose metadata has been idle for at least 24 hours. The terminal reason accepts at most 200 characters. v3.7.5 (B1): opt-in prune_corrupt also removes stale entries from the corrupt_sessions/ quarantine directory. Requires a verified capability token. Sweep is the one mutation that acts ACROSS owners, so the token is not the affected petitioner's — but a self-declared identity is refused, and it is therefore no way out of a token-file failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callerYes
reasonNostale
outcomeNoaborted
idle_minutesNo
prune_corruptNo
response_formatNojson
corrupt_min_age_daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.4.18
    • removedInput schema / properties / caller / default
      Removed value: -"operator"
    • changedInput schema / properties / caller / enum
      Previous value: -[
-  "codex",
-  "claude",
-  "gemini",
-  "deepseek",
-  "grok",
-  "perplexity",
-  "operator"
-]New value: +[
+  "codex",
+  "claude",
+  "gemini",
+  "deepseek",
+  "grok",
+  "perplexity"
+]
    • addedInput schema / required
      Added value: +[
+  "caller"
+]
  2. Addedv4.4.12
  3. Removedv4.4.11
  4. First observedv4.4.8

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint and idempotentHint, but the description adds significant behavioral detail: it removes stale quarantine entries only when prune_corrupt is opted in, requires a verified capability token, and clarifies that the token belongs to a different identity than the affected petitioner. This goes well beyond what the annotations convey.

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?

The description is dense but compact: three sentences front-load the core purpose and then add auth and version-specific behavior. The token-file warning is slightly elaborate but relevant to safe invocation, so no sentence is pure filler.

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?

The description covers purpose, auth requirements, and destructive scope, which are critical safety aspects. However, there is no output schema, yet the description does not mention return values or response_format behavior, and most parameters remain semantically unexplained. It is adequate for safety but incomplete for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only clarifies reason's 200-character limit and prune_corrupt's quarantine behavior. The other five parameters—caller, outcome, idle_minutes, response_format, and corrupt_min_age_days—are left undocumented, which is insufficient for a 7-parameter tool.

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?

The description states a specific verb and resource: 'Finalize unfinished sessions whose metadata has been idle for at least 24 hours.' It also distinguishes the tool from siblings by noting it is 'the one mutation that acts ACROSS owners,' which prevents confusion with per-owner session mutations.

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?

The description gives clear usage context: sweep is for idle unfinished sessions and is uniquely cross-owner, which helps an agent select it over owner-scoped alternatives. It also provides an exclusion by warning that a self-declared identity is refused and this is 'no way out of a token-file failure.' It does not explicitly name alternate tools, so it stops short of a 5.

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