Problem it solves
Every new Claude Code session starts blank. You’ve told Claude your preferred code style a hundred times. You’ve explained your project conventions in every session. You’ve repeated “I prefer async/await over .then()” more times than you can count.
Memory MCP gives Claude persistent memory across sessions. Tell it something once — your preferences, recurring context about your project, quirks of your setup — and it remembers for every future session. You stop being a stranger to your own AI assistant.
How to install
⚠️ Package name needs verification. The command below uses
@anthropic-ai/memory-server— this package name has not been independently verified. Check the official Anthropic MCP servers repository for the current, correct package name before running.
# ⚠️ Verify package name before runningclaude mcp add memory -- npx -y @anthropic-ai/memory-serverAfter installing, restart Claude Code and confirm with /mcp. The server runs as a background process and persists a memory store between sessions.
How to use
Once installed, just tell Claude things you want it to remember:
- “Remember: I prefer TypeScript strict mode and ESLint with Airbnb rules”
- “Remember: This project uses Prisma for the database and Zod for validation”
- “Remember: I’m using pnpm, not npm or yarn”
- “Remember: Always write tests with Vitest, not Jest”
Claude stores these as memory entries. In future sessions, it recalls them automatically when relevant — you don’t have to re-explain your setup each time.
You can also ask Claude what it remembers: “What do you know about my preferences?” and it will surface the stored entries.
Pro tips
Combine with CLAUDE.md for layered context. Think of them as two different layers: CLAUDE.md holds static project rules that belong in version control and apply to everyone on the team. Memory holds your personal preferences and dynamic context that’s specific to you. CLAUDE.md for shared rules, Memory for individual preferences — they complement each other perfectly.
Update memory when things change. If your project migrates from Jest to Vitest, tell Claude: “Update your memory — we now use Vitest instead of Jest.” Memory isn’t magic; it needs to be maintained like any other context source.
Use memory for recurring debugging context. If your project has a known quirk (“The auth module has a known race condition in tests — ignore flaky failures in auth.test.ts”), storing that in memory means Claude won’t waste time investigating it every session.
When NOT to use
Don’t use memory as a substitute for a good CLAUDE.md. If a convention applies to the whole team, it belongs in version control — not in one person’s private memory store. Also be mindful that memory can become stale: if your project goes through a major architectural change, audit your stored memories and update them. Stale memory is worse than no memory, because it actively misleads.