Skip to main content
Glama
zensation-ai

ZenBrain

Official
by zensation-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

@misc{bering2026zenbrain,
  title         = {ZenBrain: A Neuroscience-Inspired 7-Layer Memory Architecture for Autonomous AI Systems},
  author        = {Bering, Alexander},
  year          = {2026},
  eprint        = {2604.23878},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  doi           = {10.5281/zenodo.19353663},
  url           = {https://arxiv.org/abs/2604.23878}
}

Feedback, replications, and counter-results are explicitly welcome — please open an issue or reach out via research@zensation.ai.

Your AI forgets everything after every conversation. ZenBrain fixes that — with the same mechanisms your brain uses: spaced repetition, emotional consolidation, Hebbian strengthening, and exponential forgetting curves. Not a vector database with a wrapper. Actual neuroscience.

Architecture vs. this package. ZenBrain's architecture is 15 neuroscience-inspired mechanisms — 9 foundational algorithms + 6 Predictive Memory Architecture (PMA) components (paper). The 6 PMA components are proprietary and run in the production system. This open-source package ships the algorithm library: 10 core algorithms + 10 advanced research modules (20 modules), zero-dependency.

Benchmark: LongMemEval-500

On LongMemEval-500, three of nine head-to-head answer-quality comparisons hold against Letta, Mem0 and A-Mem — all three against A-Mem, the remaining six are ties, none lost. Three competitors x three LLM judges, Bonferroni-corrected (alpha = 0.05/18) and version-matched. It reaches 91.3% of a full-context oracle's binary-judge accuracy at 1/109.6 of the per-query token cost (47.7% vs. 52.2%).

The paper prints where ZenBrain loses as well: on LoCoMo, substring-based aggregate F1 favours lexical retrieval (BM25) by metric design, and we do not contest that. The advantage is most pronounced on judge-graded answer quality and cross-session reasoning.

The mechanism comparison further down re-runs from this repository in under a minute — bash scripts/compare-mechanisms.sh, no API keys and nothing to install. It prints a positive and a negative control before the result, so the instrument can be checked before its output is trusted. The method, the effect sizes and the ablations behind the numbers above are in the paper; this repository ships no runner for them. The archived packages below run the significance tests and effect sizes in full, and the mechanism ablation behind paper Tables 7–9.

Related MCP server: brainlayer

Reproduction packages

The raw material behind the numbers above is deposited on Zenodo, open access and citable. Both links are concept DOIs and resolve to the latest version, the same convention this README uses for the paper archive; each description was measured against the version named after it.

  • Mechanism ablation, paper Tables 7–9 — 10.5281/zenodo.22162063 (described here: v1.0.0). Four experiment suites (95 tests), the reference JSON the paper's tables were generated from, and verify-against-reference.mjs, which diffs a fresh run against that reference and exits non-zero on drift. npm install && npm run experiments; the run itself needs no API keys and no network, and finishes in under a minute on a laptop. Two of the paper's other ablation tables need data this package does not carry: Table 11 the LoCoMo corpus, Table 13 a different pipeline. The package says so itself.

  • Measurement package, LongMemEval-500 and the real-pipeline flag ablation — 10.5281/zenodo.22161977 (described here: v1). Per-(system, judge, seed) judged outputs, the flag manifests as recorded at run time, a SHA256SUMS.txt covering every file in the package, and the analysis scripts. Three of those scripts are stdlib-only and self-checking — the oracle comparison behind the 91.3% figure, the judge-agreement figures, and the real-pipeline flag-ablation table: each prints every re-derived value next to the reference it has to match, and exits non-zero on mismatch. The significance tests behind the nine head-to-head comparisons against Letta, Mem0 and A-Mem sit in a separate script that needs numpy and scipy; it recomputes all eighteen pairwise tests and rewrites the deposited significance JSON byte-identically, so what catches a mismatch there is the checksum, not an exit code.

Both packages name what they do not cover. Replications and counter-results are welcome: research@zensation.ai.

How ZenBrain differs from Mem0, Letta and Zep

ZenBrain implements fifteen mechanisms taken from human memory research. No system among those surveyed in the paper integrates more than two of them. The table below records which of the mechanisms appear in the public source of three widely used memory systems, at pinned versions, on a fixed date.

Mechanism

ZenBrain

Mem0

Letta

Zep

FSRS spaced repetition

yes

—

—

—

Hebbian learning

yes

—

—

—

Ebbinghaus forgetting curves

yes

—

—

—

Sleep consolidation

yes

—

—

—

Emotional tagging

yes

—

—

—

Zero runtime dependencies

yes

—

—

—

How this was measured, 27 August 2026. Full-text search over the checked-out public source of mem0ai/mem0 (npm mem0ai 3.1.7, PyPI mem0ai 2.0.19), letta-ai/letta-code (npm @letta-ai/letta-code 0.31.2) and getzep/zep, lockfiles excluded. A dash means the term does not occur in that snapshot — not that the system cannot do something comparable under another name. Dependency counts are declared direct dependencies: @zensation/core resolves to two packages, both our own; mem0ai declares four, @letta-ai/letta-code eighteen. Re-run the whole check yourself with scripts/compare-mechanisms.sh; it prints its own positive and negative controls so you can see the instrument works before you trust the result.

Human memory does not work like a key-value store. The brain keeps specialised systems for different kinds of memory, forgets actively, modulates by emotion and retrieves by context. ZenBrain brings those mechanisms to AI agents.

Advanced algorithms (since v0.3.0, May 2026)

On top of the 10 core algorithms above, @zensation/algorithms ships 10 advanced algorithms grounded in recent neuroscience and ML research. Each is exposed as its own sub-path (@zensation/algorithms/<name>) and remains zero-dependency:

  • fsrs-vmPFC — Prediction-Error coupled FSRS

  • hebbian-two-factor — Two-Factor synaptic consolidation

  • sleep-simulation-selection — RL-based replay selection

  • spectral-health — Fiedler-value KG health monitor

  • ib-budget — Information-Bottleneck retention budget

  • dopamine-routing · hopfield-stm · personalized-pagerank · surprise-gradient-memory · temporal-multi-route

See CHANGELOG.md for details.

Quick Start

Requires Node.js 22 or newer (since 0.4.0). On Node 20 or older, npm silently installs the last compatible release (@zensation/algorithms@0.3.4, @zensation/core@0.2.2) instead of the current one — which looks like a broken package but is a platform mismatch. See CHANGELOG.

npm install @zensation/algorithms
import {
  initFromDecayClass,
  getRetrievability,
  updateAfterRecall,
  tagEmotion,
  computeEmotionalWeight,
  computeHebbianStrengthening,
  propagateForRelation,
} from '@zensation/algorithms';

// 1. Schedule a memory with FSRS
const memory = initFromDecayClass('normal_decay');

// 2. A week later, check recall probability (Ebbinghaus curve)
const aWeekLater = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000);
const retention = getRetrievability(memory, aWeekLater);
console.log(`Recall probability: ${(retention * 100).toFixed(1)}%`);
// ~36.8% — retrievability has decayed over the week

