How to Give Claude Desktop Persistent Memory with MCP (2026 Guide)

Can you give Claude Desktop persistent memory? Yes, with an MCP server

The short answer is yes. Claude Desktop has no long-term memory of its own — every conversation starts from a blank slate — but the Model Context Protocol (MCP) lets you attach one. You run a small memory server on your own machine, add a few lines to Claude Desktop's configuration file, and from then on Claude can store facts during a conversation and recall them in the next one, days or weeks later, in a brand-new session. Nothing about the model changes; you are giving it a tool it can read from and write to.

There are three practical routes to Claude Desktop persistent memory, and they suit different people. Choosing well matters more than the setup itself, so it is worth being honest about which one fits you before you touch a config file.

• The official reference memory server. Anthropic publishes an open-source memory server that stores a small knowledge graph in a single JSON file on your laptop. It is the fastest way to get personal, single-machine memory working, and it costs nothing. It fits an individual who wants Claude to remember personal facts and preferences and is comfortable editing a configuration file.
• Developer memory platforms. Products such as mem0 and Zep are memory APIs you wire into agents you are building yourself. They are the right choice for developers shipping their own AI features who need managed recall, scoring and summarisation. They are less relevant if your goal is simply to make the Claude Desktop app in front of you remember your context.
• A full company knowledge base behind MCP. A local-first knowledge base such as Fleece AI Brain makes "memory" mean your actual company knowledge — Slack threads, Gmail, Drive documents, Notion pages, tickets, code — rather than a handful of notes you typed by hand. This is the route we recommend for teams, because the memory is current, shared, and queryable by every AI tool at once, not just by one seat.

This guide walks through all three with the concrete setup for each. It is the practical companion to our deeper piece on shared memory for AI agents with MCP, which covers the architecture and the case for a graph; here we stay close to the keyboard and focus on Claude Desktop specifically.

Why Claude forgets between conversations

To fix the amnesia it helps to understand where it comes from, because the cause tells you which fix is real and which is a workaround. Large language models are stateless. The model itself does not remember anything between calls; it reads whatever is in front of it and produces a response, and then that state is gone. What looks like "memory" inside any chat app is simply the transcript being fed back into the model on each turn — the conversation is replayed into the prompt so the model appears to recall what you said earlier.

That trick works within a session and collapses at its edge. When you start a new conversation in Claude Desktop, the previous transcript is not replayed, so the context is gone. Everything you established — your stack, your naming conventions, the decision you explained yesterday — has to be re-established from scratch. The context window is the size of the note the model can read at once, and a bigger window does not solve this. A one-million-token window still forgets the moment the session ends, and you still have to choose, by hand, what to paste back in. The limitation is architectural, not a matter of window size.

Persistent memory means moving the remembered facts out of the disposable transcript and into a durable store that survives every session — and giving the model a way to reach that store on demand. That is exactly what MCP provides. The Model Context Protocol is an open standard that lets any AI client — Claude Desktop, Cursor, Cline, Zed, your own agents — connect to external tools and data through one common interface. A memory server is just an MCP server that exposes two kinds of tool: one to write a fact down, and one to search for facts later. Claude Desktop discovers those tools when it starts, and from then on it can decide to store or recall memories the same way it decides to run any other tool. The store lives on disk, so it outlasts the chat that created it.

Option 1: the reference memory MCP server

The simplest way to give Claude Desktop persistent memory is Anthropic's own reference implementation. It ships in the public Model Context Protocol servers repository and is designed to be run with a single command, no build step required.

What it does: it maintains a small knowledge graph — entities, relations and observations — and persists it to a single JSON file on your machine. When you tell Claude something worth keeping ("I prefer TypeScript over JavaScript", "my co-founder is named Alex", "we deploy on Fridays"), Claude can write it as an entity or an observation. In a later session, when the topic comes up, Claude searches that graph and reads the relevant nodes back. It is a genuine, working long-term memory for one person on one computer.

To enable it, you add the server to Claude Desktop's configuration file. On macOS that file lives at ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows it is at %APPDATA%\Claude\claude_desktop_config.json. Add a memory entry under mcpServers:

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

