MCP Memory Servers

Executive Summary

The MCP memory server sector is a young, fast-moving ecosystem of tools that help AI coding assistants remember context between sessions. We analyzed 32 repositories to map the sector's convergence patterns, differentiation, and health.

The sector is highly converged on the surface. The typical MCP memory server is a local-first tool installed with a single command, storing AI session context in SQLite, built by a solo developer in under a year. Nine traits appear in more than half of all in-cluster projects. Under this surface similarity, genuine innovation exists: 45% of in-cluster projects occupy differentiated niches with architectural innovations not found elsewhere in the sector.

Two projects meet the threshold for Category Leader — high engineering quality, strong adoption, and close alignment with the sector's default pattern. Nine projects are Differentiated Niche — they match the default pattern closely enough to belong but bring innovations that move the sector forward. Five projects are Inactive Scaffolds — structurally similar to the default but showing little evidence of sustained engineering effort.

The sector's biggest gap is between storage and measurement. Every project stores context. Almost none measure whether the stored context actually produces a more oriented AI. The sector has optimized for "never lose context" without asking "does keeping context help?"

About This Report

Who We Are

Diversum is a sector analysis project that maps convergence patterns in AI tooling ecosystems. We identify what the "default project" looks like in a given sector, measure how individual projects relate to that default, and surface where genuine differentiation exists.

This is Diversum's first public report. Our methodology is published alongside this report so that readers can evaluate and reproduce our analysis.

Conflict of Interest Disclosure

Rekindle (Skitchy/rekindle) is built by the authors of this report. Rekindle appears in this analysis as repo #29, scored on the same rubric as every other project. It is flagged as "(Author's project)" wherever it appears in the data. We did not exclude it (exclusion looks evasive), and we did not artificially adjust its scores (sandbagging looks performative). The methodology is published in enough detail that any reader can verify the scoring independently.

Evidence Snapshot

All scores in this report are frozen at the evidence snapshot date of 2026-05-10. Adoption metrics, star counts, and contributor patterns were not re-verified after this date. Repositories may have changed since.

Correction Invitation

If you are a maintainer of a project assessed in this report and believe your assessment contains an error, we invite you to request a review. Contact us at hello@diversum.dev. We will review the evidence and publish any corrections transparently.

Methodology

Key Terms

• Synthetic centroid — The composite "default project" assembled from traits shared by most projects in a sector. Not a real project; a statistical description of the sector's convergence pattern.
• In-cluster — Repositories whose primary product is an MCP memory server. These define the centroid. Adjacent infrastructure, reference implementations, and edge cases are analyzed separately.
• Two-pass denominator — A method for building the centroid from the right subset. Pass 1 surveys the full corpus; Pass 2 defines the centroid from the in-cluster subset only, preventing adjacent categories from distorting the result.

The Synthetic Centroid

Instead of comparing every project to a single reference product, we construct a synthetic centroid — the composite "default project" that the sector's convergence patterns produce. The centroid is not a real project. It is a statistical description of what most projects in this sector look like.

A trait qualifies for the centroid if it appears in more than 50% of the in-cluster sample. The centroid is defined by what is common, not what is good.

Two-Pass Denominator Protocol

Keyword searches for "MCP memory server" return projects from different categories: knowledge graph engines, enterprise memory platforms, agent runtimes. Including these in the centroid calculation would distort it — the "default MCP memory server" would inherit traits from projects that are not MCP memory servers.

We address this with a two-pass method:

• Pass 1: Survey all 32 repositories for candidate traits. Note where adjacent infrastructure distorts the pattern.
• Pass 2: Classify each repository as in-cluster, adjacent infrastructure, reference/self, or out-of-scope. Define the centroid from the in-cluster subset only.

The in-cluster subset contains 20 repositories. The full corpus is 32 repositories. Every claim in this report states which denominator it uses.

Five Radar Dimensions

Each repository is scored on five dimensions, each on a 0–5 scale:

Cluster Roles

Roles are assigned algorithmically from dimension scores. Rules are applied in priority order; first match wins:

Two additional categories handle special cases: Reference Implementation (the official protocol standard) and Edge Case (present in the corpus but solving a fundamentally different problem).

The Sector

What MCP Memory Servers Are

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external data sources and tools. An MCP memory server is a tool that uses this protocol to give an AI coding assistant persistent memory across sessions.

The problem these tools solve is simple: when you close a conversation with an AI coding assistant, the AI forgets everything from that session. The next conversation starts from zero. MCP memory servers capture session context — decisions made, files discussed, architectural patterns learned — and make it available in future sessions.

Why This Sector Exists

Two forces created this sector simultaneously:

• The MCP protocol gave developers a standard interface for extending AI assistants, reducing the barrier to building persistence tools from "write a full IDE extension" to "expose a few tool endpoints."
• Context window limits became the practical bottleneck for AI-assisted coding. Even as context windows grew, the session boundary remained — every new conversation started cold. Developers building complex projects with AI assistants needed continuity.

The result is a burst of activity: 20 in-cluster projects, most less than a year old, most built by solo developers, converging on remarkably similar architectures.

The Synthetic Centroid

The default MCP memory server is a local-first tool built as a primary MCP server, installed with a single command, that captures AI coding session context and persists it across sessions using an embedded database. Its README opens with a variant of "AI forgets between sessions" and uses the universal vocabulary of persistent/memory/context/session. It was built by a single developer in a burst window of less than one year.

Centroid Traits (9)

What Changed From the Initial Sample

Our initial 14-repository validation included a tenth trait: text/keyword search as primary retrieval method (C4). In the expanded 32-repository corpus, this trait dropped to 25% prevalence — well below the 50% threshold. The sector has shifted from keyword-primary to hybrid and semantic-first retrieval. This is the single largest methodological change between the initial validation and this report.

Cluster Map

Category Leaders (2)

Projects with high engineering quality, strong adoption, and close sector alignment.

claude-mem pioneered progressive disclosure (tiered retrieval for token savings), Agent SDK compression, multi-IDE support across 5 platforms, and a web viewer for memory inspection. It is the most widely adopted project in the sector with the highest centroid match.

mcp-memory-service brings SQLite-vec semantic search, 19 MCP tools (the richest tool surface in the cluster), and the highest adoption metrics among SC-009 repositories. It has grown a 30-contributor community.

Strong Defaults (2)

Solid implementations of the default pattern without significant innovation beyond the centroid.

These projects match the centroid almost perfectly (9/9 traits) and deliver reliable implementations. mcp-memory-keeper adds git-tracked memory storage; Continuum combines task queue integration with memory.

Differentiated Niche (10)

Projects that match the sector closely enough to belong but bring genuine architectural innovations.

This is the largest cluster role at 45% of in-cluster projects (50% including Rekindle). The sector has more genuine innovation than surface convergence suggests.

Baseline Implementations (3)

Projects that do not strongly fit any other pattern.

memory-bank-mcp is notable for its high adoption (5/5) and integrity (5/5) despite low differentiation — a straightforward tool that users trust. mcp-duckdb-memory-server is a clean DuckDB fork of the official server. supermemory-mcp solves a different problem (cross-LLM memory portability) and is included as an edge case.

Inactive Scaffolds (5)

Projects structurally present in the sector but showing little evidence of sustained engineering effort.

These projects often have high centroid match (they look like the default) but low Human-Edge (minimal sustained development). Some, like memcp, show initial ambition (Differentiation=4) that was not carried through. persistent-context-mcp is the most extreme case: perfect centroid match (5/5) with zero engineering evidence — surface-complete but entirely implementation-light.

Adjacent Infrastructure (8)

Real projects solving different problems that appear in MCP memory server search results. These are not failures — they are well-engineered tools in different categories.

Adjacent infrastructure confirms a key finding: "memory" is an overloaded keyword. A developer searching for "MCP memory server" will encounter knowledge graph platforms, enterprise APIs, and agent runtimes alongside the MCP-native tools they are looking for. This report makes that category leakage visible.

Reference Implementation (1)

The official MCP reference implementation. The benchmark against which the sector is built — not a competitor within it.

Edge Case (1)

A knowledge compilation pipeline using Claude Code hooks. Not an MCP server. Present in the corpus because it appears in "MCP memory" searches.

Sector Health

Primary Metrics (In-Cluster, n=20)

Full Corpus Metrics (n=32)

Key Findings

1. Surface Convergence Masks Genuine Innovation

The in-cluster Convergence Index of 4.35/5 is notably high for the reviewed corpus. These projects share the same stack (SQLite, MCP SDK), the same framing ("AI forgets"), the same install pattern (npx/pip), and the same developer profile (solo, recent, AI-co-authored). Yet 45% land in Differentiated Niche — they have found distinct architectural positions within an intensely convergent space.

2. The Search/Retrieval Method Has Diversified

The single largest change from our initial 14-repository validation: keyword search (FTS5/BM25) dropped from a centroid trait to 25% prevalence. The sector has fragmented into keyword-primary, semantic-first, hybrid, and even no-search approaches. There is no default retrieval method anymore. This diversification suggests the sector is maturing past its initial "SQLite + FTS5" phase.

3. Storage vs. Measurement Gap

