Skip to main content
Glama

memory_digest

Summarize the memory store's current state for session start: capsule counts by project, newest and most-recalled headlines, active handoffs, open sessions, and relation/dag status.

Instructions

Compact store projection sized for session-start injection: total capsule count, counts by project, a handoff section LEADING the headline lists — discovered by TWO markers: bracket handoffs (rows whose provenance source is "memory_session_finish", i.e. captured by memory_session_finish's handoff; ONE row per project, a superseded row stays visible flagged) and thread handoffs (rows whose content opens with the exact convention ACTIVE(): — closing paren required — captured via plain memory_ingest; ONE row per project+thread so concurrent threads stay visible, and a superseded thread row is RETIRED: supersede a thread's newest handoff to close the thread out of the lead — a guarantee that assumes each thread capture supersedes its prior (an older LIVE unchained row of the same thread resurfaces instead)); newest-first, house headline rows, capped at N; ABSENT when the scope holds none — additive, a reader that never hands off sees the digest unchanged, the newest N headlines with ids, and the N most-recalled headlines — each carrying the recall_count and last_recalled_at (RFC3339) that ordered it, sorted recall_count desc, then LAST-RECALL recency (not creation recency), then append order; capsules never returned by memory_retrieve do not appear. EVERY capped list declares its own completeness: handoff_total, newest_total and most_recalled_total are the EXACT pre-cap counts of their lists (the dag's ready/ready_total idiom), fenced exactly like the lists they sit beside and omitted at zero, so a truncated list is never mistaken for a complete one — list length < total means N cut it, raise headlines to see the rest. total and by_project's count count LIVE + SUPERSEDED capsules and EXCLUDE tombstoned (memory_export's own capsules= header line is the GRAND total including tombstoned and names its full breakdown live/superseded/tombstoned — digest total = that breakdown's live + superseded); each by_project row ALSO carries live — that row's capsules minus the superseded ones, the still-standing subset — so a census whose history outweighs its present says so instead of reading as inventory. count keeps its export-parity meaning and NEVER narrows to live. These five capsule sections honor project_prefix (subtree fence: exact id or id + "/..."; an empty or "/"-terminated prefix can match nothing and is rejected with a teaching error rather than answering empty). Store-global sections (never fenced): relation/audit counters and open sessions — open_sessions is the EXACT open-bracket count and open_session_ids NAMES which sess- are open (oldest-open first, id list capped at N while the count stays exact — the dag's capped-list + exact-total idiom), so a zero-capture orphaned bracket is recoverable: read its id there, then close it with memory_session_finish; the blocks-dag projection dag {ready + ready_total, blocked + blocked_total, done + done_total (id lists capped at N, totals exact)} — blocks-edge participants only, superseded/tombstoned dead to it; a WITNESSED participant is DONE (u-r3: proof-carrying closure DERIVED from a witnesses edge — no state field — that leaves ready/blocked and stops gating dependents, yet stays recallable unlike superseded/tombstoned ids; ready itself IS "unblocked, awaiting proof"); fail-closed on a live blocks-cycle among non-done members (status "cycle" with ONE concrete cycle + entangled_total; repair — supersede, forget, OR witness a member — and re-digest to see the next); the mission section mission {status:"ok", roots: [{...headline, children}]} — the planning-plane u2 spine, a SEPARATE projection over the grounded_in sidecar (grounded_in is NOT a dag input): roots HONOR project_prefix, fenced exactly like the other capsule sections above — the cycle check and each root's children count are the ONLY store-global pieces of this section, never fenced: roots are live kind=epic capsules with no outgoing grounded_in edge that still ANCHORS them (the live-parent anchoring rule — an edge anchors its child ONLY while the edge's parent, its to_id, is live; a live epic whose every outgoing grounded_in edge names a dead, i.e. tombstoned or superseded, parent is a mission root again), newest-first, capped at N; each root's children counts grounded_in edges naming it as parent, STORE-WIDE (never fenced to the root's own project scope) but LIVE-only (a tombstoned or superseded child endpoint does not count); mission is ABSENT from the wire entirely — not merely an empty roots array — when the live grounded_in subgraph is acyclic and has zero roots (additive dormancy: a store that never grounds anything sees a byte-identical digest); fail-closed on a live grounded_in cycle, mirroring dag's own shape (status "cycle" with ONE concrete cycle + entangled_total, checked store-global; repair — supersede or forget a member — and re-digest; the REST of the digest, including dag, still serves while mission alone fails closed); unanchored, when present, is the fenced (project_prefix-honoring, like the mission roots) count of live in-scope PLANNING nodes — persisted classification kind task ONLY (never epic: an ungrounded epic surfaces as a mission root instead, so it is already visible there and never double-counted here), OR an ACTIVE() handoff-thread row — that carry no live-anchoring outgoing grounded_in edge (the SAME live-parent anchoring rule as mission: an edge anchors its child ONLY while its to_id parent is live); it is a fail-open advisory nudge, NEVER a gate, and is omitted at zero or when the read fails; tiers {active, archived, quarantined} effective-tier counts; journal {chain ok|broken, verified|broken_seq, out_of_band count} — the audit hash-chain + coverage verification; and archive_candidates — how many records the consolidation planner would propose archiving (advisory; memory_consolidate has the full plan); and recall_misses — total rows in the u-r5 recall-miss ledger (the folded query terms memory_retrieve recorded when FTS ran and its PRE-TRIM term-lane observation was missing_evidence or abstain; forced vector and limit/budget-only term trimming write none; memory_consolidate mines recorded misses into alias_proposals). recall_misses is additive telemetry read fail-open (a broken ledger reports 0, never fails the digest). recent_failures, when present, contains ONLY the newest five folded-term recall-miss rows in sequence order; each term uses the same bounded single-line headline projection as capsule rows. Because miss rows carry no project attribution, any digest with project_prefix omits recent_failures rather than leaking store-global query text. Absence means empty OR unavailable, never proof that no miss occurred. lane_overrides_total, when present, is the all-time store-global checked count of successful explicit lane choices that disagreed with auto routing; it is advisory routing telemetry, not evidence of failure or success, and is omitted at zero or read error. sources, when present, is the git-witness section — one entry per scanned repository (source_key git:, its last-scanned cursor sha and the instant it advanced, and the corroborated/drifted/missing/mentions tallies the git-scan verb recorded for that source); it is store-global (the cursor is per-repo, not per-project), advisory only, and omitted when no repository was ever scanned or the read fails. The three optional reads fail open independently. Per-node blocker detail lives on memory_get's relations list. N defaults to 10; full capsules via memory_get. All content is ADVISORY_NOT_AUTHORITY data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
headlinesNoThe digest's GLOBAL list cap N — one knob for EVERY capped id/row list (handoff, newest, most_recalled, open_session_ids, dag ready/blocked), not just the newest headlines; counts and totals stay exact and uncapped, so raising N reveals rows, never new truth. The `nmemory digest --headlines <n>` CLI flag is the same knob. Omitted → 10.
project_prefixNoScope-hierarchy fence over the CAPSULE sections (total / by_project / newest / most_recalled): keep capsules whose project_id equals this prefix exactly or starts with it + "/". Store-global sections (relations, dag, sessions, audit, tiers, journal, archive_candidates) are NOT fenced — they describe the whole store.
Behavior5/5

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

With no annotations, the description fully shoulders the transparency burden. It meticulously details behaviors: count semantics (live/superseded/tombstoned), cap mechanics, cycle detection (fail-closed/open), advisory nature, and error conditions. Every edge case is articulated.

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

Conciseness1/5

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

The description is an excessively long, unstructured wall of text. It lacks paragraphs or headings, making it arduous for an AI agent to parse. Every sentence is dense with detail, many of which are implementation internals rather than user-facing guidance.

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?

Despite its poor structure, the description covers every component of the digest (capsules, handoffs, dag, mission, etc.) thoroughly. With no output schema, this is necessary. However, the lack of organization hinders quick comprehension, earning a deduction from perfect completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial value: it clarifies that 'headlines' caps all id lists, not just headlines, and explains that 'project_prefix' only fences capsule sections, not global ones. This context is critical for correct parameter use.

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?

The description starts with 'Compact store projection sized for session-start injection,' giving a clear use case. It distinguishes from siblings like memory_get (for details) and memory_retrieve (for search). However, the core purpose is buried in a dense wall of text, reducing immediate clarity.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for session start but doesn't compare to siblings like memory_list or memory_get. The agent must infer usage from the tool's name and context.

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