# Memory — MCP Server

> A local knowledge graph that gives an agent memory across sessions.

**Source:** https://mcpplaygroundonline.com/mcp-servers/memory  
**Transport:** stdio  
**Requires auth:** No

---

## What it does

A model forgets everything between sessions. The memory server fixes that with a deliberately simple data model: entities are named nodes with a type, relations are directed edges stated in the active voice, and observations are short atomic facts attached to an entity. An agent creates entities as it learns about them, adds observations over time, and searches the graph at the start of a later conversation to recall what it knows. Everything is persisted to a single JSON Lines file whose path you control, so the memory is inspectable, diffable and deletable — there is no hosted store and nothing leaves your machine. Because the graph is stored as text, you can also seed it by hand or check it into a repository.

## Tools exposed

- create_entities — add nodes with a name, an entity type and initial observations
- create_relations — connect entities with directed, active-voice relations
- add_observations — append new atomic facts to an existing entity
- search_nodes — query across names, types and observation text
- open_nodes — retrieve specific entities and the relations between them
- read_graph — dump the entire knowledge graph
- delete_entities / delete_relations / delete_observations — prune what is stale or wrong

## Example queries you can run

- "Remember that this project uses Postgres 16 and deploys on Fridays."
- "What do you already know about my team and how we work?"
- "Update what you know about the billing service — it moved to a new repo."
- "Show me everything in memory related to the migration project."

## Details

- **Recommended model:** anthropic/claude-sonnet-4.5 — Memory quality depends entirely on the model choosing to write good atomic observations. Sonnet 4.5 is disciplined about this where cheaper models under-record.
- **Transport:** stdio
- **Authentication:** Not required — No credentials. The graph is a local JSON file; access control is the file permissions on the path you configure.
- **Official source:** [Memory MCP Server — official reference implementation](https://github.com/modelcontextprotocol/servers/tree/main/src/memory)

## Connecting to Memory

### Environment variables

- `MEMORY_FILE_PATH` — Absolute path to the JSON file holding the graph. Defaults to memory.json next to the server package, which is rarely what you want — set it per project.

### Client configuration

**npx with a per-project graph file**

Point MEMORY_FILE_PATH inside the project so each project keeps its own memory instead of sharing one global graph.

```
{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": { "MEMORY_FILE_PATH": "/path/to/project/.memory.json" }
    }
  }
}
```

## Frequently asked questions

### What is the memory MCP server?

It is the official reference server for persistent agent memory, published as @modelcontextprotocol/server-memory. It maintains a local knowledge graph of entities, relations and observations that survives between sessions.

### Where is the memory actually stored?

In a single JSON Lines file on your own disk, at the path you set in MEMORY_FILE_PATH. Nothing is uploaded anywhere. You can open the file, edit it, delete it or commit it to a repository.

### Why a knowledge graph instead of a vector store?

A graph gives explicit, readable relationships — "Alice works_at Acme" is a fact you can audit, not an embedding you have to trust. It also keeps recall cheap, since search_nodes is a text query rather than an embedding round trip. For semantic recall over large unstructured corpora, a vector server like Qdrant or Pinecone is the better fit.

### How does the agent know to use memory?

It mostly does not, unless you tell it. In practice you add a line to your system prompt instructing the model to search memory at the start of a conversation and record new facts as it learns them. Without that prompt the tools sit unused.

### Does the graph grow forever?

Yes, unless something prunes it. The delete_entities, delete_relations and delete_observations tools exist for that, but nothing calls them automatically. Reviewing the JSON file occasionally is the practical answer on a long-running project.

---

_Test this server across 40+ models on MCP Playground: https://mcpplaygroundonline.com/mcp-servers/memory — free, no install._