Skip to main content
Glama

memory_session_finish

End an open session, optionally saving a distilled handoff of outcomes and next actions to guide future sessions.

Instructions

Close an open session bracket (exactly once) with an optional summary — and an OPTIONAL handoff: the distilled close (what became true / what is open / the next physical action). A present handoff is captured as a NORMAL capsule through the audited ingest path BEFORE the bracket closes — provenance source "memory_session_finish", anchor = the session id, linked to the bracket; project-fence defaults, taint scan, and idempotent dedup all apply — and memory_digest then LEADS with the newest handoff per project (its handoff section), so the next cold session reads the close first. The response names the capsule (handoff_capsule; handoff_deduped: true when the content collapsed onto an existing capsule). A value-rejected handoff (e.g. empty content) fails the WHOLE call with -32602 naming the param — fail closed: nothing captured, the session stays open. A closed bracket accepts no further captures. Both state faults are typed resource-state errors, one family (-32002 + data {kind, id}): an unknown id → {kind: "unknown_session", id}; finishing an already-finished bracket → {kind: "finished_session", id} (never a discriminator-less invalid-params) — a handoff never leaks a capture past either. Audited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handoffNoR6: optional distilled handoff — what became true, what is open, the next physical action. When present it is captured as a NORMAL capsule through the audited ingest path BEFORE the bracket closes (provenance source [`HANDOFF_SOURCE`], anchor = this session id, linked to the bracket; fences, taint scan, and dedup all apply), and `memory_digest` then leads with the newest handoff per project. When absent, finish behaves exactly as before.
summaryNoOptional close-time summary, recorded on the session row.
session_idYesThe open session to close (`sess-<n>`).
Behavior5/5

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

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: handoff capture before closure, dedup, taint scan, response fields, error types with structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very long and dense, with many technical details included in a single paragraph. It could be broken into more digestible sentences or bullet points.

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?

Despite no output schema, the description thoroughly explains return values (handoff_capsule, handoff_deduped) and error types with structured data. It covers all necessary behavioral aspects for correct invocation.

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?

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining that handoff is distilled and goes through audit/dedup, and that summary is optional. This goes well beyond the schema descriptions.

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 clearly states the tool closes an open session bracket with optional summary and handoff. It uses specific verbs ('Close', 'captured', 'finish') and distinguishes from siblings like memory_session_start by focusing on closing behavior.

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 explains when to use (to close a session with optional handoff) and when not to (unknown or already finished sessions). It does not explicitly compare to alternatives, but the context of sibling tools implies this is the only close tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menot-you/n-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server