MCP Memory Server: Put Cross-Session Memory in a Local Knowledge Graph

Who it's for

You need an AI client that "doesn't lose things between sessions": write user preferences, naming conventions, technology choices that are already settled, and records from integration testing and go-lives into structured memory, so the next conversation picks up right where you left off without restating the background by hand every time. This official Memory Server does exactly that - it lands memory as a local knowledge graph, where nodes are entities, edges are relationships, and observation entries can hang off the nodes.

The unsuitable cases are worth stating up front: its memory granularity is "decidable facts" (who, which service, what was chosen, why), not verbatim retention of whole documents; the data stays on the local machine, with no cross-project or cross-device sharing and sync mechanism; if the team has strict privacy requirements or needs centrally managed long-term archives, think through the local storage and backup strategy before rolling it out.

Your first attempt in 3 minutes

There is only one official installation path: write the following configuration into your MCP client's server configuration, let npx launch the process, and you don't need to compile the source yourself.

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-memory"]
}

After writing it into the config and saving, restart the client session once or reconnect it. The prerequisite is Node.js 24 or later on the machine; otherwise the process won't start.

For the first call, pick the pure-read one: read_graph takes no input and returns the entire graph. There are two success signals - the client receives a JSON payload containing the entities and the relationships; and a readable resource named memory://knowledge-graph appears in the resource list, with MIME type application/json and content of the same shape as read_graph. read_graph doesn't write anything, but it does read the memory already stored on the machine, so sensitive environments still call for caution. The write tools really do change the local graph, which is a side effect you can't ignore; it's better to confirm the chain works with a read-only call first before going further.

To check the complete tool list, open the official page:

https://github.com/modelcontextprotocol/servers/tree/main/src/memory

Use cases

Use case 1: verify "whether this piece of information is in memory at all". When you don't know whether a fact has already made it into the graph, search with search_nodes and pass a query string; it scans entity names, entity types, and observation content in one go, and returns the matched entities along with their relationships. If the names are already known, use open_nodes with a names array to retrieve exactly the matching nodes. Both calls are read-only and leave the graph unchanged, so they fit at the start of any conversation that needs to cite historical facts.

Use case 2: write a new conclusion into the graph and pull it back when needed. create_entities builds the nodes and add_observations appends observations to them, forming a record that can be retrieved in the next search; every creation or append emits a notifications/resources/updated for memory://knowledge-graph, and clients subscribed to that resource see the change in real time. If you write it wrong, clean up with delete_entities: pass entityNames and the entity will be cascade-deleted together with its associated relationships. If a name doesn't exist, no error is raised - the response lists which names weren't found, so you can check the deletion result item by item.

Usage boundaries

• Reads have no filter: read_graph returns the complete graph structure in one go, and as the graph gets denser the output of a single call grows with it; the safe approach is to narrow the scope with search_nodes first, then fetch the specific nodes with open_nodes.
• Deletion can't be undone: delete_entities is a cascade delete, so removing one entity takes its relationships with it; the page describes no undo, trash, or rollback step, so keep a verifiable snapshot with read_graph or search_nodes before you act.
• Notifications reach subscribers only: notifications/resources/updated is not pushed to clients that haven't subscribed to the resource, and whether you subscribed decides whether you see this change in time.
• The protocol has generational differences: the same stdio process picks the protocol based on the client's first message - one kind of client sends server/discover first and attaches the version, identity, and capabilities to the request, while another goes through the initialize handshake; the tools and resources exposed by the two generations are the same set, so one configuration is enough.
• Storage is local: the memory lives in the knowledge graph on the machine, and the server itself provides no cross-environment sync or sharing.