Skip to main content
Glama
Sign In
sessionmem

sessionmem

by catfish-1234
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

handleSessionEnd

Idempotent

Finalizes a session by summarizing ingested events into durable memory and pruning stale entries at session end; call once after ingesting events.

Instructions

Run the full session-end pipeline: auto-summarize the session's ingested events into a durable memory (when enough events exist) and apply a light retention prune of stale memories. Idempotent on the summary memory (upsert by sessionId).

WHEN TO CALL: Once, at the very end of a session, after ingesting session events via ingestSessionEvents. Lets sessionmem generate and store the session summary for you.

WHEN NOT TO CALL: Mid-session, or when you have already written your own summary (use summarizeSessionToMemory instead). On Claude Code this also runs automatically via the installed SessionEnd hook, so calling it explicitly is usually unnecessary there.

Provide sessionId and sourceAdapter. memoryId (optional) pins the summary's id; omit to derive ${sessionId}-summary. config (optional) tunes autoSummarize / minimumEventThreshold / cloud summarization; omit for sensible local-only defaults.

RESPONSE status is one of: 'stored', 'skipped_threshold' (too few events), 'skipped_disabled', 'failed'. warningCodes may carry cloud/local fallback signals.

Input Schema

NameRequiredDescriptionDefault
scopeNo
configNo
memoryIdNo
sessionIdYes
sourceAdapterYes
workingDirectoryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.10.0
    • addedInput schema / properties / scope
      Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 160,
+      "minLength": 1,
+      "pattern": "^[^\\x00-\\x1f\\x7f]+$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedInput schema / properties / workingDirectory
      Added value: +{
+  "maxLength": 4096,
+  "minLength": 1,
+  "type": "string"
+}
  2. Addedv1.1.2

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare idempotentHint and destructiveHint=false, but the description adds real value beyond them: the idempotency mechanism (upsert by sessionId), the existence of a retention prune of stale memories, threshold-gated summarization, and the four possible status outcomes plus warningCodes for cloud/local fallback. It does not detail what the prune actually removes or what permissions/keys cloud summarization requires.

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?

Well front-loaded: one-sentence pipeline summary, then labeled WHEN TO CALL / WHEN NOT / parameter notes / response codes. Slightly padded by the repeated 'omit for sensible defaults' phrasing and some incidental detail, but nothing is genuinely wasted.

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?

No output schema, yet the description enumerates the status values and warningCodes, which is the main return-value need. The remaining gap is undocumented optional params (scope, workingDirectory, several config keys) that an agent could mis-set silently.

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 0% across 6 params including a nested config object, so the description must compensate. It explains sessionId, sourceAdapter, memoryId's default derivation, and three config fields — helpful — but leaves scope, workingDirectory, factMode, summaryTokenCap, redactionEnabled, and anthropicApiKey entirely undocumented.

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 composite action (summarize ingested events into durable memory plus a light retention prune) and names the exact alternative (summarizeSessionToMemory) it differs from. An agent can distinguish it from siblings like ingestSessionEvents or storeMemory without opening any schema.

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?

Explicit WHEN TO CALL (once, at the very end, after ingestSessionEvents) and WHEN NOT TO CALL (mid-session, or when a summary already exists — use summarizeSessionToMemory instead). It even notes the Claude Code SessionEnd hook makes explicit invocation usually unnecessary, which is exactly the routing info an agent needs.

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