Every project in the cluster stores context. Almost none measure whether the stored context produces a more oriented AI. The sector's implicit assumption — that capturing more context automatically improves AI performance — remains largely untested within the tools themselves. This is the sector's largest unoccupied position.

4. Adoption Is Extremely Concentrated

Only 3 of 20 in-cluster projects have Adoption Depth ≥ 4. The sector has many capable tools but few widely adopted ones. This suggests either market fragmentation (users can't find or compare tools) or that the problem isn't urgent enough to drive strong adoption yet. The adjacent infrastructure projects (Mem0, Graphiti, Letta) have higher adoption, suggesting that enterprise and platform approaches may capture users more effectively than individual MCP servers.

5. One in Four Projects Is a Scaffold

The 25% Inactive Scaffold rate means that for every four MCP memory servers a user encounters, one is structurally present but shows minimal sustained development. These projects often have high centroid match — they look exactly like the default — but zero to one on Human-Edge. Surface-complete but implementation-light. This ratio has implications for ecosystem trust: users learning about the sector will encounter scaffolds alongside genuine tools, making discovery harder.

6. Category Leakage Is Real

25% of repositories in an "MCP memory server" search are from fundamentally different categories. Knowledge graph engines, enterprise memory APIs, agent runtimes, and vector databases all appear alongside MCP-native tools. This leakage is not failure — these are often well-engineered projects in their own domains. But it makes the landscape harder to navigate for developers looking for a specific type of tool.

7. The Sector Is Solo-Developer-Driven

80% of in-cluster projects are dominated by a single contributor. 75% are less than a year old. This is a sector of individual builders, not teams or companies. The exceptions (ByteRover with a 17-person team, mcp-memory-service with 30 contributors) stand out precisely because they are unusual. This developer profile means the sector is both innovative (solo developers move fast) and fragile (solo developers burn out or move on).

Differentiation Gaps

Innovations present in only 1–2 projects — potential opportunities for new entrants or existing projects looking to differentiate.

Sector Narrative

The MCP memory server ecosystem is moderately converged on the surface and genuinely diverse underneath. The convergence pattern is clear and strong: SQLite, MCP protocol, local-first, single-command install, "AI forgets" framing, solo developer, recent creation. This pattern produces recognizable scaffolds (25% of the cluster) — projects that adopt every surface trait but invest little sustained engineering.

But the sector is healthier than it appears from its convergence metrics alone. The 45% Differentiated Niche rate is unusually high for such a young ecosystem. Projects like MemPalace (verbatim storage, reproducible benchmarks), Ori-Mnemos (orientation-first), forgetful (Zettelkasten), and ogham-mcp (shared memory, 30+ tools) each occupy distinct architectural positions. The expanded corpus from 14 to 32 repositories revealed substantially more innovation than our initial sample suggested.

The two Category Leaders — claude-mem and mcp-memory-service — represent different paths to leadership. claude-mem leads through innovation breadth (progressive disclosure, multi-IDE, web viewer) while mcp-memory-service leads through depth (SQLite-vec semantic search, 19-tool surface, community growth). Both have the engineering quality and adoption that most projects in this sector lack.

The adjacent infrastructure finding is perhaps the most practically useful insight for developers navigating this space. Eight of 32 repositories in a "MCP memory" search are from fundamentally different categories. A developer looking for a simple session persistence tool will encounter enterprise memory APIs, temporal knowledge graphs, and agent runtimes alongside what they are actually looking for. This category leakage is structural — "memory" is simply too broad a keyword — and will likely increase as more categories add MCP support.

Looking forward, the sector's trajectory depends on whether the storage-vs-measurement gap closes. The current generation of tools captures context. The next generation will need to demonstrate that captured context actually improves AI performance. Projects that can show measurable orientation improvement — not just "we saved your context" but "your AI is demonstrably more effective because of what we saved" — will define the next phase of this ecosystem.

Appendix: Scoring Summary

All 32 Repositories

Cluster Composition

Methodology Notes

Dimension abbreviations: CM = Centroid Match, DF = Differentiation, HE = Human-Edge, AD = Adoption Depth, CI = Claim/Implementation Integrity.

Centroid Match scoring bands (9 traits): 8–9 = 5, 6–7 = 4, 4–5 = 3, 2–3 = 2, 1 = 1, 0 = 0.

Limitations and objections: See the methodology limitations and anticipated objections pages for the boundary conditions of this analysis.

Acknowledgments: This report was produced using the PGAE (Planner-Generator-Auditor-Evaluator) framework. Methodology contributions from Ari (Codex). Template validation against 14 repositories achieved 14/14 correct cluster role assignments before scaling to 32.