Updated 2026-07-02
linksee-memory vs the official MCP memory server — an honest comparison
Both are free, local, and speak MCP. They answer different questions: “what are the facts?” vs “why did we decide this — and are we still following it?”
If you searched for a memory MCP server, you probably found @modelcontextprotocol/server-memory — Anthropic's official reference implementation — and a long tail of alternatives. This page compares it with linksee-memory specifically, because they occupy the same niche: free, local-first, no cloud account. We build linksee-memory, so read this as an opinionated but factual comparison — every claim below is checkable in both READMEs.
The short version
The official server is a knowledge graph: entities, relations, and observations, persisted to a JSONL file. It is deliberately minimal and does exactly what the agent explicitly tells it to do.
linksee-memory is a decision-memory layer: it stores not just facts but the reasoning around them in six explicit layers (goal / context / emotion / implementation / caveat / learning), and then uses that record to detect drift — the moment your code or docs silently diverge from something you decided earlier.
Feature comparison
| @modelcontextprotocol/server-memory | linksee-memory | |
|---|---|---|
| Maintained by | Anthropic (official reference server) | Indie OSS (MIT), weekly releases since Apr 2026 |
| Storage | Knowledge graph in a JSONL file | One SQLite file (~/.linksee-memory/memory.db) |
| Memory model | Entities · relations · observations | 6 layers: goal / context / emotion / implementation / caveat / learning |
| How memories get written | Agent explicitly calls create_entities / add_observations | Explicit tools + optional auto-capture via Claude Code hooks |
| Decision-drift detection | — | Anchors + drift states, with file:line evidence via the map CLI |
| Token savings on file re-reads | — | AST-aware diff cache (read_smart), measured 50–99% |
| Forgetting / relevance decay | — (manual delete tools) | Active forgetting with decay; caveats are protected |
| Works with any MCP client | Yes (stdio) | Yes (stdio); documented setup for 6 clients |
| Cloud / account required | No | No |
| Install | npx -y @modelcontextprotocol/server-memory | npx -y linksee-memory setup |
Where the official server is the better choice
- You want the reference implementation. It is maintained by Anthropic, tracks the MCP spec closely, and its code is small enough to read in one sitting.
- Your memory needs are simple facts and relationships. “Alice works at Acme, prefers Python” maps perfectly onto entities and observations. A 6-layer structure would be overhead.
- You want zero opinions. No decay, no auto-capture, no guard — nothing happens unless the agent calls a tool.
Where linksee-memory earns its extra surface area
- The WHY survives the session boundary. A flat fact (“we use FTS5”) is less useful than the caveat that comes with it (“vector search was rejected because…”). The 6-layer structure keeps the reasoning retrievable and explainable.
- Drift detection. Memory tools remember what you did; nothing notices when this week's session quietly contradicts last week's decision. linksee-memory declares decisions as anchors and reconciles reality against them — ask
what's drifting?in any session. - Token economics.
read_smartreturns only diffs on re-reads (measured 86% savings on a typical TypeScript edit, 99% on unchanged files), which matters if your agent re-reads large files every session. - Capture without discipline. Optional Claude Code hooks record sessions automatically, so memory accumulates even when nobody remembers to say “save this.”
Can I run both?
Yes. They are separate MCP servers with separate storage, and neither interferes with the other. In practice most people pick one to avoid the agent splitting its writes across two stores.