Claude Memory MCP: Give Claude Readable Memory Across Sessions

Claude can reason brilliantly about a repository and still forget the decision that mattered when the next session starts. A Claude memory MCP server fixes the persistence boundary: Claude calls external tools to store, search, and update knowledge outside its context window.

The consequential choice is the storage behind those tools. For durable engineering knowledge, your agent's memory should often be files you can read, edit, diff, and self-host—not only embeddings in a black-box retrieval service. Meshnote exposes linked markdown wikis through MCP, so Claude and other compatible agents can share memory without making one model vendor the system of record.

What the top Claude memory MCP results cover

The current top three results are practical but narrow. LobeHub's Claude Memory Setup Guide catalogs a local knowledge-graph server backed by SQLite. It covers Desktop configuration, the @modelcontextprotocol/server-memory package, entities, relations, observations, backup, and basic “favorite color” verification.

A February 2026 DEV article introduces MemCP. It focuses on saving before /compact, reminders, separate insight and large-context storage, graph links, progressive search, file chunking, and archival. Its benchmarks are author-reported rather than an independent comparison, but its lifecycle insight is sound: storage is useless if the agent never writes before context disappears.

The related GitHub guide goes deeper on sharing a local database between Claude Desktop and Claude Code, with Windows, macOS, and Linux paths plus troubleshooting. What these three pages do not provide is a remote, authenticated setup paired with a cross-session acceptance test and a memory-maintenance contract. That is the missing production layer this guide adds.

How Claude memory over MCP actually works

MCP separates four concerns that are easy to conflate:

The host—Claude Code or another client—connects to servers and exposes their tools to the model.
The policy tells Claude when to recall, write, revise, or delete memory.
The server implements operations such as search, page reads, writes, and history.
The store determines whether knowledge is markdown, vectors, a graph, or a hybrid.

MCP provides interoperability; it does not decide what deserves to become memory. Put stable decisions, constraints, runbooks, vocabulary, and source-backed facts in long-term memory. Leave speculative debugging ideas, credentials, raw logs, and easily regenerated output in the session or their original systems.

If you need more protocol detail first, read the MCP memory server architecture guide. For the broader coding workflow, see Claude Code persistent memory.

Working setup: connect Claude Code to Meshnote

Create an API key in your Meshnote account, then run the official Claude Code MCP command below in Bash or zsh. Replace the placeholder locally; do not commit the token.

export MESHNOTE_API_KEY='mnk_replace_with_your_key'
claude mcp add --transport http meshnote https://meshnote.io/mcp \
  --scope user \
  --header "Authorization: Bearer $MESHNOTE_API_KEY"

claude mcp list

Claude Code's current MCP documentation defines --transport http, --scope user, and --header for authenticated remote servers. User scope makes the connection available across projects. The command stores the expanded bearer value in your user configuration, so protect that file and rotate the key if it is exposed. If the server is not connected, open Claude Code and run /mcp to inspect authentication and connection status.

Meshnote tools operate on a project slug or ID. In Claude Code, ask:

Use Meshnote to list my projects. In project acme-api, read the
schema and index, then summarize only the current deployment rules.
Do not write anything yet.

This first read proves connectivity without mutating memory. Then save one falsifiable fact:

In Meshnote project acme-api, update the deployment runbook to state:
"Production migrations run before the service restart." Include today's
date and note that this came from the repository deployment script.
Preserve any non-conflicting existing content.

Start syncing — $8/mo.

The cross-session acceptance test most setups skip

Do not accept “tools connected” as proof that memory works. Use this five-step test:

Write a unique, non-sensitive fact with a source and date.
Ask Claude to read the page back and quote the exact stored statement.
End Claude Code completely, then start a new session in another directory.
Ask a neutral question—“What is the production migration order for acme-api?”—without repeating the answer.
Ask Claude to identify the memory page and source, then correct the statement and confirm the old version can be recovered from page history.

This tests persistence, retrieval, provenance, update behavior, and recovery. A favorite-color demo tests only storage. For teams that need full infrastructure ownership, the self-hosted agent memory guide covers tenant boundaries, backups, and restore drills.

Claude memory options: honest trade-offs

Option	Best at	Trade-off
Claude native memory / project instructions	Low-friction personal preferences and Claude-specific context	Convenient, but tied to Claude's product surfaces and less suitable as a shared, agent-agnostic knowledge system
Mem0	Extracting compact memories and semantic retrieval across application conversations	Strong SDK and managed workflow; the canonical memory is not naturally a human-curated markdown wiki
Zep / Graphiti	Temporal facts, entity relationships, and graph-based context assembly	Powerful when “what was true when?” matters, with more graph infrastructure and modeling than many code teams need
Letta	Stateful agents that actively manage memory blocks as part of their runtime	A coherent agent architecture, but adopting the runtime is a larger decision than attaching an external knowledge store
Readable markdown over MCP	Decisions, runbooks, research, and shared knowledge humans must audit	Easy to inspect and version; weaker than vector or graph systems for fuzzy recall across huge, unstructured conversation archives

These approaches can coexist. Use native memory for personal preferences, semantic retrieval for high-volume conversational traces, a temporal graph for changing relationships, and readable pages for knowledge that carries operational consequences.

A maintenance contract for reliable memory

Add a short policy to CLAUDE.md so memory behavior is repeatable:

At session start, read the project memory index and search for the task.
Write only durable decisions, constraints, runbooks, and sourced findings.
Before writing, search for an existing page; update instead of duplicating.
Record source and date. Never store secrets or unverified guesses as facts.
Before session end, summarize material changes and link related pages.

Then review memory like code. Give pages clear owners, distinguish current rules from historical notes, check links, and periodically delete or archive stale knowledge. Readable files make this governance possible; semantic systems still need analogous retention and correction controls even when their implementation is hidden.

Choose based on failure mode

If the dangerous failure is missing a vaguely related past conversation, prioritize semantic recall. If it is misunderstanding how entities changed over time, prioritize a temporal graph. If it is an agent silently following an obsolete deployment rule, prioritize readable, reviewable memory with history and provenance.

Claude memory via MCP is valuable because it lets you change the storage architecture without changing the agent interface. Meshnote uses that boundary to keep the durable layer in markdown and make it available across tools. Self-hosted teams can choose Self-hosted for teams from $10/seat/month.