// 3. User recalled it anyway — update scheduling
const updated = updateAfterRecall(memory, 4, retention, aWeekLater);
// stability 7 -> 8.19: recalling at low retrievability gives a bigger boost

// 4. Tag emotional significance
const emotion = tagEmotion('I am absolutely thrilled — I got the promotion!');
const weight = computeEmotionalWeight(emotion);
console.log(`Decay multiplier: ${weight.decayMultiplier}x`);
// 2.7x — emotional memories decay nearly 3x slower

// 5. Strengthen knowledge connections (Hebbian)
const stronger = computeHebbianStrengthening(1.0);
// 1.09 — "neurons that fire together wire together"

// 6. Propagate confidence through your knowledge graph
const confidence = propagateForRelation(0.5, 0.8, 1.0, 'supports');
// 0.9 — supporting evidence increases confidence

Want the advanced algorithms?

import {
  computeKGPredictionError,
  computeAdaptiveFSRSInterval,
} from '@zensation/algorithms/fsrs-vmPFC';

// Couple FSRS scheduling with the prediction-error signal from your
// knowledge graph: when the embedding has shifted a lot since the last
// review (high cosine distance), shrink the next interval; otherwise push
// it out. Both arrays must have the same length.
const lastEmbedding = [0.1, 0.2, 0.3, 0.4];
const currentEmbedding = [0.5, 0.4, 0.1, 0.2];
const pe = computeKGPredictionError(lastEmbedding, currentEmbedding);
const nextInterval = computeAdaptiveFSRSInterval(14, pe);

