MCP Memory Server: server-memory vs MemoryRouter
Search for a memory server to run over MCP and the same package comes up almost every time: @modelcontextprotocol/server-memory, the knowledge graph memory server in the official server collection. It sits in the Claude Desktop config examples, it keeps everything in one file on one computer, and version 1.0.0 landed on npm on October 11, 2026.
It does what it claims, and its README is candid, calling it a basic implementation in the first sentence. Both facts matter when you are deciding where your memory should live for the long haul. Here is what each one is, what it costs, and the questions that actually decide between them.
The reference server
The data model is a local knowledge graph with three parts: entities (a name, a type, a list of observations), relations between entities, and observations, meant to be one atomic fact each. Nine tools read and write it: create, extend, and delete entities, relations, and observations, plus read_graph, search_nodes, and open_nodes. One resource exposes the entire graph as JSON at memory://knowledge-graph.
Storage is a single JSONL file, memory.jsonl by default, and MEMORY_FILE_PATH moves it anywhere you like. Setup is a JSON block for Claude Desktop or one-click installs for VS Code, running over stdio through npx or Docker.
Two operational details are worth knowing. Nothing is stored unless the model calls a write tool, and nothing is recalled unless it calls a read tool, so the README ships a sample system prompt for teaching the model when to retrieve and what is worth keeping. And the file can be shared by several clients: each client starts its own process, and every write takes an exclusive lock beside the memory file while it reads, changes, and saves, so processes on the same computer take turns instead of overwriting each other. That lock depends on local filesystem behavior, which is why the README warns against sharing the file over a network filesystem.
Sources: the server's README and its npm page, read October 16, 2026.
The hosted vault
MemoryRouter runs the same category of server, remotely, at https://mcp.memoryrouter.ai/mcp. You add a URL to a client instead of a command, and sign-in happens in the browser through OAuth, so credentials stay out of config files.
The tool surface is wider. Ten tools cover semantic recall that can be narrowed by tier and importance, time-window search with continuation cursors, storing a memory, connection status, reflection and consolidation, lineage inspection, and deletion at the single-memory and whole-vault levels. Recall is relevance-ranked against the query, so it returns the memories that match instead of the whole graph.
The bigger change is what the server reads from. The reference server reads one file, wherever that file sits. The vault is hosted, and one vault serves every client you connect: Claude, Cowork, and ChatGPT conversations, Codex and Claude Code on the terminal, and any other client that speaks MCP. Save a decision in one client and every other client can read it, on whichever machine you authorized.
Setup steps per platform are on the MCP page, which also carries a checked table of the other MCP memory servers if you want the wider field. The MCP documentation has the full tool list, scope behavior, and deletion safeguards.
Who does the remembering
On the reference server, memory exists because the model wrote it, and recall happens because the model asked. That is why the README ships a sample system prompt: the retrieve and save habits are yours to define, client by client.
MemoryRouter keeps that same model-directed behavior in Claude, Cowork, and ChatGPT, where tool calls are the only mechanism. The hook-based clients go further. In OpenClaw, in Claude Code, and in Codex, lifecycle hooks run beneath the chat and capture the turn on their own. If you want writes you never had to ask for, start there. The verification pass from an earlier MCP walkthrough works against either design whenever you want to confirm the path end to end.
The case for the local file
One hard requirement settles this half of the comparison: if memory data cannot leave the machine, the reference server is built for that rule. One file, no account, no network calls, MIT licensed, and it opens in any text editor, which makes it easy to read, back up, or put under version control.
The system prompt keeps you in direct control of what gets kept, and for a personal graph of modest size, keyword search plus the full-graph read is enough.
The two things that decide it
First, how recall finds things. The reference server matches substrings across names, types, and observation text, and read_graph returns everything, which costs context as the graph grows. The vault runs a semantic search instead, ranks by relevance, and can restrict a result set by tier, an importance floor, or a date window, so the question can be phrased naturally and the answer kept small.
Second, the reach. The file model centers on one computer. Several clients can share it there, and the lock design shows how much care that sharing took to build. The vault answers on every connected client, wherever you open one. If your setup is a single computer and a single app, the file is the simpler thing to own. If your week moves between a chat window, an editor, and a terminal running overnight jobs, only the hosted vault shows up in all three.
What each one costs
The reference server costs nothing. MIT license, no account, no plan, maintained under the Model Context Protocol project.
MemoryRouter costs $20 a month once the free trial ends. 200M memory tokens are included each month, then $0.50 for each additional 1M. Your model provider keys and their billing do not change.
How to pick one
One computer, one client, and a rule that nothing leaves the machine: run the reference server and keep your prompt tuned.
One record that follows you across clients, machines, and tools, with recall that lands before you think to ask in your coding sessions: Start your vault and give every tool the same memory.