Memory MCP Server Setup for Cursor IDE (2026)

What does the Memory MCP server do? It gives Cursor a persistent knowledge graph — entities, relationships between them, and short text observations attached to each — stored as a local JSON file instead of living only inside one chat's context window. Install @modelcontextprotocol/server-memory, point MEMORY_FILE_PATH at an absolute path you control, restart Cursor, and the AI can save facts in one session and recall them in the next.

This is one of Anthropic's original reference servers, alongside Sequential Thinking and Fetch — no API key, no third-party account, just a Node process and a file on disk.

The Problem It Solves

Every new Cursor conversation starts blank. You re-explain that your team uses feature-branch naming like eng/TICKET-123-slug, that the staging database is on Neon and production is on RDS, that you prefer functional components over classes — over and over, every session, forever. The Memory server exists to stop that specific kind of repetition by giving the AI somewhere to write facts down and somewhere to look them up later.

It is not a vector database and it does not do semantic search. It's closer to a small graph database: named entities ("Backend API", "Sarah Chen", "Staging DB") connected by typed relations ("deployed_to", "reports_to", "uses"), each entity carrying a list of plain-text observations. search_nodes matches on keyword/substring against those observations and names — ask it something phrased very differently from how the fact was stored, and it can miss, because there's no embedding model involved.

Prerequisites

Step 1: Choose Where the Memory File Lives

This is the step most setup guides skip, and it's the one that actually matters. If you don't set MEMORY_FILE_PATH explicitly, the server defaults to a memory.json file relative to wherever npx happened to extract the package — which, on a fresh npx -y run, can be a different temp-cached location than last time. Your "persistent" memory quietly resets. Always set an explicit absolute path.

mkdir -p ~/.cursor-memory

Step 2: Add the Server to Cursor's MCP Config

Open ~/.cursor/mcp.json and add:

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

Use the full, absolute path — ~ doesn't reliably expand inside an env block depending on how Cursor spawns the process. On Windows, something like C:\\Users\\you\\.cursor-memory\\memory.json.

Restart Cursor completely (quit, not just reload) and check Settings → MCP for a green "memory" entry.

Step 3: Verify It Persists

In one Cursor conversation:

Remember that this project's staging database is Neon Postgres, 
production is on AWS RDS, and we deploy via a GitHub Actions 
workflow that requires two approvals.

Close that conversation entirely and start a new one. Ask:

What do you remember about how we deploy this project?

If the second conversation answers correctly without you re-explaining anything, the file is being read and written across sessions, not just held in one chat's context.

What the Tools Actually Do

| Tool | What it does |
|------|---------------|
| create_entities | Adds new named entities (with a type and initial observations) to the graph |
| create_relations | Links two existing entities with a typed, directional relationship |
| add_observations | Appends new facts to an existing entity without recreating it |
| delete_entities | Removes an entity and any relations pointing to or from it |
| delete_observations | Removes specific facts from an entity while keeping the entity itself |
| delete_relations | Removes a specific relationship between two entities |
| read_graph | Returns the entire graph — useful for a "what do you actually have stored" sanity check |
| search_nodes | Keyword/substring search across entity names, types, and observation text |
| open_nodes | Retrieves specific named entities and their direct relations by name |

The AI decides on its own when to call create_entities vs add_observations based on your phrasing — it's usually right, but if the graph starts looking duplicated (two entities for "the same" thing with slightly different names), ask it to read_graph and consolidate.

Practical Workflows

Persisting project conventions once

Remember these conventions for this project: TypeScript strict mode, 
Zod for all runtime validation, Vitest for tests (not Jest), and PRs 
must reference a Linear ticket ID in the title.

Every future session in this repo can pull those facts back without a project README summary pasted into every chat.

Tracking a person across conversations

Remember that Priya Nair is the backend lead, she owns the 
payments service, and she prefers async standups posted in Slack 
rather than live meetings.

Weeks later: "Who should review a payments-service PR, and how should I loop them in?" — the AI answers from stored relations, not a fresh guess.

Auditing what's actually stored

Show me the full memory graph — every entity and relation you have 
stored for this project.

This calls read_graph directly. Worth doing periodically; memory files accumulate stale facts (an old staging URL, a team member who left) that nothing automatically expires.

Scoping memory per project

Run separate memory entries with different MEMORY_FILE_PATH values per project-level .cursor/mcp.json if you don't want facts about Project A bleeding into Project B's context. A single global memory file works fine for personal preferences; it gets messy fast for anything project-specific across multiple repos.

What This Doesn't Do

Troubleshooting

Memory doesn't persist between sessions
Almost always a missing or relative MEMORY_FILE_PATH. Set an absolute path explicitly — don't rely on the default.

"ENOENT" or permission errors on startup
The directory in MEMORY_FILE_PATH needs to exist before the server starts; it creates the JSON file but not its parent folder. Run mkdir -p on the directory first.

The AI "remembers" things incorrectly or contradicts itself
Ask it to read_graph and show you the raw contents. Stale or duplicate entities are common after months of use — periodically ask the AI to clean up duplicates or delete outdated observations.

Server shows connected but nothing gets saved
Check that you're not running two different memory entries (e.g., one global in ~/.cursor/mcp.json and one project-level in .cursor/mcp.json) pointing at different files — Cursor may be talking to a different instance than the one you're inspecting on disk.

Frequently Asked Questions

Q: Does the Memory server send my data anywhere?
A: No. It's a local process reading and writing a JSON file on your own machine. There's no network call in the reference implementation — everything stays on disk where you put it.

Q: Can I edit the memory.json file by hand?
A: Yes, it's plain JSON — you can inspect or hand-edit it directly with any text editor. Restart the MCP server (or restart Cursor) after manual edits so it re-reads the file rather than overwriting your changes with its in-memory state.

Q: How is this different from just pasting a project README into every chat?
A: A README is static and you have to remember to paste it. Memory is queried and updated by the AI itself mid-conversation — it can add a new fact ("we switched from Jest to Vitest last week") without you editing any file, and every future session picks that up automatically.

Q: Will the memory file grow forever and slow things down?
A: It can accumulate cruft over months of heavy use, but it's plain JSON parsed into memory on server start — even a few thousand entities and relations is a small file by modern standards. If it does get unwieldy, ask the AI to read_graph, review it, and delete stale entities.

Q: Can multiple team members share the same memory file?
A: Technically yes if you point everyone's MEMORY_FILE_PATH at a shared, synced location, but there's no built-in conflict resolution — concurrent writes from multiple people's Cursor sessions can race. It works better as a personal or single-machine tool than a team-shared database.

Related Guides

---