Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ZENBRAIN_DBNoPath to the SQLite file that holds the memory. A leading ~/ means your home directory; a relative path depends on where the client starts the server (some start it in /), so give an absolute or ~/ path. Use ':memory:' for a store that is discarded when the process exits../zenbrain.db
ZENBRAIN_CONTEXTSNoComma-separated context domains, passed to the cross-context layer. No tool uses that layer yet, so the value currently has no effect.personal,work,learning,creative

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
zenbrain_storeA

Write something into long-term memory so it survives this conversation. Routing is automatic by default, first match wins: steps, or wording such as "How to", "Steps:" or "workflow:", make a procedure; an emotional weight above 0.5 (detected, or set via emotionalWeight) an episode; a confidence above 0.9 a pinned core memory; anything else a semantic fact. Set type only when you want to override that. Every call adds a new memory, except that storing the same core memory again updates it; the content is also kept in working memory (the most recent seven) while the server runs, so once seven are held each store replaces the oldest copy there. Long-term memory is never changed by a store. Returns the id of the stored memory. If it may already be stored, check with zenbrain_recall first: storing it again adds a duplicate.

zenbrain_recallA

Search long-term memory for anything relevant to a query. By default it searches the episodic, semantic, procedural and core layers; working memory (the most recent stores, held only while the server runs, up to five results) is searched only when named in layers. Returns results sorted by score, each with its id and the layer it came from; zenbrain_forget takes both. The score runs from 0 to 1 and says how well a result matches the query; a layer in which nothing matches returns recent memories (or its most successful procedures) at 0, behind every hit, and minScore above 0 leaves them out. Every core block scores 0.5 or 0.8, so a block can rank above a weak hit. Use this before answering when the user refers to something from an earlier session. To see how much is stored rather than what, use zenbrain_health; to save something, use zenbrain_store.

zenbrain_forgetA

Permanently delete a memory, addressed by the id and layer that zenbrain_recall returned for it, together with what consolidation linked to it; this cannot be undone. Forgetting an episode also deletes the fact zenbrain_consolidate made from it; forgetting such a fact also deletes every episode consolidated into it; both also delete the working-memory copies of that content. Forgetting a working-memory result deletes only that copy. alsoForgotten lists everything deleted besides the memory itself. A memory stored on its own and never consolidated keeps its long-term entry. Use it when the user asks to forget something or a stored memory is wrong; to correct a memory, forget it and store the corrected version with zenbrain_store. An id the layer does not hold is reported as not forgotten, not as an error.

zenbrain_consolidateA

Run one consolidation pass: among the 100 most recent episodes, each one with an emotional weight above 0.5 becomes a semantic fact — once, however often the pass runs. Working-memory slots lose relevance with age, and slots whose relevance has dropped to 0.01 or below are removed; that is the only deletion, and nothing in long-term memory is deleted. Run it between sessions or after a batch of zenbrain_store calls, not on every turn; compare zenbrain_health before and after to see the effect.

zenbrain_healthA

Report how full the memory layers are: working-memory slots in use, interactions held, episodes, facts and how many are due for review, procedures, core blocks. Read-only and cheap, safe to call at any time. It returns counts only; to read the memories themselves, use zenbrain_recall.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool owns a clearly distinct verb-resource: store (write), recall (read), forget (delete), consolidate (maintenance pass), and health (read-only stats). The descriptions actively disambiguate by cross-referencing each other (e.g. 'to save, use zenbrain_store; to see how much is stored, use zenbrain_health'). No two tools could reasonably be confused.

Naming Consistency5/5

All five tools follow a uniform zenbrain_<operation> snake_case pattern with single, predictable operation tokens. The convention holds throughout, with no mixing of styles or verb forms.

Tool Count5/5

Five tools is well-scoped for a memory server, with each tool earning its place across a full lifecycle (write, read, delete, consolidate, monitor). Nothing is redundant or missing a corresponding slot.

Completeness4/5

The surface covers the full memory lifecycle: create (store), read (recall), delete (forget), maintenance (consolidate), and observability (health). Direct update/edit is absent, though it is explicitly documented as a forget-then-store workaround, so it's a minor gap rather than a dead end.

Maintenance

ActivityActive
ResponsivenessSlow