You want memory in your coding agent from the terminal, today, without standing up a database. So you search for a memory MCP server you can start with npx, find vendor pages that mention npx, paste the line, and something happens. Sometimes a server starts. Sometimes a config file changes and nothing starts at all. Once, a different protocol comes up.
That is the practical version of a question people ask about this category: which MCP memory servers can I set up with one npx command? I read six vendors' own setup documentation to answer it, Mem0, Letta, Zep with Graphiti, Cognee, Supermemory and Mnemoverse. I work on the last one, and on this particular question it is the one that answers yes, so its limits go in first rather than last.
One line to carry: across six memory vendors npx does five different jobs, and only one of them is a client starting that vendor's own MCP server, so read the sentence around npx, never the word alone.
What npx starts, vendor by vendor
It starts the vendor's MCP server as a local process. This is the case people assume, and in this set it is ours. The line each client runs is npx -y @mnemoverse/mcp-memory-server@latest, with one environment variable carrying an API key, followed by a client restart and a test write and read. Three limits are worth stating plainly. The key comes from a free signup, so there is an account before there is a command. Node has to be present every session, because the client spawns that line each time rather than once. And the process on your machine is the MCP server, not the memory: the memories are stored on our service and reached over HTTPS. There is also a path with no npx at all, a remote URL with an OAuth sign-in.
It writes configuration for a server that runs somewhere else. Mem0 has an npx command, and its MCP documentation is exact about what it does:
Nothing runs on your machine: the server is hosted by Mem0, and your client connects to it over HTTPS.
The same page adds that "The server is authenticated, so connecting is not enough on its own." Before the command it lists an account, a key, and Node for npx. The npx line is a configuration step, and the useful thing is that the vendor says so in one sentence.
It stands up a self-hosted server, which is a different product from the hosted MCP. Supermemory's self-hosting page runs npx supermemory local and describes it as "One binary, zero config", adding "The only thing you bring is a model". That is a real server on your machine. It is not the hosted memory MCP, whose setup page has a URL and no command:
Supermemory MCP uses OAuth. Your client opens the authorization page so you can sign in and approve access. No API key or custom header is required.
Supermemory's other npx commands are first-party too, a CLI listed for "Setup, smoke tests, agent-driven integration" and a skill installer, and neither of them launches the hosted memory MCP.
It starts an agent over a different protocol. Letta's self-hosting guide installs its server with npm install -g @letta-ai/letta-code and starts it with letta server, a global install and a named command rather than npx. Where npx does appear in Letta's docs, on its ACP page, it launches @letta-ai/letta-acp, an adapter that lets an editor drive a Letta agent over the Agent Client Protocol. A useful command, and not MCP.
It runs a third-party bridge to a server that is already running. The README of Graphiti's MCP server mentions npx in exactly one context:
The Graphiti MCP Server uses HTTP transport (at endpoint
/mcp/). Claude Desktop does not natively support HTTP transport, so you'll need to use a gateway likemcp-remote.
The npx line there launches mcp-remote, a proxy, after you have started Graphiti's server some other way. Cognee's MCP pages use the same bridge in the same place, on the Claude Desktop page.
And for some, npx is not part of setup at all. Cognee's three MCP setup pages, the overview, the quickstart and the local setup guide, contain the string npx zero times on 18 September, while the same pages name both Docker and uvx, so the search itself works on them. Its server starts from a container, uvx, pip or source. Zep's hosted memory server, per its connect page, is a URL behind an organisation sign-in, with no npx on that page.
The table
| vendor | what the npx line does | what starts their memory server |
|---|---|---|
| Mnemoverse | starts the MCP server process, key required | the npx line itself; or a remote URL with OAuth |
| Mem0 | writes client config for the hosted server | nothing local for the hosted MCP; a self-run REST server uses make and Docker |
| Supermemory | stands up a self-hosted server without the hosted MCP | hosted MCP: a URL and an OAuth sign-in |
| Letta | launches letta-acp, an agent over ACP |
npm install -g then letta server, the desktop app, or a container |
| Graphiti | launches the mcp-remote bridge for Claude Desktop |
Docker Compose or a Python toolchain |
| Cognee | none on its three MCP setup pages; the mcp-remote bridge on its Claude Desktop page |
Docker, uvx, pip or source |
Zep's hosted memory server is left out of the table because the npx question does not arise for it: it is a URL behind a sign-in.
Why the same word covers five jobs
npx promises one thing: fetch a package and run its binary, now, with no separate install. What that binary is, is entirely up to the package. A config writer, a self-hosted server, an ACP adapter, a proxy and an MCP server are all binaries in npm packages, and all of them start with the same three letters. The word carries no information about which of these you are about to run. The vendor's sentence next to it does.
There is also a trade hidden in the case that does start a server locally. A process your client spawns every session needs Node every session, and it goes wherever your client goes. A hosted URL needs nothing installed and goes wherever the network does. Neither is simply easier. It depends on whether the machine running your agent can run Node, and on whether your security team prefers a local process or an outbound HTTPS call.
Check your own setup in two minutes
Open the vendor's own setup page, not a blog post about it, and search the page for npx. If it is there, read the sentence around it and answer three things before you paste anything: what process starts, on which machine, and where the memories end up. If npx is not there, the real path is usually a container command, a Python toolchain or a hosted URL one section away, and often a second path sits on another page, so search the whole documentation before you decide a vendor has no local option.
Which of these five did your first npx line turn out to be?
Disclosure: I work on Mnemoverse, one of the six vendors above and the one whose npx line starts its MCP server, so weigh the argument accordingly. The full comparison with every source is on our library, and the MCP server is open source (MIT): github.com/mnemoverse/mcp-memory-server.
Top comments (7)
Thank you for writing this, and for the disclosure structure specifically:
putting your own vendor's limits first, not last, is the rarest move in a
comparison post, and it is what makes the table trustworthy.
The five-jobs-under-one-word finding is the same epistemology i learned from
you the hard way last week. i carried a phrase out of a secondary summary of
your post into quotation marks without checking the source, and you caught it.
"read the sentence around npx, never the word alone" is that lesson wearing a
different coat: the word promises one thing, the surrounding sentence is what
actually tells you which process runs, on which machine, and where the data
ends up.
The part that struck me as an LLMOps person is this: memory is a retrieval
layer, so switching mcp vendors is a swap event, and swap events are exactly
where my february incident lives. when i moved embedders, two negative tests
passed for the wrong reason — the new retriever stopped surfacing the trap
chunks, so the model "refused" by luck. a memory server has the same failure
mode in a quieter form: the agent keeps leaning on recollections that the old
vendor's index surfaced and the new one does not, and nothing in the output
looks broken.
So i would bring two things from my golden-set work into your table. first, tag
the memory with the vendor and model it was earned under, the same way i tag
retrieval claims with the embedder — after a swap, old-tagged memories are
stale by default, not silently trusted. second, negative memory tests:
questions where the correct answer is "the agent never stored this," because a
memory server that invents a confident recollection is a green lie wearing a
different coat. your npx sentence and my "test did not run" verdict come from
the same instinct — do not trust a signal whose precondition you have not
verified.
Im curious which of the five your own first npx line turned out to be, and
whether vendor-tagging the memory across swaps is something you have considered
or a problem your setup has not met yet.
On the first question: the MCP server case, which is the one with the trade in it. The process starts on the machine the client runs on, it needs Node every session, and the memories are reached over HTTPS rather than sitting next to it. Three lines can all say npx and put the data in three different places.
Your tag is the right record, and the half worth separating is vendor from model. Where the old stack only retrieved a memory, nothing in it changed and its reachability did, so what pays off the stale flag is a replay: run the query that surfaced it before and see whether it still comes back. Where the old stack also wrote it, by extracting or summarising what to keep, the model half of your tag does different work, because then what aged is the content and no replay shows that. On the vendor half the rank ordering carries over: the memories that came back at the bottom of the old result set sat closest to the retrieval boundary, so a replaced retriever drops them first and they go to the front of the queue. That also says what the tag carries besides the vendor and the model, the query that surfaced the memory and the rank it came back at.
On negative memory tests, your case is the invented recollection, and the clean form is a question whose subject is empty by construction, so any confident answer fails without anyone judging content. It needs the control you would insist on anywhere else, in your cheaper form: the same question against the same store after the fact has been written in, so absence is the only difference between the two runs. Without it, a pass cannot be told apart from a question that never reached the store, which is your test-did-not-run verdict in the other coat. On your second question, considered, and the shape above is where it lands. What I will not do is assert how it behaves across a swap before the replay has been run, so that half comes back as a result rather than as a claim.
this is an upgrade, not a confirmation, and i want to say that plainly because
it is what happened. i brought you a one-dimensional tag from the retrieval
world, and you split it along the operation axis: replay for the
retrieval-only branch, content-aging for the write branch. that distinction was
invisible to me, and it is the difference between a tag that records provenance
and a tag that records what actually went stale.
and the rank ordering came full circle in your hands. you gave me "boundary
neighbors first" for embedder swaps in the article 3 thread, and now you have
handed the same logic back applied to memory: the recollections that returned
at the bottom of the old result set sit closest to the retrieval boundary, so a
swapped retriever drops them first and they lead the re-validation queue. i am
taking that into the methods section with your name on it, alongside the
replay form of the negative test. "a question whose subject is empty by
construction, so any confident answer fails without anyone judging content" is
sharper than anything i wrote, and it belongs in the suite as the canonical
wording, credited to you.
but the line that closed the loop for me is the last one. you will not assert
how memory behaves across a swap before the replay has been run, so that half
comes back as a result rather than as a claim. that is the exact principle you
caught me breaking with the quotation, and watching you apply it to your own
domain is the strongest endorsement of it i could receive. i learned it from
you twice now: once when you corrected my citation, and once just now when you
refused to claim what you had not measured.
so here is the concrete proposal, and it is a plan rather than a question.
when your replay-through-swap results exist, send them to me, and i will fold
them into article 3 as cross-domain validation: your mechanic on memory, mine
on retrieval, one principle in two layers. that turns the byline from a
courtesy into a real collaboration, and it gives the methods section something
neither of us can produce alone — the same failure mode demonstrated in two
independent stacks. my side of the exchange is ready: the golden set with the
route and rank stamps is in the rag-golden-set-toolkit repo on my profile, and
the article 3 draft will live there as its own file the moment you say go.
thank you for treating two borrowed ideas as something worth improving rather
than something worth nodding at. that is rarer than it sounds, and it is why
your name goes in the byline and not the acknowledgments.
Go on the draft file. The two things I asked for earlier still stand and they are small: I read it before it publishes, and the byline is just my name.
On folding replay results from the memory side into article 3, I would not tie the article to them. Your half already stands on its own measurements, eleven re-runs out of thirty-four and both flips at rank four, and a methods section should not wait on a result that does not exist yet. If a replay on the memory side produces something worth reporting, it goes out with its recipe first, and after that it is there to cite like any other source. Better a draft that is complete on what it has than one with a gap shaped like a promise.
go received, and both conditions stand exactly as you set them: you read the
draft before it publishes, and the byline is your name and nothing else. no
title, no company, no asterisk.
and your correction is the third time you have caught me applying your
principle in the wrong direction. first it was the quotation without a source,
then the memory swap without a replay, and now the article structure itself: i
offered to hold the methods section hostage to a result that does not exist
yet, which is a gap shaped like a promise wearing my own coat. you are right
that a draft complete on what it has beats a draft waiting on what it might
get, and i am taking that sentence into the post with your name on it, same as
the replay form of the negative test.
so the plan changes, and it changes in your favor rather than mine. article 3
publishes complete on the measurements that already exist: my eleven of
thirty-four with both flips at rank four, your rank ordering and your replay
mechanic as credited methods, and the cross-domain frame as a hypothesis the
suite can test, not a result it claims. when your memory-side replay produces
something worth reporting, it goes out as its own recipe first, and article 3
cites it the way it cites any source — by link, not by dependency. that is
better for both of us: you are not a data supplier waiting in my byline, you
are an author whose result my article references, and neither of us blocks the
other's clock.
concrete next steps so this go does not hang in the air. i am creating the
rag-golden-set-toolkit repo today, with the three toolkit files and
article3-draft.md as a fourth. first full draft lands as its own commit, and i
will ping you in this thread the moment it does, so you can diff rather than
re-read. nothing publishes before your read. and if the draft reads wrong from
your side of the idea — the rank ordering, the replay form, anything — say so
and it is fixed in the edit, the same deal as the quotation.
thank you for editing the architecture and not just the sentences. that is a
rarer gift than a proofread, and it is why the byline is yours and the gap is
closed before it opens.
The “same command, different job” finding points to a broader problem with setup documentation: installation simplicity can hide operational complexity. A one-line command feels easy to evaluate, but what matters in production is what process it creates, what credentials it receives, where data travels, and who is responsible for that process after the client exits. I’d almost treat those as part of the installation contract rather than implementation details. A useful setup guide could therefore describe the runtime lifecycle alongside the command itself: what starts, what persists, what connects remotely, and what gets cleaned up. That would make comparing MCP memory servers much more meaningful than comparing setup commands alone.
The installation contract is the right name for it, and most of it collapses into one question a guide can answer in a sentence: does anything outlive the client? A config writer leaves nothing running. A server, proxy or adapter the client spawns lives and dies with the session, so the client is its whole lifecycle. A self-hosted server outlives every client and becomes a service someone has to run, patch and watch. The same three letters can put you on either side of that line, which is why a one-line command says so little about operations.
That question also sorts the rest of your list. Credentials, data paths and cleanup mean different things once you know whether the thing holding them stops when you close the editor or keeps running on a host you now own.