Mnemodb MCP server

MnemoDB

A structured, portable, auditable memory format for AI agents — a database whose files you can read.

claude mcp add mnemodb -- npx -y @mnemodb/mcp@latest

What it is

MnemoDB is a plain-text, Markdown-compatible file format (.mem.md) for the persistent memory of AI agents, plus the engine and tooling around it. A memory is just a Markdown heading with a one-line metadata span:

## decision: We use PostgreSQL LISTEN/NOTIFY for cache invalidation, not Redis
`mnemo c4d1 | src: user | conf: high | supersedes: 99e0`

Redis was dropped to cut infra count. Revisit if we exceed ~500 notifications/s.

It renders in any Markdown viewer, diffs cleanly in git, you can hand-edit it — and a program can read every field with no ambiguity. Every existing CLAUDE.md / AGENTS.md is already a valid (untyped) MnemoDB file, so adoption requires renaming nothing and migrating nothing.

Why — and how it relates to memory you may already have

AI agents already have some memory. CLAUDE.md loads a flat file into context every session. Claude's memory tool gives the model a /memories folder and lets it organize files however it likes. Both work. MnemoDB is not trying to replace them — it's the structure and discipline they don't provide.

The difference is philosophy. "Give the model a folder and trust it to organize" is simple and often good enough. MnemoDB is the opposite bet: a defined format with real guarantees. That buys you four things a free-form folder or a flat file doesn't:

compact pass that archives what's expired or replaced. A flat memory file only grows and eventually rots; MnemoDB can forget on purpose, auditably.

• Lifecycle, not sprawl. Typed entries with TTLs, supersession, and a

user, agent, or tool. Tool-sourced content (e.g. text scraped from a web page) is flagged untrusted and can never supersede a human instruction, so a poisoned memory can't hijack future sessions. This matters precisely because agents write memory automatically.

• Provenance and a trust model. Every memory records where it came from —

entry, mnemo trace tool (or mnemo trace tool/session-abc) lists exactly what one source put in your memory — the question a provenance-free folder can't answer at all. An optional owner: records who is accountable for a memory, as distinct from where it came from; doctor flags decisions without one, but only once a store actually uses owners.

• Containment when something does go wrong. Because provenance is on every

client. Your agent's accumulated knowledge isn't locked to one vendor or tool.

• Portability. The same files work across Claude Code, Cursor, and any MCP

exactly what your agent learned or changed — no opaque database, no cloud dashboard. mnemo doctor lints for staleness, contradictions, and damage.

• Auditability. It's readable Markdown in your git repo. git diff shows

And the tools are memory-semantic, not raw file ops. A generic memory tool gives the model create/delete/replace on a folder; MnemoDB gives it operations that understand the structure — inspect an entry's full history, ask the store to report on itself, forget something auditably and recoverably (and never erase a higher-trust memory), or change what loads into context — each with the trust and lifecycle rules built in.

When MnemoDB is worth it: you want the agent to maintain memory itself across many sessions without it decaying, you work across more than one AI tool, or you need to audit and trust what's in memory. When it's probably overkill: a short CLAUDE.md you curate by hand already does the job. We'd rather tell you that up front.

How to use it

Shortened. The full README is on GitHub.