# supermemory-mcp puts one hosted memory store behind every MCP client

> supermemory-mcp is a Cloudflare Worker that gives MCP clients one memory store on the Supermemory API. The catch sits inside the repository: there is no package to pin, no command to copy, and the README hands the next version to a hosted page.

**supermemoryai/supermemory-mcp** — Your memories are in ChatGPT... But nowhere else. Universal Memory MCP makes your memories available to every single LLM. No logins or paywall. One command to set it up.

- Repository: https://github.com/supermemoryai/supermemory-mcp
- Website: https://mcp.supermemory.ai
- Stars: 1,730 · Forks: 171
- Language: TypeScript
- License: MIT
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/supermemoryai-supermemory-mcp

## Your memories are in one assistant, the setup command is nowhere

Your memories are in ChatGPT and nowhere else, which is the gap this server closes: one memory store behind any MCP client, so a fact captured in one assistant is available in another. The project summary line promises "One command to set it up." Getting Started then sends you to app.supermemory.ai and tells you to follow the instructions on the page, and no command appears anywhere in the file. Nothing about that page is mirrored into the repository, so the documented setup path is a web page you cannot read from here. What the repository does carry is a one-click `.dxt` install link, a demo video, and a blog post on the UX and technicalities of MCP servers. Those three items give the shape of the thing away: a hosted service, a packaged bundle, and a README whose headline promise is not fulfilled inside the README.

## Self-hosting moves the endpoint, not the stored memories

Self-hosting here means carrying somebody else's API key. To self host, get an API key at console.supermemory.ai, then add it in the `.env` file. Exactly one setting is documented, and the whole configuration surface is one line:

```bash
SUPERMEMORY_API_KEY=
```

No database URL, no vector store option and no embedding model choice appear anywhere in the file. That is the part worth settling before you adopt this: self-hosting the server places the MCP endpoint on your Cloudflare account, while the memories stay behind the Supermemory API, so every query your client makes still leaves your network. A `.gitignore` sits in the top-level listing, and nothing in the repository states which paths that file covers. If your requirement is a memory store that never contacts supermemory.ai, this project does not offer it, and the README says nothing about offline mode, a local index or any way to inspect what the API has kept.

## A Cloudflare Worker that also serves a React front end

The top-level entries describe a Cloudflare Workers application rather than a small server package: `wrangler.jsonc`, `workers/`, `tsconfig.cloudflare.json` and `worker-configuration.d.ts`, plus dev dependencies on `@cloudflare/vite-plugin` and `@cloudflare/workers-types`. An `app/` directory next to `react-router` and `react-dom` means the deployed artifact also serves a web interface, built on React 19.1.0 and react-router 7.5.0, with hono 4.7.6 underneath the HTTP layer. Wrangler 4.11.1 ships it and TypeScript 5.8.3 checks it. The scripts show how the pieces move:

```json
"dev": "react-router dev",
"build": "react-router build",
"deploy": "bun run build && wrangler deploy",
"preview": "bun run build && vite preview",
"typecheck": "wrangler types && react-router typegen && tsc -b"
```

Those five lines show a split toolchain. Ordinary development runs through the react-router CLI, while `deploy` and `preview` shell out to bun before reaching `wrangler deploy` or `vite preview`. Type checking begins by regenerating Cloudflare types with `wrangler types`. No lockfile of any kind appears in that listing, so a fresh clone resolves every caret range in `package.json` on whatever runtime you install, and two of these scripts quietly assume bun rather than node.

## A placeholder package name leaves no version to pin

Nobody filled in the local package identity. In `package.json` the name is `@repo/mcp`, the package is marked private, and the version is the placeholder default:

```json
"name": "@repo/mcp",
"private": true,
"version": "0.0.0",
```

That combination has a practical consequence for anyone wiring this into a client. Setup normally pins a published package version or a released artifact, and here neither exists, so there is nothing stable to write into your own configuration. `"type": "module"` confirms the code targets an ES module runtime, which suits the Workers target and tells a consumer nothing. Come back to this setup in six months and you rebuild it from a README plus a deployment you made yourself, because 0.0.0 is not a version to return to.

## Two validators, two loggers, two rate limiters, one manifest

Nineteen direct dependencies sit in `package.json`, and the manifest is the only account of what runs inside the server. Several entries go unexplained, and pairs sit side by side: a validation library next to `@valibot/to-json-schema` for schema conversion, `pino` next to `winston` for logging, `hono-rate-limiter` next to `@hono-rate-limiter/cloudflare` for request limits.

```json
"@hono-rate-limiter/cloudflare": "^0.2.2",
"@valibot/to-json-schema": "^1.0.0",
"@supermemory/sdk": "^0.1.0-alpha.8",
"supermemory": "^3.0.0-alpha.14",
"muppet": "^0.2.1",
```

