ZenBrain Memory

@zensation/mcp

Status: early release. The tool surface is small on purpose and may still change before 1.0. The memory layers underneath it are the same ones the ZenBrain paper describes and the benchmarks measure.

An MCP server that gives any MCP client — Claude Desktop, Claude Code, Cursor, or your own — a memory that survives the conversation.

Five tools, one local SQLite file, no account and no network call.

Each tool also tells the client what it does to the store, through the MCP tool annotations: zenbrain_recall and zenbrain_health are read-only; zenbrain_store only adds; zenbrain_forget and zenbrain_consolidate are marked destructive (consolidation removes decayed working-memory slots), so a client that asks before destructive calls asks before these two. No tool reaches anything outside the local file.

Install

Requires Node.js 22 or newer.

npm install -g @zensation/mcp

Configure your client

{

"mcpServers": { "zenbrain": { "command": "npx", "args": ["-y", "@zensation/mcp"], "env": { "ZENBRAIN_DB": "~/.zenbrain/memory.db" } } } }

The server speaks MCP over stdio. Stdout carries protocol traffic only; diagnostics go to stderr.

In Claude Code, one line does the same with the memory in ~/.zenbrain/memory.db:

claude mcp add --scope user zenbrain -e ZENBRAIN_DB=~/.zenbrain/memory.db -- npx -y @zensation/mcp

or install the Claude Code plugin, which runs this server at a pinned version, keeps the memory in the same file and lets you choose another (db_path):

claude plugin install zenbrain --marketplace zensation-ai/zenbrain

The seven layers

Storing is not filing. Which layer a memory lands in decides how it is retrieved and what consolidation does with it. The five tools reach working, episodic, semantic, procedural and core memory; short-term memory shows up only as a counter in zenbrain_health, and cross-context memory is not wired to any tool.

Nothing in long-term memory decays or is deleted on its own; only working memory decays. Every fact gets an FSRS-style review schedule, but no tool reports a review, so through this server the schedule is not advanced. Emotional weight decides routing (above 0.5: an episode) and which episodes consolidation turns into facts. The algorithms are in @zensation/algorithms and can be read line by line.

This server configures no LLM provider, so nothing in it calls a model: routing on store is a content heuristic, and consolidation runs without generated summaries.

What this release does not do

Worth knowing before you wire it in:

• No embedding provider is configured by default, so recall is lexical, not semantic. Without vectors, recall ranks by folded token overlap — umlauts and accents are folded, rarer words weigh more, and an adjacent phrase beats the same words scattered. It will find "Kieler Foerde" in a note about the "Kieler Förde"; it will *not* connect "car" to "automobile". Episodes and facts are ranked over the most recent 500 of each, procedures over the 500 with the highest success rate. A layer in which the query matches nothing returns its most recent episodes and facts, or its most successful procedures, at score: 0, behind every hit; every core block comes with 0.5 or 0.8, so a block can rank above a weak hit. Working memory, when you ask for it, is ranked the same way. Pass an EmbeddingProvider through the library for true semantic matching — that is the configuration the published benchmarks were measured with.
• SQLite similarity search is a full scan. Fine for one person's memory; use @zensation/adapter-postgres for larger volumes.
• Consolidation is a tool call, not a schedule. Nothing runs it for you.
• The store is a plain file. It is not encrypted. Put it somewhere you would put a notebook. While the server runs, SQLite keeps -wal and -shm files next to it.

Using it as a library

The server factory is exported, so you can mount ZenBrain's tools on a server of your own or drive them in tests. The package is ESM; require() loads it on Node 22.12 and later (on 22.0–22.11, use import).

import { createZenBrainServer } from '@zensation/mcp/server';

import { MemoryCoordinator } from '@zensation/core'; import { SqliteAdapter } from '@zensation/adapter-sqlite';

const coordinator = new MemoryCoordinator({ storage: new SqliteAdapter({ filename: './memory.db' }), });

const server = createZenBrainServer(coordinator); // connect it to any transport you like — the caller owns the coordinator's lifecycle

Zero-dependency, and where that stops

@zensation/algorithms and @zensation/core pull nothing but each other. That claim is checked in CI on every push against the packed tarballs, not against the source tree.

This package is deliberately outside that boundary. An MCP server needs the protocol SDK, so it carries one. Keeping it in its own package is what lets the core stay clean: installing @zensation/core never pulls the MCP SDK, and installing this never weakens the claim the core makes.

About ZenBrain

ZenBrain is a seven-layer, neuroscience-derived memory architecture for LLM agents, built in TypeScript and published under Apache-2.0; @zensation/algorithms and @zensation/core have no third-party dependencies. The benchmark results, and the configuration they were measured in, are reported in the paper; the reproduction packages are on Zenodo.

Works out of the box without an embedding provider — lexical ranking, nothing extra to install. In the paper, ZenBrain's benchmark runs against other systems used nomic-embed-text as the embedding provider; the retrieval ablations used OpenAI text-embedding-3-small.

• Source and issues: github.com/zensation-ai/zenbrain
• Paper: arXiv:2604.23878 · Open-access archive: 10.5281/zenodo.19353663
• Try it in the browser: zensation.ai/en/playground
• Model card: huggingface.co/zensation-ai/zenbrain
• Packages: @zensation/algorithms · @zensation/core · @zensation/adapter-postgres · @zensation/adapter-sqlite · @zensation/mcp · @zensation/ai-sdk
• Registry entry: ai.zensation/zenbrain

License: Apache-2.0