Each advanced algorithm has its own sub-path (@zensation/algorithms/spectral-health, @zensation/algorithms/ib-budget, …). All zero dependencies.

Runnable examples

Five self-contained examples live in examples/:

Example

Shows

basic-chatbot.ts

Working Memory + Short-Term Memory for conversation context — no SDK needed

with-claude.ts

An Anthropic Claude assistant that remembers across conversations

with-langchain.ts

ZenBrain as the memory backend of a LangChain agent

with-crewai.ts

Multiple agents sharing Working Memory, with Hebbian strengthening

with-vercel-ai.ts

A memory-aware system prompt for the Vercel AI SDK streamText pattern

npx tsx examples/basic-chatbot.ts

The integration examples additionally need their respective SDK installed. Want a LlamaIndex.TS or Mastra example? Those are open as good first issues.

The Science Behind It

7-Layer Memory Architecture

Layer 7: Cross-Context Memory    ← Shared knowledge across domains
Layer 6: Core Memory             ← Pinned facts (Letta-style)
Layer 5: Procedural Memory       ← "How to do X" (skills & workflows)
Layer 4: Long-Term Semantic      ← Facts with FSRS scheduling
Layer 3: Episodic Memory         ← Concrete experiences & events
Layer 2: Short-Term / Session    ← Current conversation context
Layer 1: Working Memory          ← Active task focus (7±2 items)

Each layer has different retention characteristics, consolidation rules, and retrieval mechanisms — just like the human brain.

FSRS Spaced Repetition

FSRS (Free Spaced Repetition Scheduler) outperforms SM-2 by 30%. It uses the desirable difficulty principle: reviewing when retention is low gives a bigger stability boost. Your AI reviews important facts at optimal intervals — never too early (wasteful), never too late (forgotten).

Emotional Memory

The amygdala modulates memory consolidation — emotional events are remembered more vividly (flashbulb memory). ZenBrain's emotional tagger assigns arousal, valence, and significance scores using a 400+ keyword lexicon (English & German). Emotional memories get up to 3x longer decay half-lives.

Hebbian Learning

"Neurons that fire together wire together" (Hebb, 1949). Knowledge graph edges that are frequently co-activated grow stronger. Unused edges decay and eventually get pruned. The result: a self-organizing knowledge structure that reflects actual usage patterns, with homeostatic normalization to prevent runaway growth.

Ebbinghaus Forgetting Curves

Ebbinghaus (1885) showed that memory decays exponentially: R = e^(-t/S). ZenBrain implements personalized decay profiles that adapt to individual learning patterns, with SM-2 compatibility for existing spaced repetition systems.

Context-Dependent Retrieval

Tulving's Encoding Specificity Principle (1973): memories are recalled better when the retrieval context matches the encoding context. ZenBrain captures temporal context (time of day, day of week) and task type at encoding time, providing up to a 30% retrieval boost when contexts match.

Bayesian Confidence Propagation

Knowledge isn't isolated — facts support or contradict each other. ZenBrain propagates confidence through your knowledge graph using Bayesian belief updates: supporting evidence increases confidence, contradictions decrease it, with damping for numerical stability.

Sleep Consolidation

During sleep, the hippocampus replays recent experiences, strengthening important memories and pruning weak connections (Stickgold & Walker, 2013). ZenBrain simulates this process: selectForReplay() prioritizes emotional and recently-accessed memories, simulateReplay() boosts their stability by 50%, and pruneWeakConnections() removes weak Hebbian edges — implementing the Synaptic Homeostasis Hypothesis (Tononi & Cirelli, 2006).

