Codebase Memory MCP Servers Compared (2026)

Updated 2026-05-18 · 6 options reviewed

If you've ever watched Claude forget a function name three messages into a refactor, you've felt the pain. Memory MCP servers fix that by giving the agent a place to write down — and recall — facts about your repo, your team, and your project history. This guide compares the five most-starred memory MCP servers and the official reference implementation, so you can pick the one that matches your workflow.

At a glance

Server Best forStarsOfficial?Language
codebase-memory-mcp Large monorepos where the agent keeps losing track of where a symbol is defined. ★ 1,532 — C
MCP Memory Service Teams running multiple agent frameworks who want one shared memory. ★ 1,734 — Python
Memory Bank MCP Cline users juggling several projects. ★ 893 — TypeScript
Memorix Polyglots who bounce between Cursor and Claude Code mid-task. ★ 416 — TypeScript
Memory Anyone learning MCP, or who wants the most stable, spec-faithful baseline. — ✅ —
Context7 Agents that keep hallucinating outdated APIs (React, Next.js, etc.). ★ 53,600 ✅ TypeScript

In depth

codebase-memory-mcp

★ 1,532 · C · database · DeusData/codebase-memory-mcp

Install guide →

DeusData's codebase-memory-mcp indexes your code into a searchable knowledge graph the LLM can query. Designed specifically for code — symbols, imports, call sites — not just free-form notes.

PROS
  • Code-aware: understands AST structure, not just text
  • Fast incremental re-indexing on file change
  • 1.5k+ GitHub stars, actively maintained
CONS
  • Setup is heavier — runs a local index daemon
  • Code-focused: not ideal for storing meeting notes or PRDs
Best for: Large monorepos where the agent keeps losing track of where a symbol is defined.

MCP Memory Service

★ 1,734 · Python · data · doobidoo/mcp-memory-service

Install guide →

doobidoo's mcp-memory-service is a REST + MCP persistent memory layer with a knowledge-graph backend. Works with Claude, LangGraph, CrewAI, AutoGen out of the box.

PROS
  • Cross-framework — same memory, multiple clients
  • 1.7k stars, mature project
  • REST API means you can integrate with non-MCP tools too
CONS
  • Generic memory — not code-aware
  • Needs a running server process
Best for: Teams running multiple agent frameworks who want one shared memory.

Memory Bank MCP

★ 893 · TypeScript · ai · alioshr/memory-bank-mcp

Install guide →

alioshr's memory-bank-mcp is a remote, multi-project memory bank — compatible with the Cline Memory Bank format. Memory is keyed per project, perfect for switching between repos.

PROS
  • Multi-project out of the box
  • Compatible with Cline's existing Memory Bank convention
  • Lightweight
CONS
  • Requires self-hosting if you want it remote
  • No code-aware indexing
Best for: Cline users juggling several projects.

Memorix

★ 416 · TypeScript · ai · AVIDS2/memorix

Install guide →

AVIDS2's memorix is a cross-agent memory layer — share context between Claude Code, Cursor, and Cline so when you switch tools the agent doesn't start over.

PROS
  • Designed for multi-client workflows
  • Simple slug-based memory namespaces
CONS
  • Smaller community (~400 stars)
  • Newer project, expect some rough edges
Best for: Polyglots who bounce between Cursor and Claude Code mid-task.

Memory

Official · ai · modelcontextprotocol/servers

Install guide →

The official memory MCP server from Anthropic / modelcontextprotocol. A simple persistent knowledge graph — minimal, well-understood, but bare-bones.

PROS
  • Reference implementation, always up to date with the spec
  • Zero dependencies, easy to audit
  • Great starter for learning how memory MCPs work
CONS
  • No code-aware features
  • Single-project unless you wrap it
Best for: Anyone learning MCP, or who wants the most stable, spec-faithful baseline.

Context7

★ 53,600 · Official · TypeScript · devtools · upstash/context7

Install guide →

Upstash's context7 isn't strictly a memory server — it's a live docs context server that pulls up-to-date library docs into your coding agent. We're including it because most users who search for 'memory MCP' actually need *up-to-date context*, and context7 solves that better than a knowledge graph.

PROS
  • Always fresh — no stale memory to invalidate
  • 53k+ GitHub stars (huge community)
  • Works alongside any other memory MCP
CONS
  • Read-only — you can't write your own facts
  • Limited to library docs Upstash has indexed
Best for: Agents that keep hallucinating outdated APIs (React, Next.js, etc.).

Our recommendation

Most teams should install two memory servers, not one. Pair context7 for fresh library docs with codebase-memory for your own repo's symbols. If you're cross-tool (Cursor + Claude Code), add memorix on top. If you're just learning MCP, start with the official memory server — it's the cleanest implementation to read.

FAQ

Do I need a memory MCP at all?
For one-off tasks, no. For multi-session refactors, agentic workflows, or long-lived projects where the agent needs to remember decisions from yesterday — yes. Without one, every new Claude session starts from zero.
Can I run multiple memory MCPs at the same time?
Yes. Each MCP server is independent. A common stack is context7 (read-only library docs) + codebase-memory (your own code) + a generic memory server for free-form notes. Claude routes the right query to the right server.
What about Mem0 or Letta — why aren't they here?
Mem0 and Letta are excellent memory systems but they're not currently shipping MCP servers in the registry. We'll add them when official MCP wrappers land.
Will memory leak sensitive code to a third party?
All servers listed here run locally by default. context7 pulls from Upstash's public docs index (no upload). codebase-memory, memory-bank, memorix, and the official memory server keep your data on disk on your machine.