MCP로 커서에 영구 메모리를 추가하는 방법 (2026)

Cursor starts every session with amnesia: yesterday’s architecture discussion, the migration you agreed not to touch, your preference for pnpm, all gone. There are three real ways to fix that. One, use Cursor’s built-in Rules and Memories. Two, run a local-first MCP memory server such as Basic Memory, which keeps everything on your machine. Three, connect a managed memory service over MCP so the same memory follows you across tools. Disclosure up front: I’m Edward, co-founder of Mnemoverse, which is one of those managed services, so I’m biased about option three. The other two are genuinely the right choice for plenty of people, and I’ll try to show where.

Option 1: Cursor’s native Rules and Memories

Rules are instruction files Cursor loads into the model’s context. Project rules live in .cursor/rules, and there are global user rules in settings. They are memory in the “sticky note” sense: static text you write and curate by hand. That is exactly right for stable conventions. “Use pnpm.” “Tests mirror the src layout.” “Never touch the legacy billing module.” Write those once and stop repeating yourself.

Memories is Cursor’s automatic layer: the editor generates memories from your sessions so context carries forward. I have to be honest here: availability and behavior vary by version. The feature has moved around and changed between releases, so check what your build actually does before relying on it. When it is present and fits your workflow, it is the zero-setup option.

The limits are structural. Everything stays inside Cursor. Open Claude Code or VS Code and none of it comes with you. Rules do not learn from your sessions, and because Memories varies by version, what it captures is worth auditing rather than assuming.

Option 2: local-first MCP memory servers

MCP (Model Context Protocol) lets you plug external tools into Cursor’s agent, and memory servers are a natural fit. A local-first server keeps every byte on your machine.

Basic Memory is a good example: an AGPL-3.0 MCP server that stores your memories as Markdown files on disk. That design decision does a lot of work. Your memory becomes a folder you can grep, edit in any editor, back up, and version in a private repo. Nothing leaves your machine, it works offline, there is no per-query cost, and there is no vendor to trust or outlive.

The tradeoffs are equally clear. It lives on one machine unless you sync it yourself. Retrieval tends to be simpler than in hosted systems, with no learned ranking or feedback loop. And maintenance is yours. But if you operate under compliance constraints, or you simply do not want project context on anyone’s server, this option wins and it is not close.

Option 3: managed cross-tool memory (a Mnemoverse walkthrough)

This is what I build, so read this section with that bias in mind. The point of a managed service is not that it is smarter than your local setup. The point is portability plus mechanics you do not have to build yourself. All integrations reach the same account and memory, but authentication differs: the local MCP package and a Custom GPT use an API key; compatible remote MCP clients can use OAuth. That means a fact written in Cursor on Monday can be available in Claude Code on Tuesday.

Setup takes a few minutes:

Step 1. Sign up at console.mnemoverse.com. The free tier is 1,000 queries per day and 10,000 atoms, no credit card.

Step 2. Copy your API key.

Step 3. Add the server to .cursor/mcp.json in your project (or the global ~/.cursor/mcp.json):

   {
     "mcpServers": {
       "mnemoverse": {
         "command": "npx",
         "args": ["-y", "@mnemoverse/mcp-memory-server@latest"],
         "env": {
           "MNEMOVERSE_API_KEY": "mk_live_YOUR_KEY",
           "MNEMOVERSE_API_URL": "https://core.mnemoverse.com/api/v1"
         }
       }
     }
   }

Enter fullscreen mode Exit fullscreen mode

Step 4. Reload MCP servers in Cursor’s settings. The local package now exposes nine tools: six core memory tools (memory_write, memory_read, memory_feedback, memory_stats, memory_delete, memory_delete_domain) plus three Beta shared-room tools (create, invite, join). For the current Cursor configuration and tool list, use the editor setup documentation.

If you would rather not manage a key, compatible MCP clients can connect to https://mcp.mnemoverse.com/mcp and sign in through OAuth. The remote connector exposes seven tools: four core tools (write, read, feedback, stats) plus the three Beta shared-room tools. The two deletion tools remain local-package-only.

What actually happens under the hood:

• On write, each memory (we call them atoms) gets an importance score at write time, and its concepts form Hebbian associations with the concepts they co-occur with. Association strengths are tuned by a Rescorla-Wagner update, so surprising co-occurrences shift weights more than expected ones. In the background, consolidation merges similar memories into prototypes, with Von Restorff protection so a distinctive memory does not get averaged into the pile.
• On recall, memory_read returns atoms ranked using those signals: importance, the learned associations, and past feedback.
• On feedback, the agent calls memory_feedback with a score from -1 to 1 when a recalled memory helped or misled it, and that signal re-ranks future recall.

The current package behavior and tool surface are documented in the MCP server reference.

Openness, stated plainly: the MCP server and the Python SDK are MIT licensed, but the engine is hosted and not open source. Your atoms live on our servers. That is the real tradeoff against option two, and memory_delete / memory_delete_domain exist precisely so you stay in control of what is kept.

Which should you pick

If Cursor is your only tool and your needs are conventions plus light session carry-over, use the native features. It is the least machinery, and Rules in particular are underrated.

If privacy, latency, or data ownership dominates, go local-first. Basic Memory if Markdown on disk appeals to you; the pattern matters more than the specific server.

If you work across several tools, managed memory is the category to look at, and I would compare honestly within it. Mem0 offers an Apache-2.0 open-source SDK plus a managed cloud and focuses on extracting facts from conversations. Zep builds on the open-source Graphiti temporal knowledge graph, where facts carry validity windows, a real advantage if you care about what was true when. If your stack is LangGraph, LangMem is native to its Long-term Memory Store and is the path of least resistance. Cognee is the one to evaluate for a self-hosted knowledge graph. Letta gives you a whole agent framework with self-editing memory rather than a bolt-on. Supermemory leans on connectors (Notion, Google Drive, Gmail, S3) if your context lives in documents more than code. Mnemoverse’s angle is the cross-tool key plus the learning mechanics above.

On performance claims: vendor-reported numbers are contested, ours included; run your own evals on your own recall tasks before you commit.

FAQ

Does MCP memory slow Cursor down?
Every read or write is a tool call the agent chooses to make, so the cost shows up a few times per session, not per keystroke. A local server answers on localhost; a managed one adds a network hop. If that hop bothers you, that is a point for option two.

Does a memory service see my whole codebase?
No. It only receives what the agent explicitly sends through the memory tools: the memories it writes and the queries it reads with. You can inspect and delete everything: with Mnemoverse via the delete tools, with Basic Memory by deleting a Markdown file. If “only what the tools send” is still too much for your threat model, that is option two’s whole argument, and it is a fair one.

Can other tools share the memory Cursor builds?
Native Rules and Memories stay in Cursor. A local MCP server can be mounted by any MCP client on the same machine. A managed service shares across machines and tools; with Mnemoverse, the same account and memory can be reached from Claude Code, Cursor, VS Code, and ChatGPT. The authentication method depends on the client: API key for the local package and Custom GPT action, OAuth for compatible remote MCP clients.

I build one of these options, so weigh my framing accordingly. And if you try any of the three and hit something rough, tell me in the comments. I read them.