import { selectForReplay, simulateReplay } from '@zensation/algorithms/sleep-consolidation';

// Select memories for overnight consolidation
const toReplay = selectForReplay(allMemories);
// Simulate sleep replay — stability ↑, weak edges pruned
const result = simulateReplay(toReplay);
console.log(`Replayed ${result.summary.totalReplayed} memories, avg stability +${result.summary.avgStabilityIncrease.toFixed(1)} days`);

Memory Coordinator

The MemoryCoordinator orchestrates all 7 layers into a single cohesive system — inspired by Global Workspace Theory (Baars, 1988):

import { MemoryCoordinator } from '@zensation/core';

const memory = new MemoryCoordinator({ storage: adapter, embedding: embedder });

// Auto-routes to the right layer (semantic, episodic, procedural, or core)
await memory.store('User prefers TypeScript', { type: 'auto' });

// Cross-layer search with ranked, deduplicated results
const results = await memory.recall('programming preferences');

// Consolidate: promote episodic → semantic, apply decay
await memory.consolidate();

// FSRS review queue across all layers
const dueItems = await memory.getReviewQueue();

Packages

Package

Description

Status

@zensation/algorithms · source

20 algorithm modules — 10 core (FSRS, Hebbian, Ebbinghaus, emotional, Bayesian, sleep consolidation, intervals, visualization) + 10 advanced (vmPFC-FSRS, two-factor Hebbian, IB budget, Hopfield STM, …)

:white_check_mark: Published

@zensation/core · source

Memory layers, coordinator, adapter interfaces

:white_check_mark: Published

@zensation/adapter-postgres · source

PostgreSQL + pgvector storage adapter

:white_check_mark: Published

@zensation/adapter-sqlite · source

SQLite storage adapter (zero-config)

:white_check_mark: Published

@zensation/mcp · source

MCP server — gives any MCP client (Claude Desktop, Claude Code, Cursor) the seven layers as four tools. Carries the protocol SDK, so the core stays dependency-free

:white_check_mark: Published

@zensation/ai-sdk · source

Vercel AI SDK middleware — recall before the model call, store after it. Works with any provider, zero runtime dependencies

:white_check_mark: Published

Tree-Shakeable Imports

Every algorithm is available as a subpath export:

// Import everything
import { tagEmotion, updateAfterRecall } from '@zensation/algorithms';

// Or just what you need (better tree-shaking)
import { updateAfterRecall } from '@zensation/algorithms/fsrs';
import { tagEmotion } from '@zensation/algorithms/emotional';
import { computeHebbianStrengthening } from '@zensation/algorithms/hebbian';
import { propagateForRelation } from '@zensation/algorithms/bayesian';
import { selectForReplay } from '@zensation/algorithms/sleep-consolidation';
import { getRetrievabilityWithCI } from '@zensation/algorithms/intervals';
import { generateRetentionCurve } from '@zensation/algorithms/visualization';

Use Cases

AI Chatbots with Long-Term Memory

import { updateAfterRecall, getRetrievability, scheduleNextReview } from '@zensation/algorithms/fsrs';
import { tagEmotion, computeEmotionalWeight } from '@zensation/algorithms/emotional';

// When your AI learns a fact about the user:
function rememberFact(fact: string) {
  const memory = initFromDecayClass('normal_decay');
  const emotion = tagEmotion(fact);
  const weight = computeEmotionalWeight(emotion);

  // Emotional facts get longer retention
  return {
    ...memory,
    emotionalWeight: weight.consolidationWeight,
    decayMultiplier: weight.decayMultiplier,
  };
}

// Before each conversation, check what needs reinforcement:
function getFactsDueForReview(facts: MemoryState[]) {
  return facts.filter(f => getRetrievability(f) < 0.7);
}

Knowledge Graph with Self-Organizing Edges

