MCP Spotlight: Memory MCP Server — Anthropic's Reference Implementation for Persistent, Shareable, Graph-Based Agent Memory Across Conversations
Server: @modelcontextprotocol/server-memory by Anthropic
License: MIT · Tools: 9 (entities + relations + observations) · Transport: stdio
Storage: Local JSONL file (per-agent, persistent, version-controllable)
GitHub: github.com/modelcontextprotocol/servers/tree/main/src/memory
NPM: @modelcontextprotocol/server-memory
MCP Tracker: glama.ai/mcp/servers/modelcontextprotocol/memory
Every agent forgets. Conversation context is volatile; when the session ends, the model loses everything it learned. The naive "include the entire conversation history in every prompt" approach blows out the context window and decays in relevance. The "vector store + RAG" approach retrieves semantically similar snippets but loses the relational structure. The "ship a generic document DB" approach forces the agent to model its own schema from scratch.
The Memory MCP Server by Anthropic is the bridge that resolves this. 9 tools built around a graph-based knowledge model with three primitives — entities (the nodes), relations (the typed edges), observations (the facts attached to nodes). The graph is stored as a JSONL file on disk, persistent across sessions, version-controllable with git, shareable across agents.
This is the persistent memory default for AI agents in 2026. Small surface, large blast radius of capability.
The Three Primitives: Entities, Relations, Observations
The MCP surface is built on three orthogonal primitives that compose into a full knowledge graph:
1. Entities — the nodes
{
"name": "Kevin Schmidt",
"entityType": "Person",
"observations": [
"Founder of centerbit UG",
"Based in Germany (DACH region)",
"Solo founder with minimal financial resources",
"Building Facio + Placet.io as complementary HITL products",
"Communicates in German, prefers informal 'du'"
]
}
An entity is a node in the graph. It has a unique name, a type, and a list of observations (facts). Entities are the "nouns" of the agent's knowledge — people, projects, products, companies, concepts, technologies.
The agent creates entities as it learns:
create_entities([
{name: "Kevin Schmidt", entityType: "Person", observations: [...]},
{name: "centerbit UG", entityType: "Company", observations: [...]},
{name: "Facio", entityType: "Product", observations: [...]},
{name: "Placet.io", entityType: "Product", observations: [...]}
])
The graph accumulates. Each new conversation enriches it.
2. Relations — the typed edges
{
"from": "Kevin Schmidt",
"to": "centerbit UG",
"relationType": "founded"
}
A relation is a directed, typed edge between two entities. Relations are the "verbs" — what connects the nouns. The agent creates relations to capture the structure of its knowledge:
create_relations([
{from: "Kevin Schmidt", to: "centerbit UG", relationType: "founded"},
{from: "centerbit UG", to: "Facio", relationType: "owns"},
{from: "centerbit UG", to: "Placet.io", relationType: "owns"},
{from: "Facio", to: "Placet.io", relationType: "complements"},
{from: "Kevin Schmidt", to: "Facio", relationType: "built"},
{from: "Kevin Schmidt", to: "Placet.io", relationType: "built"}
])
The graph captures structure, not just facts. "Kevin founded centerbit, which owns Facio and Placet.io, which complement each other" is a chain of relations, not a single blob.
3. Observations — the facts
add_observations([
{entityName: "Kevin Schmidt", contents: [
"Prefers 'du' over 'Sie' in German",
"Communication style: professional, practical"
]}
])
Observations are facts attached to an entity. They're append-only — the agent adds new observations as it learns, the graph accumulates. Observations are the "facts" — what the agent knows about each noun.
The 9 Tools
The MCP surface is small and focused:
| Tool | Purpose |
|---|---|
create_entities | Add new entity nodes |
create_relations | Add new typed edges |
add_observations | Append facts to existing entities |
delete_entities | Remove entity nodes (and their relations) |
delete_observations | Remove specific facts |
delete_relations | Remove specific edges |
search_nodes | Full-text search across entity names + observations |
read_graph | Get the entire graph (use carefully with large graphs) |
open_nodes | Get specific entities + their immediate relations |
The tools compose into the four basic operations on a knowledge graph:
- Create —
create_entities,create_relations,add_observations - Read —
search_nodes,read_graph,open_nodes - Update —
add_observations(append),create_relations(extend) - Delete —
delete_*variants
The JSONL Storage: Why It Matters
The graph is stored as a JSONL file (one JSON object per line). This design choice has massive implications:
1. Persistent across sessions
The agent writes to the file at the end of each operation. When the next session starts, the agent reads the file and the graph is intact. Knowledge survives conversations.
2. Version-controllable
JSONL is git-friendly. Each line is a JSON object; git diff shows exactly what entities/relations/observations changed. The agent's knowledge graph is code-reviewed like source code:
+ {"type":"entity","name":"Acme Q3 Launch","entityType":"Project","observations":["Target date: 2026-09-30"]}
+ {"type":"relation","from":"Kevin Schmidt","to":"Acme Q3 Launch","relationType":"owns"}
The team can see the agent learning in real-time, code-review the additions, merge them like any other change.
3. Portable across agents
The JSONL file is just data. Move it between machines, share it between agents, back it up with the rest of the team's data. The graph is the agent's persistent knowledge; it lives where the team's data lives.
4. Inspectable and auditable
Read the JSONL file with any tool. The human reviewer sees exactly what the agent knows. For regulated environments, this is the complete knowledge audit trail: "Agent knew X about Kevin Schmidt as of 2026-07-10 18:00 UTC."
5. Schema-less
No migrations, no schema changes, no DB to manage. Add a new entity type, the schema accommodates. Add a new relation type, no problem. The graph is fluid; the storage matches.
For multi-agent setups, the JSONL file becomes the shared memory substrate. Each agent reads it on startup, writes to it on changes, and the team's collective knowledge accumulates in one place.
The Search Pattern
For finding the right context:
search_nodes(query="Steuerberater")
→ Returns entities matching "Steuerberater"
→ Plus related entities reachable via relations
→ Plus the observations on each
The search is full-text across entity names and observation contents. The results include the matched entities plus their immediate relations — so searching for "Steuerberater" returns Kevin, centerbit, the Facio Compliance Agent initiative, the relevant articles, all in one call.
For deep traversal:
open_nodes(names=["Kevin Schmidt"])
→ Returns Kevin's entity + all entities with relations to/from Kevin
The agent builds its working context from the graph, dynamically expanding as it explores related nodes.
The Graph-Memory Advantage Over Vector Stores
Vector stores (Pinecone, Weaviate, Chroma) and graph memory serve different purposes. The Memory MCP server's graph model wins for structured, relational knowledge:
| Use Case | Vector Store | Graph Memory |
|---|---|---|
| Semantic similarity ("find articles like this one") | ✓ | ✗ |
| Typed relations ("who owns what") | ✗ | ✓ |
| Structured facts ("Kevin's communication style") | partial | ✓ |
| Multi-hop reasoning ("what projects does the founder of the company that owns Facio own?") | ✗ | ✓ |
| Code-reviewable knowledge | ✗ | ✓ (JSONL diff) |
| Cross-agent shared knowledge | partial | ✓ (JSONL file) |
| Version history of knowledge | ✗ | ✓ (git) |
For agent memory where structure matters — people, organizations, projects, products, relationships, history — the graph model is the right primitive. Vector stores are the right primitive for unstructured content (article corpora, document search). The two compose: vector store for retrieval, graph for structure.
The Multi-Agent Knowledge Layer
The Memory MCP server becomes the shared knowledge substrate in multi-agent systems:
Planner Agent: Reads graph, plans a campaign
→ Adds: Project "Q3 Launch", relations, observations
Executor Agent: Reads graph, sees the plan, executes
→ Adds: Task status updates, results
Reviewer Agent: Reads graph, reviews the executor's work
→ Adds: Review notes, quality observations
Human: Reads JSONL file, reviews the team's collective knowledge
→ Approves additions, merges via git
All four actors share one graph. The graph is the single source of truth for the team's evolving understanding. Each actor's knowledge is explicit, diffable, reviewable.
For multi-tenanted SaaS setups, per-tenant JSONL files — one per customer, each isolated, each audited.
Facio Integration
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"env": {
"MEMORY_FILE_PATH": "${workspace}/memory/agent-knowledge.jsonl"
}
}
}
}
Facio's audit trail captures every Memory MCP call with the tool, the entity/relation/observation, and the change. For a regulated team (SOC2, ISO 27001, GDPR), this is the complete agent-knowledge audit: "Agent at 14:32 UTC created entity 'Kevin Schmidt', added 5 observations, linked to 'centerbit UG' via 'founded' relation."
For HITL workflows, the Memory MCP server's destructive surface is small — the delete_* tools are the only ones requiring care:
| Tool | Severity | Suggested Gate |
|---|---|---|
search_nodes, read_graph, open_nodes | Read | None — autonomous |
create_entities, create_relations, add_observations | Write, additive | Soft confirm (review what was added) |
delete_entities | Write, destructive | Hard confirm + reason required (knowledge loss) |
delete_observations | Write, destructive (specific facts) | Hard confirm (specific facts can be wrong to delete) |
delete_relations | Write, destructive | Hard confirm |
The delete_entities tool deserves special attention — it's irreversible knowledge loss. The agent's "forgetting" of a person, project, or concept is permanent unless the entity is recreated. Facio should require hard confirmation with a stated reason before any deletion proceeds.
For multi-agent setups (planner + executor + reviewer), the pattern is one Memory MCP server per agent, each with its own JSONL file, plus an optional shared Memory MCP server for cross-agent knowledge. The shared server is read-only for some agents (the executor), read-write for others (the planner).
For team setups, the JSONL file lives in the team's repo, gets reviewed via PR, gets merged via the team's standard process. The agent's knowledge is code-reviewed like any other team artifact.
Quickstart
# 1. Install the Memory MCP server
npm install -g @modelcontextprotocol/server-memory
# 2. Configure with a JSONL file path
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"env": {
"MEMORY_FILE_PATH": "/data/facio-1/.facio/workspace/memory/agent-knowledge.jsonl"
}
}
}
}
# 3. First prompts (the agent populates the graph as it works)
# "Remember that Kevin Schmidt is the founder of centerbit UG, which owns Facio and Placet.io"
# "Note that the team prefers German for user-facing communications"
# "Track the project status: Auth Migration is 60% complete, target date 2026-09-30"
# "What do you remember about Kevin's projects?"
Use Cases
Long-term user model: "Remember my preferences, projects, communication style, and goals across sessions." Persistent user model in the graph.
Project knowledge base: "Track the Auth Migration project: owner, status, target date, blockers, dependencies, milestones." Project entity + relations + observations.
Customer relationship memory: "Remember this customer's preferences, past interactions, and stated requirements." Customer entity + interaction observations.
Codebase understanding: "Build a knowledge graph of our codebase: services, their owners, their dependencies, recent changes." Codebase as a graph.
Decision history: "Track every major decision we make, with the rationale and the date." Decision entities + relations to projects/people.
Team topology: "Map our team: who's in each group, who reports to whom, who owns which product." Team as a graph.
Vendor tracking: "Remember our vendors: Stripe (payments), AWS (hosting), Linear (issue tracking) — with the contracts, the costs, the renewal dates." Vendor entities + relationships.
Research synthesis: "Read 50 papers on multi-agent systems, build a knowledge graph of the key concepts and their relationships." Reading → graph construction.
Knowledge transfer: "When a new engineer joins, share the team's knowledge graph with them." Export the JSONL, hand it over, import it.
Compliance documentation: "Track every customer data handling decision, the legal basis, the consent records." Compliance entities with full audit trail.
Bug pattern tracking: "For each recurring bug type, track the root cause, the fix, the date, the affected versions." Bug entities + relations to fixes/releases.
Feature request memory: "Remember every feature request, the customer, the date, the priority, the status." Feature entities + relations.
Onboarding knowledge: "Capture everything new engineers need to know: tools, conventions, key people, key projects." Onboarding entities, ready for the next new hire.
Personal assistant memory: "Remember my calendar, my contacts, my preferences, my goals." Personal-assistant entities.
Cross-session continuity: "Yesterday we were debugging the auth flow. Pick up where we left off." The graph carries context across sessions.
Multi-tool integration: "When the user mentions 'Kevin' in any context, look up the entity. When they mention 'Facio', look up the product. When they ask about projects, traverse the relations." Cross-tool semantic lookup.
Audit-trail-ready knowledge: "Every claim the agent makes should be traceable back to a graph observation." Grounded, inspectable knowledge.
Team retrospective memory: "After each sprint, capture: what went well, what didn't, what we learned. Build a knowledge base of team evolution." Retrospective as graph observations.
Customer feedback graph: "Link every piece of customer feedback to the customer, the feature area, the date, and the related issue." Feedback entities + multi-hop relations.
Knowledge graph search: "Find me every project that depends on Auth, has a Q3 deadline, and is owned by someone in the Platform team." Multi-criteria graph query.
The Knowledge Persistence Pattern
The Memory MCP Server is the persistent knowledge default for AI agents in 2026. 9 tools (entities, relations, observations, plus search/read/delete), graph-based knowledge model, JSONL storage, MIT-licensed, official Anthropic-maintained.
For any agent that needs to remember — user preferences, project status, customer context, team topology, decision history, codebase structure — this is the bridge. The agent creates entities as it learns, links them with relations, accumulates observations as facts. All persistent across sessions, version-controllable with git, shareable across agents.
For the broader MCP ecosystem, the Memory pattern is the design lesson every "agent-knowledge" tool should learn. Some knowledge is structured; some is unstructured. Structured knowledge deserves a structured store. The graph model — entities + relations + observations — is the right primitive for agent memory that humans can read, code-review, and share. When the agent's knowledge is diffable, the agent's reasoning is auditable.
npx -y @modelcontextprotocol/server-memory with MEMORY_FILE_PATH=/path/to/agent-knowledge.jsonl and your agent has persistent memory.
MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for design clarity, ecosystem impact, and integration fit with Facio's HITL-first agent runtime.