Skip to main content
Glama
Sign In
WeftCut

WeftCut

by WeftCut
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

end_agent_session

End the current work session to release its history lock while keeping the view, activity, running tasks, and connection open. If the composition audit is stale, resolve findings before retrying.

Instructions

End your work session and release its history lock; the view, activity, running tasks and connection stay. Only the owning connection may end it (begin_agent_session { force: true } takes over a stale one). Unless your last check_composition is current, the app audits first; hard or warning findings keep the session open (ended: false, held: "audit"): settle them and end again. Answers { ended, audit } (ended: the closed session, null with none), plus tacks_to_review when open tacks are outdated. Unrecorded.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • removedInput schema / properties / force
      Removed value: -{
-  "description": "End another connection's session too. Default false.",
-  "type": "boolean"
-}
  2. Changed1 schema field changedv0.1.9
    • addedInput schema / properties / force
      Added value: +{
+  "description": "End another connection's session too. Default false.",
+  "type": "boolean"
+}
  3. First observedv0.1.8

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only say openWorldHint=false and destructiveHint=false; the description goes well beyond by disclosing the ownership rule, the audit gate, and exactly what is retained versus released. The failure mode is given concretely (`ended: false, held: "audit"`). Minor gap: 'Unrecorded' is asserted without clarifying which history/undo log it refers to.

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?

Front-loaded with the primary effect, then preconditions, failure semantics, and return shape in a logical order with no filler sentences. It is densely packed with shorthand ('Unrecorded.', `tacks_to_review`) that assumes domain familiarity and slightly compresses readability.

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?

There is no output schema, but the description hand-specifies the response (`{ ended, audit }`, null `ended`, optional `tacks_to_review`). Combined with the ownership and audit-gate behavior, an agent has everything needed to call and interpret this correctly.

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?

The tool takes zero parameters, so the schema baseline is 4 and there is nothing parameter-specific for the description to add. It does correctly avoid inventing inputs, though the caller has no handle to force or skip the audit here.

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 (end the agent session) plus the precise effect: releases the history lock while the view, activity, running tasks and connection persist. It is immediately distinguishable from the sibling begin_agent_session, which is named as the takeover alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says who may call it (only the owning connection) and names the alternative for the stale case (`begin_agent_session { force: true }`). It also states the precondition (a current `check_composition`) and what to do when the call is refused (settle findings and end again).

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