MCP memory servers and npx: one command, six different answers
Type npx into six memory-server vendors' setup docs and something different happens every time. This article checks one specific, narrow question against each vendor's own live documentation: does the npx command actually launch that vendor's own memory server, and if not, what does. Not a ranking of which install is "easiest" in the abstract. A look at how much work one three-letter command has been asked to do across a category, and what each vendor's own docs say it launches.
TL;DR
- Of six vendors checked, exactly one launches its own memory server with npx: Mnemoverse, gated by nothing but a free API key, with no separate sign-in step after the command runs.
- The other five fail that test for five different reasons. Mem0's npx command configures a hosted server rather than running one. Letta documents no npx path, but it does document a Node one: a globally installed npm CLI, with Docker as the deployment option. Zep and Graphiti's real paths are a container command or a Python toolchain, with npx only ever bridging a client that can't already speak the protocol. Cognee's three MCP setup pages never mention npx, checked by hand; where its wider docs do, it is the mcp-remote bridge or an editor plugin. Supermemory needs no command at all, only a URL and a sign-in.
- Disclosure: Mnemoverse is one of the six vendors compared, built by this site's publisher. Every fact here, ours included, is quoted from a page that vendor published, fetched the week this article was checked.
- No performance or benchmark number appears in this article, for any system, our standing benchmark freeze.
The mechanism npx is supposed to promise
Type npx and something is supposed to happen: code runs, on your machine, right now, no separate install step. That is the whole promise behind the word. It does not hold for five of the six systems checked here, each for a different, specific, checkable reason.
Mnemoverse: the one that actually runs
Ours is the one system where npx is the literal command a client spawns. Add it to Claude Code, Cursor, VS Code, Claude Desktop or Windsurf, and the line each of those clients runs is the same shape: npx -y @mnemoverse/mcp-memory-server@latest, one environment variable carrying an API key. Nothing installs first, nothing runs afterward (agent setup guide). What runs on your machine is the MCP server process; the memories themselves are stored server-side and reached over HTTPS, the same hosted shape as Mem0 below. The difference this section is about is the launch command, not where the data lives.
That key still has to come from somewhere, and this article says so plainly rather than calling the result "no setup": a free key from a signup page at console.mnemoverse.com, the same shape of prerequisite as Mem0's account requirement below, just without a separate sign-in step after the command runs. VS Code also has a second, keyless path through an editor extension with browser sign-in and no npx involved at all: a different mechanism, worth naming so this article never implies npx is the only door in.
Mem0: an npx command that configures, not runs
Mem0 has an npx command too, and this is where the word starts meaning something different. Point a client at it and the command writes local configuration; it does not start anything, in the vendor's own words:
Nothing runs on your machine: the server is hosted by Mem0, and your client connects to it over HTTPS.
And connecting alone is not the finish line:
The server is authenticated, so connecting is not enough on its own.
(mem0-mcp docs). The prerequisite list above that command names an account, a key from a dashboard, and Node itself, purely to run npx at all. One client sits outside the whole one-line story: Mem0's own docs say Claude Desktop rejects the automated command entirely and has to be added by hand through its settings instead.
Letta: a client, not a server you stand up
Letta answers the question by not really having one. Its own documentation describes what it is plainly:
MCP tools execute on external MCP servers. Unlike server tools (where the tool code runs in Letta's sandbox) or client tools (where the tool code runs in your app), MCP tools only require registering the server URL - the tool execution happens on the MCP server.
(MCP tools guide). Letta is a client that registers other people's servers, not something launched with npx to get a memory server of its own running. The one npx example on that page proves the point: it installs a completely unrelated, general-purpose filesystem tool, not anything of Letta's. Letta's own backend does have a Node path, just not an npx one: its self-hosting guide documents npm install -g @letta-ai/letta-code followed by letta server --backend local --listen, with Docker offered alongside for deployment. Checked live 2026-09-04; the package is published as @letta-ai/letta-code with a letta binary.
One more thing worth naming plainly, found checking this section rather than assumed: Letta does publish its own npm package for a memory MCP server, under its own team's maintainer names on the registry. But the package's listed README is copied wholesale from an unrelated project (the Model Context Protocol registry server), and the repository its own listing links to no longer exists. A real, published package with a mismatched README, not something this article can point a reader toward with confidence either way.
Zep and Graphiti: two products, neither launches with npx
Two products share this vendor's name, and neither one starts with npx. Graphiti, the open-source half, documents its own server starting through Docker Compose or a Python toolchain as the alternative. npx appears in exactly one place on its setup page, the Claude Desktop bridge, and only after the real server is already running, bridging a client limitation rather than launching anything:
Claude Desktop does not natively support HTTP transport, so you'll need to use a gateway like mcp-remote.
(Graphiti MCP server README). Zep's own hosted product, separately, has no run command at all: add one URL, sign in through an organization's identity provider, done (Zep memory MCP server). Zep also runs a second server under the same name, a documentation search tool for coding agents rather than a memory server, its own separate URL, no key required at all (Zep docs MCP server); the same word carries a third meaning inside one vendor's own documentation.
Cognee: zero occurrences, checked by hand
Cognee's documentation for its memory server spans three separate pages: an overview, a quickstart, and a local setup guide. Searched for the string npx across every one of them, the count comes back at zero.
The site's own menu names three real paths instead, worth naming correctly rather than compressed into one line, since the page itself keeps them as three separate cards:
Docker Quickstart. Recommended for most users. Get running in minutes with a pre-built container.
API Mode (Shared). For teams.
Local Setup. For development. Build from source for full control and latest features.
(Cognee MCP overview). A container, a shared backend, or building from source with a Python toolchain. None of the three is npx, and no fourth option is hiding in the text. There is a reason for that, checkable independently: Cognee's memory server is a real, published PyPI package, but the npm registry (the one npx actually reads from) returns nothing under its name. There is no npm package here to run with npx in the first place.
Supermemory: a URL, not a command
Supermemory's memory server has the shortest setup instruction of the six, and it isn't a command at all:
Add the remote server to your MCP client.
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 MCP setup). One npx line does appear in Supermemory's docs search, and naming what it actually is matters: it belongs to a separate product, a documentation-search tool for coding agents, explicitly distinguished on its own page from the consumer memory server. A second, different npx command, npx supermemory local, self-hosts Supermemory's own API on your infrastructure, and that mode's comparison table marks the memory server itself unavailable in it. Neither npx string launches the thing this article is checking.
The table
| vendor | does npx run their own memory server? | what actually does |
|---|---|---|
| Mnemoverse | yes | nothing else needed; one API key |
| Mem0 | no | npx configures a hosted server; sign-in happens after |
| Letta | no | a globally installed npm CLI (letta server), or Docker; the one npx example on its docs installs an unrelated tool |
| Zep / Graphiti | no | Docker Compose or a Python toolchain; npx only bridges an already-running server |
| Cognee | no | Docker or a Python toolchain; zero npx mentions across three docs pages |
| Supermemory | no | a URL and OAuth sign-in; no run command of any kind |
Check your own setup
Checking this yourself takes less time than this article did to write. Open the vendor's own setup page and search the page itself for npx, not a blog post about the vendor. If it appears, read the sentence around it before typing anything: does that command start a server, or write configuration for one running somewhere else. If it doesn't appear at all, the real path is sitting one section away, usually a container command or a language-specific toolchain, and no amount of searching will turn up a fourth option the vendor never documented.
Every vendor fact here was fetched live 2026-09-03 with full browser headers, re-checked two days after an initial research pass to confirm nothing had drifted. Mnemoverse's own facts fetched the same day from its agent setup guide. No performance or benchmark number appears in this article, for any system, pending a completed clean benchmark run of our own.