MCP Memory Server

What it is and how it works

MCP Memory Server is one of the reference server implementations published inside the official modelcontextprotocol/servers repository — the same repo that ships the filesystem, fetch, git, and other "canonical" MCP servers Anthropic maintains as examples of the protocol done correctly. Its job is narrow and specific: give an LLM agent a place to persist facts across conversations by exposing a small set of MCP tools (create_entities, create_relations, add_observations, delete_entities, read_graph, search_nodes, and a handful of siblings) that operate on a local knowledge graph instead of a flat document store.

The data model is deliberately simple and borrowed from classic knowledge-graph theory: entities (named nodes with a type, like person, project, or preference), relations (directed, typed edges between entities, e.g., "works_at", "depends_on"), and observations (freeform text facts attached to a specific entity, appended over time rather than overwritten). When an agent using an MCP client — Claude Desktop, Claude Code, or any other MCP-aware host — decides something is worth remembering, it calls the appropriate tool, and the server appends that fact to the graph. On the next session, the agent can call read_graph or search_nodes to pull relevant context back in before responding.

Under the hood, storage is about as unglamorous as it gets: a JSON file (or JSON-lines file, depending on version) on local disk, read into memory and rewritten on mutation. There is no embedding model, no vector index, no query planner — retrieval is graph traversal and substring/keyword matching over entity names and observation text. This is the entire point: it is a reference implementation meant to demonstrate the MCP tool-calling pattern for stateful memory, not a production memory backend. It runs over stdio (or can be adapted to run over SSE/HTTP) like any other MCP server, spawned as a child process by the host application.

Deployment patterns

The overwhelmingly common deployment is single-user, single-machine: a developer adds the memory server to their Claude Desktop or Claude Code MCP config (claude_desktop_config.json or .mcp.json), pointing it at a local JSON file path, often via npx -y @modelcontextprotocol/server-memory so there's nothing to build or install ahead of time. The agent then has persistent memory scoped to that one file — useful for a solo developer who wants their coding assistant to remember project conventions, personal preferences, or running context between sessions without re-explaining everything each time a context window resets.

A second common pattern is per-project memory: teams check a memory.json into a project-local (usually gitignored, sometimes intentionally committed for shared team context) directory so that anyone using an MCP-compatible agent against that repo inherits the same graph of facts about the codebase, its people, and its decisions. This works because the server takes a configurable storage path — there's no requirement to use a single global memory file.

What you essentially never see is a shared multi-user or multi-agent deployment. There's no access control, no per-user namespacing, no concurrency handling beyond whatever file-locking the underlying JSON read/write does. Running it as a "team server" that several people's agents write to concurrently is asking for lost writes or corrupted state — the architecture assumes one reader/writer at a time. If you need that, this is the wrong tool, not a scaling problem to work around.

How it compares

Against Zep (a purpose-built memory layer with temporal knowledge graphs, entity extraction pipelines, and a hosted or self-hosted service model), MCP Memory Server is a toy by comparison — no automatic fact extraction, no temporal reasoning about when a fact stopped being true, no dedicated query API beyond what MCP tools expose. Zep is built to serve production agent applications with many end users; this server is built to demonstrate a pattern in an afternoon.

Against Graphiti (the open-source temporal knowledge-graph library that Zep itself is partly built on), the comparison is similar but closer in spirit: both use an entity-relation graph model, but Graphiti adds bi-temporal tracking, LLM-driven entity/relation extraction from unstructured text, and integration with real graph databases (Neo4j, FalkorDB). MCP Memory Server has none of that — its graph is hand-populated by explicit tool calls from the agent, not automatically extracted, and it lives in a JSON file rather than a graph database engine.

Against vector-store-backed memory approaches (a Chroma or Qdrant instance paired with an embedding pipeline, wired up as a custom MCP server or LangChain memory module), MCP Memory Server trades semantic recall for structural clarity. You cannot ask it "what did we discuss that's related to deployment issues" and get a similarity-ranked answer — you get keyword/graph matches only. But you also don't need to run an embedding model, choose a distance metric, or manage index rebuilds. It is faster to stand up and easier to reason about at the cost of recall quality as the graph grows.

Best use cases and honest limitations

This is the right tool for a solo developer or small team that wants an agent to retain lightweight, structured context — names, preferences, project facts, relationships between people/projects/decisions — between sessions, with zero infrastructure. The knowledge-graph shape is genuinely useful even at small scale: it forces facts into entities and typed relations rather than an undifferentiated blob of text, which makes later inspection and manual editing of the JSON file tractable.

It is the wrong tool the moment you need semantic search over memory (no embeddings, so unrelated phrasing won't match), the moment more than one process needs to write concurrently (no isolation or locking guarantees to speak of), or the moment the graph grows large enough that JSON-on-disk becomes slow to load and rewrite on every mutation. There's also no forgetting/decay mechanism — observations accumulate indefinitely unless the agent or operator explicitly deletes them, so long-lived graphs need manual pruning. Treat it as what it's named: a reference implementation and an entry-tier stepping stone, not a memory system to build a product on.