MEMORY_FILE_PATH memory MCP

Not specified by the original author.

TL;DR

Memories vanish between sessions when MEMORY_FILE_PATH is unset, relative, or different per client: each launch then writes to a different file (or a temp default). Set MEMORY_FILE_PATH to one absolute, writable path in every client's MCP config. All sessions then share the same knowledge graph file.

The error

Error: Changes not saved across sessions

Fix it

1. Check what path each client is actually using. Look at the env block of the memory entry in every MCP config (Claude Desktop, Claude Code, Cursor each have their own).

   • Expected: you find either no MEMORY_FILE_PATH or different values per client.

2. Set one absolute path everywhere:

   {
     "mcpServers": {
       "memory": {
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-memory"],
         "env": { "MEMORY_FILE_PATH": "[HOME]/..." }
       }
     }
   }

   • Expected: identical absolute path in every client config.

3. Make sure the file is writable (touch it once as your user), then create a test entity and restart the client.

   • Expected: the entity is still there after restart.

When to use

• Entities created in one session are missing in the next.
• Different clients (Desktop vs Code) seem to have different memories.

When NOT to use

• Duplicate entities piling up - that is a naming/search_nodes discipline problem.
• memory.json over 10MB and slow - that is bloat, prune it.
• Server will not start at all - check npx and the install first.

Compatibility

• @modelcontextprotocol/server-memory, all clients.

Root cause

The server persists the knowledge graph to the JSONL file at MEMORY_FILE_PATH. Without the variable it falls back to a default location that varies by working directory, so two clients (or two launches) silently use two different files. A relative path has the same effect because the server's working directory differs per client.

Edge cases

• Do not point the file inside a synced folder with aggressive conflict handling unless you enjoy resolving JSONL merge conflicts.
• Keep secrets out of the file: it is plain text on disk and outlives the session.
• Back the file up before pruning; there is no undo for delete_entities.

Memory MCP troubleshooting guides list the top issue as Memory Not Persisting with the documented fix: check that MEMORYFILEPATH is correctly set, ensure write permissions for the file, and verify the file is not corrupted. One guide gives the exact client command that sets it: claude mcp add with -e MEMORYFILEPATH pointing at an absolute path.

Not specified by the original author.

TL;DR: The SQLite MCP server cannot find your database because the --db-path you gave it is relative, and the server resolves it against its own working directory, not yours. Pass an absolute path to the database file in your client config and the error goes away.

Error: unable to open database file

Fix it

1. Replace the relative path with an absolute one in your MCP client config:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "[HOME]/..."]
    }
  }
}

On Windows use the full drive path, e.g. C:[HOME]/....

2. Fully quit and restart the MCP client so the server respawns with the new argument.

   Expected: the server starts and tools like read_query list your tables. No open error in the logs.

3. If it still fails, check the parent directory exists. SQLite cannot create missing parent directories, only the file itself:

ls -la [HOME]/...

When to use this

• The database file exists and opens fine in the sqlite3 CLI, but the MCP server says it cannot open it.
• You used a relative path, ~, or an env-var-style path in --db-path.

When NOT to use this

• The error is no such table. The file opened fine; you are pointing at the wrong (probably auto-created empty) database.
• The error is database is locked. That is a concurrency problem, not a path problem.

Compatibility

• @modelcontextprotocol/server-sqlite (takes --db-path).
• Claude Desktop, Claude Code, Cursor, Windsurf.

Why it happens

GUI MCP clients launch the server as a child process with an unpredictable working directory (often the app bundle or system root). A relative --db-path like data/app.db resolves against that directory, not your project. SQLite then fails to open it because the parent directory does not exist there. Absolute paths remove the ambiguity entirely.

Edge cases

• ~ is not expanded by the server. Write out [HOME]/... (or C:[HOME]/...) in full.
• Paths with spaces work if quoted correctly in JSON. The JSON string quoting handles it; do not add shell quotes inside the arg.
• If the parent directory is missing, create it first. The server will create the .db file itself if it does not exist.

The statcan-mcp-server project (Aryan-Jhaveri/mcp-statcan) lists this as an active known issue in its README: Unable to open database file on Claude Desktop, with the workaround to pass --db-path with a full absolute path. This is the same failure mode as the official @modelcontextprotocol/server-sqlite, which takes --db-path as its argument and resolves it relative to the server process working directory, which under a GUI MCP client is not the user's shell directory. Source: https://github.com/aryan-jhaveri/mcp-statcan

Not specified by the original author.

TL;DR

Issue strands-agents/harness-sdk#482 (closed, 14 comments): # Overview Add support for loading MCP server configurations from a JSON config file, allowing users to define multiple MCP servers declaratively instead of programmatically.

Steps

1. Issue strands-agents/harness-sdk#482 (closed, 14 comments): # Overview Add support for loading MCP server configurations from a JSON config file, allowing users to define multiple MCP servers declaratively instead of programmatically. This extends the existing experimental agent_config.py to support an mcp_servers field that creates and manages MCPClient instances automatically. Note: Multiple MCP servers and automatic lifecycle management already work programmatically (see tests_integ/mcp/test_mcp_tool_provider.py::test_mcp_client_multiple_servers). This feature request is specifically about configuration file support.
2. [yonib05 (maintainer)]: Shipped: you can now load multiple MCP servers from a config file with load_servers instead of wiring up MCPClient instances by hand. It is in both SDKs (Python PR #3053, TypeScript PR #2947). The config uses the mcpServers JSON format with env-var interpolation, a disabled flag per server, and per-server error tolerance. Docs: mount the host path https at container path //strandsagents.com/latest/documentation/docs/user-guide/concepts/tools/mcp-tools/

When to use

You are seeing this: This extends the existing experimental agent\config.py to support an mcp\servers field that creates and manages MCPClient instances automatically. Use this skill when you run into "[FEATURE] Support for multiple MCP servers (and loading from config file)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Note: Multiple MCP servers and automatic lifecycle management already work programmatically (see tests\integ/mcp/test\mcp\tool\provider.py::test\mcp\client\multiple\servers).

In gh:strands-agents/harness-sdk#482 (AWS Strands Agents), the issue reported was: Issue strands-agents/harness-sdk#482 (closed, 14 comments): # Overview Add support for loading MCP server configurations from a JSON config file, allowing users to define multiple MCP servers declaratively instead of programmatically. This extends the existing experimental agent_config.py to support an mcp_servers field that creates and manages MCPClient instances automatically. Note: Multiple MCP servers and automatic lifecycle management already work programmatically (see tests_integ/mcp/test_mcp_tool_provider.py::test_mcp_client_multiple_servers). This feature request is specifically about configuration file support. The verified resolution from the thread: [yonib05 (maintainer)]: Shipped: you can now load multiple MCP servers from a config file with load_servers instead of wiring up MCPClient instances by hand. It is in both SDKs (Python PR #3053, TypeScript PR #2947). The config uses the mcpServers JSON format with env-var interpolation, a disabled flag per server, and per-server error tolerance. Docs: mount the host path https at container path //strandsagents.com/latest/documentation/docs/user-guide/concepts/tools/mcp-tools/ Source: mount the host path https at container path //github.com/strands-agents/harness-sdk/issues/482