Save the file and restart Claude Desktop. The npx -y invocation fetches and runs the package on demand, so there is nothing to install ahead of time beyond Node.js. Once Claude restarts, it will list the memory tools among its available tools, and you can prompt it to "remember" and "recall" facts explicitly, or add a line to your preferences asking it to store durable facts automatically.

Be clear-eyed about the scope, because the honest limits are the whole reason the other two options exist:

• It is personal and single-machine. The JSON file lives on one laptop. There is no sync, no sharing, and no notion of a team. The memory you build on your work machine is not on your home machine.
• It stores what you tell it, not what your company knows. The graph only contains facts that passed through a conversation. It has no awareness of your Slack, your documents, your tickets or your codebase unless you type those facts in one by one.
• It is a flat JSON file. That is a virtue for simplicity and a limit for scale and audit. It is a fine notebook for one person; it is not an organisation's source of truth.

For an individual who wants Claude to stop forgetting their preferences, this is an excellent, zero-cost starting point, and we recommend it for exactly that. If your goal is for Claude to know things about your company, keep reading.

Option 2: developer memory platforms

The second route is aimed at a different reader: someone building their own AI product, not someone configuring the Claude Desktop app for personal use. Platforms such as mem0 and Zep provide memory as a service — an API your agent calls to write memories, retrieve relevant ones, and in some cases score, decay or summarise them over time. They handle the retrieval logic and the storage so you do not have to build a memory layer from first principles.

The trade you are making is where the memory lives and who runs it. These are developer platforms, so the memory sits in their infrastructure — a hosted API you send data to — or in a self-hosted deployment you stand up and maintain yourself. Both are legitimate; both mean the memory is something you integrate through code rather than something Claude Desktop reaches natively. Some of these tools expose an MCP surface, but the centre of gravity is the API and the SDK, meant to be embedded inside an application you are writing.

Choose this route if you are shipping agents to your own users and need a managed recall system with clear controls over retention and scoring. It is the wrong tool if you simply want the Claude Desktop app to remember your context and, especially, if you want that memory to be your company's real knowledge rather than a store your application writes to. For that, the memory needs to be fed by the systems your company already uses — which is the third route.

Option 3 (recommended): a company brain behind MCP

The first two routes make Claude remember facts you feed it. The third makes Claude remember your company. This is the option we recommend for teams, and it is the product we build.

Fleece AI Brain is a local-first desktop application — for macOS, Windows and Linux — that turns your organisation's scattered knowledge into a single memory that any MCP client can query. Instead of a JSON file you fill in by hand, the memory is populated by twenty connectors that sync your real systems: Slack, Gmail, Google Drive, Notion, GitHub, Jira, Zendesk, Linear, Salesforce, Microsoft 365 and more. Every message, document, page and ticket becomes a node in a knowledge graph that Claude Desktop reads through MCP. When you ask Claude about "the billing migration", it does not guess — it recalls the decision, the thread it was made in, the doc it superseded and the person who owns it.

Three properties make this different from a notebook and from a doc store:

• Local-first and inspectable. The vault is plain Markdown plus a local SQLite index, fully Obsidian-compatible. It is your files on your disk. You can open, read and edit the same memory Claude queries — no opaque blob, no cloud lock-in. This is also why a brain is not the same thing as a wiki: unlike a Notion workspace, which is a place humans read documents, a brain is memory that agents query, with the structure and provenance that makes recall trustworthy.
• Private by architecture. The connectors authorise over OAuth, then pull data from each provider's API directly onto your machine. The raw payloads — your Slack messages, your emails, your ticket bodies — never transit our servers. The memory is assembled locally, which is what makes it safe to point a powerful model at it.
• Shared, not siloed. On the Teams plan the same brain becomes your organisational memory — one source of truth that every teammate's Claude, and every other AI tool, reads from. What one person's agent learns, the whole team's agents inherit.