import { computeHebbianStrengthening, computeHebbianDecay } from '@zensation/algorithms/hebbian';
import { propagateForRelation } from '@zensation/algorithms/bayesian';

// When two concepts are mentioned together:
function coActivate(edge: { weight: number }) {
  edge.weight = computeHebbianStrengthening(edge.weight);
}

// Periodic maintenance — decay unused edges:
function decayEdges(edges: { weight: number; lastUsed: Date }[]) {
  for (const edge of edges) {
    edge.weight = computeHebbianDecay(edge.weight);
    // Edges below MIN_WEIGHT (0.1) can be pruned
  }
}

RAG with Confidence Scoring

import { propagateForRelation, isSignificantChange } from '@zensation/algorithms/bayesian';

// After retrieval, propagate confidence through related facts:
function updateConfidenceGraph(facts: Fact[], relations: Relation[]) {
  for (const rel of relations) {
    const newConf = propagateForRelation(
      rel.target.confidence,
      rel.source.confidence,
      rel.weight,
      rel.type // 'supports' | 'contradicts' | 'related_to'
    );
    if (isSignificantChange(newConf, rel.target.confidence)) {
      rel.target.confidence = newConf;
    }
  }
}

Extracted From Production

These aren't toy implementations — ZenBrain's algorithms are extracted from ZenAI, a production AI platform. Everything claimed here is verifiable in this repository:

  • 528 tests (429 algorithms + 99 core), all passing

  • Zero runtime dependencies — pure TypeScript, dual ESM + CJS, tree-shakeable subpath exports

  • Reproducible — building from this source produces the same 153-file @zensation/algorithms@0.4.5 tarball published on npm

  • 7-layer memory architecture grounded in published neuroscience

Contributing

We welcome contributions! See CONTRIBUTING.md for guidelines. Issues and pull requests get a first response typically within 72 hours.

Resources: API Reference | Recipes | Architecture | Benchmarks | FAQ | Roadmap

# Clone the repo
git clone https://github.com/zensation-ai/zenbrain.git
cd zenbrain

# Install dependencies
npm install

# Run tests
npm test

# Build all packages
npm run build

Research

ZenBrain's architecture and algorithms are documented in an open-access technical disclosure:

If you use ZenBrain in academic work, please cite:

