Skip to main content
Glama
Sign In
sessionmem

sessionmem

by catfish-1234
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ingestSessionEvents

Idempotent

Push raw session events to sessionmem for session-end summarization and token-savings analytics; duplicate re-ingestion is ignored, making retries safe.

Instructions

Push raw session events (tool calls, decisions, file edits, user turns) to sessionmem so they can be summarized at session end and counted toward token-savings analytics. Writes immediately, in a single transaction. Re-ingesting the same (sessionId, eventIndex) is a no-op, so retries are safe.

WHEN TO CALL: Periodically during a session (e.g. at task boundaries) to record what happened, OR in one batch shortly before the session ends. This is what powers automatic session-end summarization and sessionmem savings.

WHEN NOT TO CALL: For durable, individually-important facts/decisions — use storeMemory for those. Session events are transient raw material for summarization, not first-class memories.

Each event needs: id (unique), eventIndex (monotonic 0-based order within the session), eventType (e.g. 'tool_use', 'user_message'), payloadJson (a JSON string of the event body).

LIMITS: at most 500 events per call. For more than 500 events, call this tool multiple times in chunks — re-ingestion of already-stored events is safe (idempotent via the (project, session, eventIndex) UNIQUE index), so overlapping chunks never double-count.

Input Schema

NameRequiredDescriptionDefault
scopeNo
eventsYes
sessionIdYes
replaceExistingNo
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. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / events / items / required
      Previous value: -[
-  "id",
-  "eventIndex",
-  "eventType",
-  "payloadJson"
-]New value: +[
+  "id",
+  "eventType",
+  "payloadJson"
+]
    • addedInput schema / properties / replaceExisting
      Added value: +{
+  "type": "boolean"
+}
  3. Addedv1.1.2

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing immediate single-transaction writes, idempotency keyed on the (project, session, eventIndex) UNIQUE index, and the 500-event cap. It is consistent with idempotentHint=true, but never mentions the replaceExisting parameter, which could change the no-op-on-reingest behavior an agent relies on.

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?

Front-loads what the tool does, then organizes when-to/when-not/limits into scannable blocks. Every sentence carries actionable information; nothing is filler.

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?

With no output schema and no annotations covering safety beyond idempotency, the description covers transactionality, idempotent retry semantics, and batch limits thoroughly. The one material gap is the undocumented replaceExisting flag and scope, which affect how an agent should shape repeat calls.

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%, so the description carries the documentation burden; it does explain the nested event fields (id, eventIndex, eventType, payloadJson) but omits createdAt, scope, workingDirectory and especially replaceExisting, whose effect on the idempotency guarantee is unstated. Useful but incomplete compensation.

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 ('Push raw session events ... to sessionmem') plus the downstream purpose (session-end summarization, token-savings analytics). It explicitly distinguishes itself from storeMemory, so an agent can tell ingestion of transient events from storing first-class memories without opening either 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?

Provides explicit WHEN TO CALL (periodically at task boundaries, or one batch before session end) and WHEN NOT TO CALL, naming storeMemory as the alternative for durable facts. It also gives operational guidance for oversized batches (chunk at 500, overlapping is safe).

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