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 (1)
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.