I went looking for a memory MCP server the way anyone does. Sort by stars, check the registry, read the README, pick one.
Then I opened all thirteen that actually ship, and every one of those four signals turned out to measure something other than what I thought it measured. Not one of them is a lie. Each is a real number pointing at a real thing. The problem is that the thing is rarely the server you are about to install.
Here is what each signal actually reports, with the cases where the gap is widest.
The star count often belongs to a different project
The largest number in this field is about 90,100 stars, and it belongs to claude-mem. That one is honest: the stars sit on the repository that ships the thing.
Two of the best-known entries are not.
Mem0's memory MCP server lives inside an umbrella repository carrying roughly 62,800 stars. Those stars cover the engine, the SDKs, the docs, and everything else in the monorepo. Supermemory has the same shape: about 28,800 stars on the monorepo where its MCP v2 lives, while the deprecated v1 repository sits near 1,700.
Memori is the sharpest case. Its engine has around 15,700 stars. Its MCP wrapper, the part you would actually connect to a client, has two.
None of that makes those projects worse. Mem0 and Supermemory are serious, mature systems, and Memori's engine has earned its count. But if you shortlist by star count without asking which repository the number is attached to, you have ranked engines against wrappers against monorepos and called it a comparison.
The check takes ten seconds: open the repository the install command actually points at, and read the count there.
The registry is a form, not a review
The official MCP Registry looks like a filter. It is not one. Publishing to it is self-service: a maintainer fills in a form. Nobody reviews the server, tests it, or checks that it does what the description says.
The absence side is worse. The largest project in the whole comparison, claude-mem at roughly 90,100 stars, has no registry entry at all. Neither does MemPalace at about 58,200. Meanwhile some of the smallest projects in the registry have almost no users.
So a registry entry tells you one thing: MCP-aware clients that browse the registry can find this server. That is genuinely useful, because such a client cannot find what is not listed. It is just not a quality signal, and reading it as one inverts the field.
Download counts measure the reference implementation, not the field
The most-downloaded package in this comparison is the official server-memory, at roughly 390,000 npm downloads a month. That is more than an order of magnitude above anything else here.
Its own README calls it "a basic implementation."
That is not false modesty. It stores a knowledge graph in a single local JSONL file, searches by substring, and serves one user. It is actively maintained and it is a reasonable first experiment. It is also the thing people install to try MCP memory once, which is exactly why its download number looks the way it does.
Downloads measure trial, and trial concentrates on whatever is easiest to install. Engine libraries distort the picture further: mem0ai on PyPI counts far higher than anything in this list, but it is an engine, not an MCP server, and comparing the two is comparing a library to a service.
A README is a snapshot, and sub-projects disappear
An earlier version of the comparison page behind this article pointed readers at OpenMemory as Mem0's local Docker path. That path was removed from the monorepo in July 2026. Mem0's documented MCP entry point today is a hosted server.
Nothing was hidden. The project moved, as projects do. But the sentence had been true when it was written, and it was still sitting there being read after it stopped being true.
The same failure mode is waiting in memento-mcp. Its README describes a knowledge graph with vector embeddings and temporal decay over Neo4j, and that description is accurate. What the README does not say is that the last commit to main was 10 May 2025, and npm downloads sit around 127 a month. You would be adopting abandoned code and, in this case, forking it.
Before adopting any of these, check the last commit date and whether the sub-project you are citing still exists in the repository. Both checks are faster than reading the feature list.
One of the most-searched names is not a product
Searches for a memory MCP server called "gmemory" return confident results. There is no such shipped server. The term points at G-Memory, a multi-agent memory research framework on arXiv, paper 2506.07398.
It is a paper. It is a good paper. It is not something you can connect to a client.
The nearest shipped SQL-native option is Memori, from MemoriLabs, formerly GibsonAI, and that is a different project entirely, with the engine-versus-wrapper split described above.
Free does not mean free, and free does not mean self-hosted
Most of this field converges on roughly $15 to $30 a month for a hosted tier, and several projects have no paid tier at all. Two entries break that pattern in opposite directions.
memento-mcp is listed as free and it is, in the sense that the code costs nothing. Running it requires your own Neo4j 5.13+ instance and a paid OpenAI key for embeddings. The bill exists. It is just not on the invoice you were reading.
Memori is the outlier the other way. Its first paid step is quoted from $60,000 a year, with nothing self-serve between the free open-source path and that. It is not a more expensive version of the same purchase. It is a different purchase.
The distinction worth holding: free and self-hosted are not the same property. mcp-memory-service is both, with local embeddings and no cloud bill. memento-mcp is neither, once you count what it needs to run.
The one filter that actually narrows the field
After all thirteen, the question that did the most work was not on any feature grid.
Does memory need to stay on one machine you control, or must several clients and users share one store?
That single question splits the field before any other comparison applies, because it sets the trust boundary and the operating burden. Local-first means backups, versioning, and portability become your job. Hosted means the agent's memory lives on someone else's infrastructure.
And one caution inside the local branch that took me too long to see. basic-memory connects to many client applications, Obsidian included. That is a genuine strength, and it is often read as multi-user support. It is not. It serves one user's files across many clients. "Works with many clients" and "isolates many users" are different properties, and the second one is a deployment concern in every hosted case here, never an automatic guarantee.
What I would check now instead
Four questions, all faster than reading a feature comparison:
- Which repository does the star count belong to? Open the one the install command points at.
- When was the last commit to main? Not the last release. The last commit.
- Does the sub-project in the README still exist? Search the repository for it.
- What does "free" require you to run? A database and an embeddings key are a bill.
None of that tells you which server is best. Nothing does, because the answer depends on the deployment question above. What it does is stop you shortlisting on numbers that describe something else.
The full comparison of all thirteen, with three tables and every number dated and sourced, is on the original page. One of the thirteen is ours. It is flagged as a vendor entry there and ordered first on purpose, so it can be discounted in one glance rather than quietly benefiting from the company it keeps.
Disclosure: I work on Mnemoverse, a memory engine for AI agents connected over MCP, and it is one of the thirteen servers in the comparison this article draws on. Every number above is dated and checkable on the source page. Free key: console.mnemoverse.com · Plans and limits
Top comments (3)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
This is an excellent reminder that repository stars and registry presence are weak proxies for production readiness. I would formalize your approach into an MCP adoption score based on commit velocity, release cadence, dependency freshness, maintainer concentration, issue resolution time, protocol compliance, security posture, and reproducibility.
The trust boundary is even more important for agent memory. I would evaluate storage topology, tenant isolation, encryption at rest, key ownership, retention policies, deletion guarantees, backup recovery, and whether retrieval can leak memories across agents.
I would also build a reproducible benchmark measuring retrieval precision, recall, latency, context amplification, embedding cost, and memory corruption under concurrent workloads.
Your repository versus wrapper distinction is particularly valuable. This is exactly the kind of due diligence that prevents teams from adopting impressive numbers instead of reliable infrastructure.
Would enjoy comparing MCP evaluation methodologies with you.
A composite score is the move this piece argues against, and the eight inputs are the reason. Every one of them is a public signal read at second hand, and the finding here was that public signals are what failed: the star count belonged to a different project, the registry entry turned out to be a form rather than a review, the download counter measured the reference implementation instead of the field, and the README described a state that no longer existed.
Averaging more of those does not remove the error. It hides which input carried it. One wrong signal is falsifiable by a reader in a minute. A composite of eight is not, and its failure mode is that it stays plausible: when the star count was wrong, the resulting number still looked reasonable.
The filter that actually narrowed the field was opening the repository and reading what was in it, and that does not reduce to a score.
There is a number worth building, but it grades the signals rather than the projects: how often each public signal disagrees with what opening the thing shows. Run that across a field of thirteen and you learn which proxies are worth reading at all, and the result transfers to the next field. A score built on unvalidated proxies transfers only the error.
That distinction makes sense, and I agree that aggregating unvalidated proxies can create false confidence. I would shift the model from scoring projects to measuring signal reliability itself.
A useful framework could treat each public signal as a hypothesis and periodically validate it against observable repository state. For example, compare registry metadata against installability, README claims against executable behavior, download statistics against active usage, and repository activity against actual release health.
You could then calculate precision, staleness, disagreement rate, and detection latency for each signal. That produces something much more reusable than another ranking table.
For MCP specifically, I would automate these checks in CI with reproducible installs, protocol handshake tests, dependency audits, and repository snapshots. The interesting output is not “which server wins” but “which evidence deserves trust.”
That methodology could become a valuable benchmark for evaluating developer infrastructure beyond MCP.