Memory MCP setup: verify storage across restarts
Configure Memory MCP with a dedicated JSONL file. Write a test note, read it after restart and remove it: setup and a reproducible persistence check.
A note is persistently stored only if you can retrieve it after a complete restart. Plan more than one successful write operation. Use invented test data and a dedicated storage file during setup. This makes each step repeatable and allows precise cleanup afterwards. The goal of this guide is a reproducible check of writing, reading again and removing one known test object without involving your existing project notes.
Define the storage task and project boundary
The reference package @modelcontextprotocol/server-memory organizes entities, observations and directed relations in a local knowledge graph. Storing arbitrary text files is a different task; see the Filesystem guide for that route. Use the memory directory and Memory search to compare declared properties across implementations.
| Check | Your decision | Expected result |
|---|---|---|
| Test object | Unique invented name | Can be retrieved precisely later |
| Storage | New file in a test directory | Existing notes remain separate |
| Lifecycle | Write, restart, read, delete | Each state recorded independently |
Configure an explicit storage file
The example uses mcpServers and selects a JSONL file through MEMORY_FILE_PATH. Replace the sample path with an absolute path on the machine running the server process. Create its parent test directory beforehand. The client overview explains configuration formats; a path on your desktop is not automatically available inside a container.
{
"mcpServers": {
"memory": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-memory"
],
"env": {
"MEMORY_FILE_PATH": "/absolute/path/mcp-test/memory.jsonl"
}
}
}
}
On Windows, use a suitable absolute Windows path and escape backslashes in JSON. Also check how your client launches processes; the provider documents cmd /c for npx there. Inspect the file with the configuration checker before the first run. Record the package release actually used, so a later attempt can repeat the same setup rather than silently testing a different release.
Prove writing, restarting and reading separately
Choose a unique test name such as
project_probe_20261001and an invented observation such as “Label colour is green”. Check that the name does not already exist.Create the test object with the available write operation. Retrieve it through the available read operation and compare its exact content.
Fully stop the server process. Start it again with the same configuration and request your specific test name once more.
Remove only the test object you created. Repeat retrieval after another restart and record that the test content no longer appears.
Read current input schemas from the tool list rather than guessing names or arguments from an old example. Keep the responses from all four phases separate. An answer in an already open conversation is not independent evidence that the content came from the restarted storage instance. Explicitly request a new tool operation and inspect its actual result. Your record should make the distinction visible to someone who did not watch the attempt.
Investigate missing notes and mixed project data
If the note disappears after restart, first compare the effective file path, process user and file permissions. Check that the same server definition really started. Choose another test file for a second project and confirm that its retrieval does not find the original test name. This is a concrete countercheck of your chosen separation, not a general claim about support for multiple users or simultaneous access.
Before changing package versions, back up the test file while the process is stopped and repeat the complete lifecycle afterwards. For a handover, provide a sanitized configuration with a placeholder path and the recorded outcomes. The update guide adds further checks. A successful attempt applies to the documented environment; it does not establish the same behavior for other storage locations or concurrent writers.
- Does a successful write prove persistence?
- Retrieval after a complete restart tests the persistent storage path described here.
- Should I use real project data?
- Start with an invented object in a new test file. That makes comparison and targeted cleanup straightforward.
- Why can I see another project’s notes?
- Compare the effective storage paths and server definitions. Two differently named clients may still use the same file.
- Does tracevero store the test note?
- No. You run this check with your chosen server and its storage. tracevero provides the guide and registry information.
Provider documentation checked on 1 October 2026. The test plans and examples are editorial suggestions.
- MCP: Memory reference server
Show retrieval command
curl -s https://github.com/modelcontextprotocol/servers/tree/main/src/memory