Skip to main content
Glama

End a session

end_session
DestructiveIdempotent

Closes a session by stopping headless turns and disconnecting live windows from Duet while leaving those windows open on the Mac.

Instructions

Close a session. A headless session stops taking turns; a live window disconnects from Duet but stays open on the Mac.

Input Schema

NameRequiredDescriptionDefault
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description adds genuinely useful context beyond that by distinguishing the two termination modes — a headless session stops taking turns, while a live window merely disconnects and stays open on the Mac. It stops short of saying whether an ended session can be resumed or what happens to in-flight work.

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 short sentences, the action front-loaded and the behavioral distinction second; nothing is wasted or restated.

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 one-parameter mutation with no output schema and annotations covering safety and idempotency, the description supplies the key behavioral consequence for each session type. Only the origin of session_id and post-close state are left implicit.

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?

The single session_id parameter has 0% schema description coverage and the description never explains its format or that it comes from start_session/list_sessions. The name is largely self-evident, but with low coverage the description should compensate and does not.

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 specific verb and resource ('Close a session') and immediately splits the outcome by session type, so an agent learns this is the counterpart to start_session in the sibling set. It does not explicitly name start_session or cancel_job as the inverse/alternative, which keeps it just under 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 Guidelines3/5

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

Usage is only implied: the description makes clear this is how you terminate a session, but it never says when to prefer it over cancel_job for a running job, nor what preconditions exist (e.g., must the session be idle).

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