Under the hood, the app runs a small MCP server on stdio that registers a set of memory tools — Claude calls brain_recall to search the graph and brain_remember to write a durable fact — alongside tools to read, list, connect and traverse nodes. Because it speaks standard MCP, the same brain works for Cursor, Cline and Zed too, not just Claude Desktop. One memory, every tool.

Setting it up, step by step

1. Install the desktop app. Download Fleece AI Brain for macOS, Windows or Linux and open it. It runs entirely on your machine; there is a 14-day trial, no card required, so you can build a real brain before deciding anything.
2. Open a vault. Point the app at a folder to hold your memory, or import an existing Obsidian or Markdown vault. Everything is stored as plain Markdown files plus a local SQLite index — the files are yours and stay readable outside the app.
3. Connect your tools. From the connectors screen, authorise the systems you want in memory — start with Slack, Gmail and Notion. Each connector runs an OAuth flow and then syncs that provider's data directly to your device, deduplicated and kept current, never routed through our infrastructure.
4. Connect Claude Desktop. The app generates the exact MCP configuration block for your vault. Copy it once into Claude Desktop's claude_desktop_config.json and restart the app. This is the single copy-paste step — you are not hand-writing JSON or hunting for a binary path.
5. Ask. Start a new conversation and ask Claude something only your company knows: "What did we decide about the pricing exception for enterprise refunds?" Claude calls brain_recall, retrieves the relevant nodes from your graph, and answers with the source cited — across sessions, without you pasting anything in.

From that point on, Claude Desktop has persistent memory that is not just durable but meaningful: it is your company's knowledge, kept current by the connectors, inspectable in Markdown, and shared with your team if you want it to be.

Testing that memory actually works

Whichever route you pick, verify the memory survives a session boundary before you trust it. The failure you are checking for is subtle: a tool can look connected and still not persist anything, or persist to a store nobody reads. A short, deliberate test settles it.

1. Write a fact, then quit. In one conversation, tell Claude something specific and unusual — "Remember that our staging database is called orion-staging and only Priya can restart it." Confirm it acknowledges storing it, then fully quit Claude Desktop, not just close the window.
2. Reopen and ask cold. Relaunch, start a new conversation, and ask without any hints: "Who can restart our staging database, and what is it called?" Genuine persistent memory returns orion-staging and Priya. If Claude asks you to remind it, the memory is not wired up.
3. Cross the topic, not just the transcript. Ask something adjacent that requires the model to retrieve rather than echo: "Is there anything I should know before restarting staging?" A working memory surfaces the Priya constraint unprompted, which proves recall is doing real retrieval, not replaying your last message.
4. For a company brain, test source-grounding. Ask a question whose answer lives in a connected tool, not in anything you typed — "Summarise the last decision in the #billing channel about refunds" — and confirm the answer cites the underlying thread. That confirms the connectors, the graph and MCP are all in the loop, not just a local scratchpad.
5. Test the next day. The real proof of persistence is time. Repeat one recall prompt tomorrow. Memory that holds across a restart usually holds across a week; if it does not, you are looking at session context, not a durable store.

If all five pass, Claude Desktop is genuinely remembering. If the cold-start recall fails, re-check that the server appears in Claude's tool list after a restart — that is almost always where the wiring breaks.

The verdict: which route should you use?

All three give Claude Desktop persistent memory over MCP; they differ in what the memory is and who it serves. For a single person who wants Claude to remember personal preferences, the reference server is the right, free starting point. For developers embedding memory into their own agents, mem0 or Zep are built for that job. For a team that wants Claude — and every other AI tool — to know what the company actually knows, a local company brain is the route we recommend, because it makes memory an organisational asset rather than a per-seat notebook.

If a company brain is the fit, pricing is straightforward: Solo is €12 per month for up to three connectors, Pro is €24 per month for unlimited connectors, and Teams is €49 per user per month for the shared organisational brain. Every plan starts with a 14-day trial, no card required. You can download the app and build a working memory in an afternoon, or sign in to connect your first tools. Whichever route you choose, the principle is the same one worth taking away: Claude is not the bottleneck — its forgetting is, and MCP is how you fix it.