Two things in that block reward a second look. The JSON Schema converter is a direct dependency while no `valibot` package sits beside it, so the schema library it converts for arrives from outside this manifest. Both first-party clients are pre-release, at `^0.1.0-alpha.8` and `^3.0.0-alpha.14`, and a caret range on a pre-release still leaves the patch free to move. `muppet` appears with no word of explanation, and effect 3.14.8 sits alongside the validation libraries, so at least three schema-shaped packages are installed at once. Nobody has written down which one covers what.

## No login holds for the hosted page, not for your own worker

Two claims in the features list stop holding the moment you read the self-hosting section. The project advertises no login required and free use, then asks you to obtain an API key from console.supermemory.ai before the server can answer anything. Read together, the two statements describe two products: a hosted page where a visitor gets access without an account, and a self-run worker that authenticates against the vendor. Nothing in the file prices the hosted tier or explains what happens when free access ends, so that second claim has no detail behind it.

The failure mode is concrete enough to plan around. The worker cannot answer a single query without a valid key, and no behaviour is described for a missing, expired or throttled one. That matters because the manifest imports two rate limiter packages, so limiting exists somewhere in the request path while no limit value and no error response are described. The same silence covers stored content: no retention window, no delete endpoint, no export.

## A .dxt bundle instead of a cloned repository

Concretely, the alternative to cloning is the bundle the README calls one click install with `.dxt`, downloaded from `mcp-dxt.dxt`. Both paths differ in more than convenience. The bundle is offered as a single download with no account step attached to it, and the `SUPERMEMORY_API_KEY=` line appears only in the self-hosting section. The clone gives you source, a wrangler pipeline and a key of your own, which is the only route to reading what the server does with a query before that query leaves your machine. Take the clone when you intend to audit or change the behaviour, and the bundle when you only want stored memories to appear in a client.

Neither route is documented to the end. The bundle is an asset URL with no instructions beside it, and the clone path stops at the single `.env` line, so the questions that matter next, which transports it speaks and how a stored memory comes back, are unanswered here. The blog post at `https://supermemory.ai/blog/the-ux-and-technicalities-of-awesome-mcps` is the only tutorial the README links.

## Two destinations for the next version, on two branch names

The top of the README carries a warning that changes how the rest of it reads. It says MCP v1 is being deprecated, sends users to app.supermemory.ai for the latest version, and states that while this repository is maintained and still active, the code will be maintained in a moonorepo at `apps/mcp`. Two destinations serve that one project: a hosted app for people who want to use it, a monorepo path for people who want to change it. Anything you learn from this source tree describes the line the project has announced it is leaving.

The repository carries an MIT licence, has no GitHub releases, and its last push was on 2026-10-02. A branch detail sharpens that picture: this repository builds on `master` while the monorepo path it points to uses `main`, so a fork started from the wrong branch finds nothing. Key management is not the real upgrade cost, since it stays one line of configuration, and re-reading code that the project says will live in a different repository is.

## Conclusion

Pick this server when you want one memory store reachable from any MCP client and you are content to hold a vendor key. Leave it alone when the requirement is a local database, an offline client or a version you can pin: the local package name is `@repo/mcp` at version 0.0.0, nothing is published to install from, and the README hands the next version to app.supermemory.ai. Before wiring it into a client, check what a key from console.supermemory.ai allows the service to keep and what happens when that key lapses.

## FAQ

### Do I need a supermemory account to use supermemory-mcp?

For the hosted route the README lists no login required and free use, and setup begins on app.supermemory.ai. Self-hosting asks for an API key from console.supermemory.ai placed in the `.env` file.

### How do I self-host supermemory-mcp?

Get an API key at console.supermemory.ai, put it in the `.env` file as `SUPERMEMORY_API_KEY=`, then deploy the worker. The package script `deploy` runs `bun run build && wrangler deploy`, so a Cloudflare account and the bun runtime are needed.

### Is there a published npm package for supermemory-mcp?

Nothing published is described. The local manifest names the package `@repo/mcp`, marks it private and leaves the version at 0.0.0, so a client is pointed at the hosted app or at the `.dxt` bundle instead of a package version.

### Does supermemory-mcp keep memories on my own machine?

The README documents no local storage, no local index and no offline mode. Self-hosting covers the server, and the key in the `.env` file points at the Supermemory API, so queries still leave your network.

### Where is the current version of supermemory-mcp kept?

The warning at the top of the README says MCP v1 is being deprecated and sends users to app.supermemory.ai, while code maintenance moves to the monorepo directory `apps/mcp`. This repository holds the v1 line.

## Sources

- [Issues](https://github.com/supermemoryai/supermemory-mcp/issues)
- [License: MIT](https://github.com/supermemoryai/supermemory-mcp/blob/master/LICENSE)
- [Project website](https://mcp.supermemory.ai)
- [README](https://github.com/supermemoryai/supermemory-mcp/blob/master/README.md)
- [supermemoryai/supermemory-mcp on GitHub](https://github.com/supermemoryai/supermemory-mcp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/supermemoryai-supermemory-mcp