@misc{bering2026zenbrain,
  title         = {ZenBrain: A Neuroscience-Inspired 7-Layer Memory Architecture for Autonomous AI Systems},
  author        = {Bering, Alexander},
  year          = {2026},
  eprint        = {2604.23878},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  doi           = {10.5281/zenodo.19353663},
  url           = {https://arxiv.org/abs/2604.23878}
}

Community

License

Apache 2.0 — use it in production, modify it, distribute it. Just keep the attribution.

Available Tools

4 tools
zenbrain_consolidateConsolidate memoryA
Destructive

Run one consolidation pass: promote repeated episodes into semantic facts, decay stale working-memory slots, prune what has fallen below the retention threshold. This is the sleep-like maintenance step — safe to run periodically, not per turn.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
prunedYesItems pruned below the retention threshold.
decayedYesWorking-memory slots decayed.
promotedYesEpisodes promoted to semantic facts.

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful context by enumerating the destructive actions (promote, decay, prune) and qualifies safety ('safe to run periodically'), which helps the agent understand the nature of the operation. It does not mention potential irreversible side effects or interactions with other tools, but it goes slightly beyond the annotations.

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?

The description is two sentences, front-loaded with the core action and followed by a usage note. Every sentence earns its place—no filler or repetition. It is compact and scannable.

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 tool with no parameters, an output schema, and a clear conceptual role, the description covers what it does and when to run it. It doesn't detail the output format (but the output schema exists) or potential side effects on other memory operations, but these are minor gaps given the tool's simplicity.

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

Parameters4/5

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, the baseline for 0 params is 4. The description doesn't need to explain parameters, and it doesn't add anything about them, so the baseline stands.

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 clearly states what the tool does: runs a consolidation pass that promotes repeated episodes to facts, decays stale slots, and prunes below-threshold items. It identifies a specific verb and resource, and its 'sleep-like maintenance step' phrasing hints at its distinct role relative to store/recall, though it doesn't name sibling tools explicitly.

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

Usage Guidelines3/5

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

The description provides a frequency guideline ('safe to run periodically, not per turn'), which tells the agent when it is appropriate to invoke. However, it does not contrast with alternatives (e.g., when to use zenbrain_store vs. this), so the agent must infer the tool's niche from the name and purpose.

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

zenbrain_healthInspect memory stateA
Read-only

Report how full each of the seven layers is: working-memory slots in use, interactions held, episodes, facts and how many are due for review, procedures, core blocks. Use it to check what the agent actually remembers.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description aligns with that by framing the operation as a report. It adds meaningful context by specifying the exact metrics reported (slots in use, episodes, facts due for review, etc.), which goes beyond the annotation and clarifies the tool's non-mutating scope.

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?

Two sentences with no filler. The first sentence front-loads the core reporting content, and the second provides the practical usage intent. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-parameter, read-only inspection tool, the description fully covers what the agent needs to know: what is reported, in what granularity, and why it would be used. No output schema exists, but the description sufficiently characterizes the return content.

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

Parameters4/5

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

There are zero parameters, so the description does not need to explain parameter behavior. The schema coverage is trivially 100%, and the description appropriately focuses on what the tool returns rather than inputs.

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?

The description states a specific verb ('Report') and resource ('each of the seven layers'), enumerating the exact memory categories covered. It clearly distinguishes this inspection tool from the sibling tools (store, recall, consolidate) by framing it as a state check rather than a mutation or retrieval operation.

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

Usage Guidelines4/5

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

The description gives an explicit use case: 'Use it to check what the agent actually remembers.' It does not explicitly mention when not to use it or name alternatives, but for a zero-parameter health-check tool, the intended context is clear and unambiguous.

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

zenbrain_recallRecall memoriesA
Read-only

Search long-term memory for anything relevant to a query. Searches every layer by default and returns results ranked by relevance, each tagged with the layer it came from. Use this before answering when the user refers to something from an earlier session.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results (default 10).
queryYesWhat to look for, in plain language.
layersNoRestrict the search to these layers. Defaults to all but working.
taskTypeNoCurrent task, e.g. 'coding', 'writing' — used for context matching.
minConfidenceNoDrop results below this confidence.
includeContextNoBoost results matching the current context.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesHow many memories were returned.
resultsYesMatching memories, most relevant first.
skippedYesRows that carried no readable content and were left out of `results`.

TDQS

A4/5.0
Behavior3/5

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

Adds behavioral context beyond annotations: default full-layer search, relevance ranking, and layer tagging. However, the claim that it 'searches every layer by default' conflicts with the schema's layers property, which defaults to 'all but working', creating ambiguity about actual default behavior.

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?

Two tight sentences with no filler. The core action and the usage context are both front-loaded, and every sentence contributes useful information.

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?

The description covers what the tool does, when to use it, and what results look like. The presence of an output schema and comprehensive parameter descriptions reduce the burden further. The main gap is the internally inconsistent default-layer statement, which could mislead an agent into incorrect assumptions.

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 the parameters are already well documented. The description does not add meaningful parameter-level semantics beyond what the schema states, and the 'every layer' phrasing could actually mislead relative to the layers parameter default.

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 ('Search long-term memory') plus a query-based scope. It also clarifies what the tool returns (relevance-ranked results with layer tags), making it readily distinguishable from sibling tools like zenbrain_store or zenbrain_consolidate.

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

Usage Guidelines4/5

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

Gives a clear, actionable usage context: 'Use this before answering when the user refers to something from an earlier session.' It does not explicitly list when not to use it or name sibling alternatives, but the guidance is sufficiently clear for an agent to know when to invoke it.

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

zenbrain_storeStore a memoryA

Write something into long-term memory so it survives this conversation. Routing is automatic by default: a general statement becomes a semantic fact, a narrated event becomes an episode, a sequence of instructions becomes a procedure. Set type only when you want to override that. Returns the id of the stored memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoRouting hint. 'auto' (default) decides from the content.
stepsNoOrdered steps. Required when type is 'procedure'.
toolsNoTools a procedure uses.
sourceNoWhere this came from, e.g. 'user', 'ai', 'import'.
contentYesThe memory to store, in plain language.
contextNoContext domain, e.g. 'work', 'personal', 'learning'.
outcomeNoWhat the procedure achieves.
confidenceNoHow certain this is (0–1). Above 0.9 routes to core memory.
emotionalWeightNoEmotional significance (0–1). Detected from the content when omitted.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYesIdentifier of the stored memory.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only say the tool is not read-only, not idempotent, and not destructive. The description adds meaningful behavioral context: memories persist beyond the conversation, routing is automatic with concrete mapping (statement→fact, event→episode, instructions→procedure), and the tool returns an id. It does not mention potential side effects like duplicate creation, but overall it adds solid value beyond the annotations.

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?

Three sentences with no filler. The purpose is front-loaded, the routing behavior is summarized efficiently, and the return value is stated at the end. Every sentence contributes useful information.

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 tool with 9 parameters and an output schema, the description covers the core behavior, routing, and return value well. It does not spell out that `steps` is required for `type=procedure`, but the schema already handles that. The description is sufficiently complete for an agent to call the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the automatic routing semantics and instructing to set `type` only to override, which is not fully captured by the schema. It does not elaborate on `steps` or `outcome`, but those are already described in the schema.

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?

The description clearly states the operation: 'Write something into long-term memory so it survives this conversation.' It uses a specific verb and resource, and the sibling names (consolidate, recall, health) make the distinction obvious without further explanation.

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

Usage Guidelines4/5

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

The description gives clear context: this is the tool for persisting memories, with automatic routing and an override via `type`. It does not explicitly say 'use this instead of recall for retrieval' or offer when-not-to-use guidance, which keeps it from a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.5
    • First observedzenbrain_consolidate
    • First observedzenbrain_health
    • First observedzenbrain_recall
    • First observedzenbrain_store
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool serves a uniquely identifiable purpose: consolidate handles maintenance, store writes new memories, recall retrieves existing ones, and health reports system status. There is no overlap or ambiguity in their roles.

Naming Consistency5/5

All tools follow a clear 'zenbrain_' prefix with a descriptive second word (consolidate, store, recall, health). Though 'health' is a noun rather than a verb, the pattern is uniform and predictable across all four tools.

Tool Count5/5

Four tools is ideal for a focused memory management system. Each tool covers a core operation (write, read, maintain, monitor) without redundancy or bloat.

Completeness4/5

The tool set covers the full lifecycle of memory management: storage, retrieval, consolidation/pruning, and health inspection. The only minor gap is the lack of an explicit delete/forget tool, but consolidation handles pruning automatically, so agents can achieve the same result.

Maintenance

ActivityActive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers

  • alaya

    SecurityRonin
    A
    license
    Not graded
    quality
    C
    maintenance
    A local memory engine for AI agents. Stores conversation episodes, consolidates knowledge through a neuroscience-inspired lifecycle, and builds a personal knowledge graph — all in a local SQLite database.
    16
    MIT

  • brainlayer

    EtanHey
    A
    license
    Not graded
    quality
    B
    maintenance
    Local-first persistent memory layer for AI agents. Provides hybrid search (FTS5 keyword + vector embeddings) over 223K+ knowledge chunks via MCP. Tools: brain_search, brain_store, brain_entity, brain_subscribe. Features pub/sub with stable agent identity, delivery tracking, and Claude --channels integration. SQLite + BrainBar Swift daemon on Unix socket.
    1,410 PyPI
    9
    Apache 2.0

  • misMEM

    lucasmella-stack
    A
    license
    Not graded
    quality
    A
    maintenance
    Provides persistent, cooperative memory for LLMs via MCP, with SQLite storage and tools for capturing, recalling, consolidating, crystallizing, and forgetting memories across sessions.
    3
    MIT