Skip to main content
Glama

WhiteMagic — governed local memory for agent continuity

by io.github.lbailey94
OverviewDiscussionsAdmin

Recall session continuity

session.continuity
Read-onlyIdempotent

Recall where the previous session left off: recent turns, checkpoints, and open work.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoNumber of prior turns (default 10)
sinceNoTime-range floor: epoch seconds, RFC 3339, or YYYY-MM-DD
untilNoTime-range ceiling: epoch seconds, RFC 3339, or YYYY-MM-DD
max_content_bytesNoPer-turn content cap in bytes (256-262144, default 8192)
current_session_idNoSession to exclude (optional)
max_response_bytesNoTurns budget in bytes (256-262144, default 49152)
include_briefing_textNoInclude the ready-to-inject briefing.text block (default false; adds bytes outside the turns budget)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoTurns returned
turnsNoTurns (memory_id, role, turn_type, sequence, content, content_bytes, content_truncated, importance)
statusNoOperation status
truncatedNoWhether the response hit its byte budget
checkpointNoLatest checkpoint handoff, or null
checkpoint_idNoMemory UUID of the checkpoint, or null
turns_omittedNoTurns dropped by the response budget
previous_sessionNoSession the turns were read from
max_content_bytesNoPer-turn byte cap applied
max_response_bytesNoTotal response byte budget applied

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_briefing_text
      Added value: +{
+  "description": "Include the ready-to-inject briefing.text block (default false; adds bytes outside the turns budget)",
+  "type": "boolean"
+}
  2. Changed2 schema fields changed
    • changedOutput schema / description
      Previous value: -"Result envelope for this tool; fields vary by operation."New value: +"Recent turns plus the latest checkpoint handoff for the prior session."
    • addedOutput schema / properties
      Added value: +{
+  "checkpoint": {
+    "description": "Latest checkpoint handoff, or null",
+    "type": [
+      "object",
+      "null"
+    ]
+  },
+  "checkpoint_id": {
+    "description": "Memory UUID of the checkpoint, or null",
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "count": {
+    "description": "Turns returned",
+    "type": "integer"
+  },
+  "max_content_bytes": {
+    "description": "Per-turn byte cap applied",
+    "type": "integer"
+  },
+  "max_response_bytes": {
+    "description": "Total response byte budget applied",
+    "type": "integer"
+  },
+  "previous_session": {
+    "description": "Session the turns were read from",
+    "type": "string"
+  },
+  "status": {
+    "description": "Operation status",
+    "type": "string"
+  },
+  "truncated": {
+    "description": "Whether the response hit its byte budget",
+    "type": "boolean"
+  },
+  "turns": {
+    "description": "Turns (memory_id, role, turn_type, sequence, content, content_bytes, content_truncated, importance)",
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "turns_omitted": {
+    "description": "Turns dropped by the response budget",
+    "type": "integer"
+  }
+}
  3. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the conceptual shape of the result (turns, checkpoints, open work) but says nothing about default behaviour such as excluding the current session, truncation/budget behaviour, or what a checkpoint contains; an output schema exists, which lowers but does not remove that burden.

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?

A single front-loaded sentence with zero filler; the payoff (recent turns, checkpoints, open work) comes immediately after the verb. Nothing is repeated from the schema or annotations.

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 read-only recall tool with a full output schema and 100% parameter coverage, the description supplies the essential framing. It stops short of situational guidance (when resuming vs. when doing a targeted memory.search) which would be the remaining useful addition.

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 100%, so all seven parameters (n, since, until, byte caps, current_session_id, briefing flag) are fully documented in the schema. The description adds no format, default or interaction detail beyond that, so the baseline 3 applies.

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 (recall) and resource (where the previous session left off), and enumerates the returned content: recent turns, checkpoints, open work. It never distinguishes itself from near-neighbours like session.recall, session.replay or session.list, so an agent cannot route between them from the description alone.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no conditions, and no named alternative. The intended occasion (resuming after a break) is only inferable from the phrase 'where the previous session left off', and the presence of session.recall/session.replay in the sibling set makes the choice genuinely ambiguous.

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

All WhiteMagic — governed local memory for agent continuity toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources