MnemoverseDocs

Appearance

MCP Server ​

npm versionnpm downloads per monthMCP RegistryLicense: MITGlama quality score

Give any MCP-compatible AI tool persistent memory. One config, and it never forgets again.

Current release: v0.9.1 (2026-08-24), 10 tools. The version here comes from the same registry file every Mnemoverse surface reads, refreshed automatically when a release ships.

The @mnemoverse/mcp-memory-server npm package works with any tool that supports the Model Context Protocol. Listed on the Official MCP Registry: any MCP-aware client that browses the registry will find it there.

Prefer not to manage an API key?

The hosted Remote MCP Server connects the same memory over one-click OAuth sign-in: add https://mcp.mnemoverse.com/mcp as a custom connector, no key to paste. This page covers the local npx package. Since 0.9.0 the two surfaces expose the same tool set; deletion is an administrative REST operation, not an agent tool.

Pick Your Tool ​

  • Claude Code & Claude Desktop: one command for Claude Code, JSON config for Desktop
  • Cursor: one-click install or .cursor/mcp.json
  • VS Code: keyless extension, remote OAuth, or .vscode/mcp.json
  • Windsurf: mcp_config.json (Devin Desktop)
  • ChatGPT: GPT Actions with a key, or the remote MCP connector in developer mode
  • Python SDK: pip install mnemoverse for scripts and backends

Try It ​

Your assistant may never recall what it saved unless you tell it to

Connecting adds the memory tools; it doesn't make the assistant use them. By default it answers from its own context instead of checking Mnemoverse, so recall quietly goes unused. Fix it with one line: Make Your Agent Use Memory. Writing usually needs less help: the server's own instructions tell the assistant to save durable facts, preferences and decisions proactively. But those instructions only reach the model in clients that pass them through. Where yours doesn't, the same standing instruction covers writing as well as recall.

With that in place, the point is one memory across tools, provided both tools are connected with the same MNEMOVERSE_API_KEY. Memory is scoped to the key, so two keys mean two separate memories and the demo below comes back empty.

In whichever tool you just connected:

"Remember: staging deploys go through make deploy-staging, never Railway directly."

Later, in a different tool (even days later):

"How do I deploy staging here?"

It recalls the rule, because the memory lives in Mnemoverse, not in any single tool. (A same-tool "it remembers" demo wouldn't prove much: the tool's own memory could do that; cross-tool recall is what needs Mnemoverse.)

If nothing comes back, check four things in this order. A key the server never accepted (from 0.8.4 a wrong key prints one line naming MNEMOVERSE_API_KEY on stderr at startup, so look there first). Two different keys across the two tools, which gives you two memories rather than one. A missing standing instruction (above), which leaves recall unused rather than broken. And the read itself: an unscoped read does not search shared rooms, and memory_read ranks by meaning, so ask for memory_list_recent when you want a complete recent list rather than the closest match.

If this setup saved you time, a GitHub star helps the next builder find it.

How It Works ​

Your AI tool ←stdio→ @mnemoverse/mcp-memory-server ←HTTPS→ core.mnemoverse.com

The MCP server runs locally via npx, communicates with your AI tool over stdio, and calls the Mnemoverse API over HTTPS. Your memories are stored server-side, accessible from any tool with the same API key.

Tools ​

The server exposes ten tools. Five work on your own memory, four share a memory pool across accounts, and one discovers stored secret aliases. Two delete tools were removed in 0.9.0; deletion is an administrative REST operation now, and the honest way to fix a wrong memory from an agent is to write a corrected one.

Reading and writing your own memory ​

ToolWhat it does
memory_writeStore a preference, decision, or lesson
memory_readSearch memories by natural language query, optionally newest-first (order_by) or time-bounded (since / until)
memory_list_recentList the newest memories first, no query, to catch up after a break or on a shared room
memory_feedbackReport if a memory was helpful (+1) or wrong (-1)
memory_statsCheck how many memories are stored

Shared rooms (Beta) ​

ToolWhat it does
memory_create_roomCreate a room, a memory pool shared across accounts
memory_invite_to_roomMint a shareable invite code for a room
memory_join_roomRedeem an invite code and join a room
memory_list_roomsRe-find the rooms you belong to in a fresh session

Secrets ​

ToolWhat it does
vault_listList stored secret aliases; values are never returned

See the Claude Code page for detailed parameter docs and examples for each tool.

Search versus the recent feed ​

memory_read and memory_list_recent answer different questions, and using the wrong one is the most common way to conclude the memory is empty when it is not.

memory_read is a semantic search: it answers "what do I know about X" and returns what is relevant to a query. Entries that exist but do not match the query are not returned (correctly, but invisibly).

memory_list_recent is a walk backwards through time: it answers "what happened lately" and is complete by construction. Nothing is skipped. Use it to resume after a break, to catch up on a shared room, or whenever you want to be sure you are seeing everything rather than the best matches.

Both accept the same time and authorship filters:

ParameterMeaning
sinceOnly entries created at or after this instant (your last-seen watermark)
untilOnly entries created at or before this instant; pair with since for a closed window
exclude_authorDrop entries written by one author principal; it matches the principal, not the agent name shown in results, so an agent name will silently match nothing

memory_list_recent additionally takes limit (1–100, default 20) and cursor. The feed is paged rather than truncated: when more entries exist, the response carries a cursor that continues the listing with no skips and no duplicates, so reading a thousand entries is five calls rather than one impossible one.

Shared rooms in detail ​

A room is a memory pool shared across accounts, addressed as a domain of the form xroom:<room_id>. Every memory tool that takes a domain works against a room you belong to: membership is enforced in the database, not only in the application, so a non-member cannot read a room's entries even if a bug let the request through.

The owner creates a room and mints invite codes; each code is single-use and expires. memory_list_rooms is how a fresh session re-finds the rooms you are already in.

Universal Memory ​

One API key. Every tool. Same memories.

                    ┌── Claude Code / Desktop
   Mnemoverse API ──├── Cursor / VS Code / Windsurf
   (one memory)     ├── ChatGPT (Custom Actions)
                    └── Python SDK / REST

Write a memory in Claude Code → Cursor reads it. Learn something in VS Code → ChatGPT knows it.

Configuration ​

VariableRequiredDefault
MNEMOVERSE_API_KEYYesNone
MNEMOVERSE_API_URLNohttps://core.mnemoverse.com/api/v1

MNEMOVERSE_API_URL is the REST backend the local server talks to. It is not an MCP endpoint; never paste it into a connector-URL field. A remote MCP connector uses https://mcp.mnemoverse.com/mcp (Remote MCP Server).

Get your API key at console.mnemoverse.com (free tier, no credit card).

VS Code, Cursor, Windsurf & VSCodium: skip the key, then install the Mnemoverse Memory extension and click Sign In. It connects keyless in your browser; nothing to paste.

What's New ​

v0.9.1 (August 2026) ​

  • A failed tool call now tells the agent what to do, instead of echoing the API's raw wire body. A rejected call answers in three parts — what happened, whose problem it is, and whether to retry — so the model can act on it rather than relaying "error 401" to you. A bad key, for example, names MNEMOVERSE_API_KEY and says not to retry until it is replaced. The raw body is kept underneath, so existing greps still find Mnemoverse API error <status>.
  • Feedback now re-ranks your recall for real. The read path used to apply its feedback and recency adjustments after ordering and truncation, so the advertised re-ranking never actually changed what came back. The engine now applies them before the cut (live in production since 2026-08-23), so a memory you up- or down-weight genuinely moves in the results. The flip side, stated plainly: an unhelpful memory is out-ranked, never erased — nothing decays or is deleted by age (deletion has been administrative-only since 0.9.0).

v0.9.0 (August 2026) ​

  • The two delete tools are gone. memory_delete and memory_delete_domain are removed from this package entirely: registration, handlers, schemas, and every generated surface. Deletion is withdrawn from the agent-facing surface to an administrative, REST-only operation (DELETE /memory/atoms/{id} and DELETE /memory/domain/{domain} are unaffected). Why: a delete path destroyed learned associations tenant-wide in a logged incident, and the hosted connector already excluded delete by design; this package was the last agent-facing surface still exposing it.
  • Every remaining mention of deletion now points at a corrective write. To fix a wrong or stale memory from an agent, write a fresh one with memory_write. A non-destructive primitive that marks a memory as superseding an older one is planned to replace the delete-for-update lifecycle; it does not exist yet and no date is promised.
  • Migration: integrations calling either removed tool will fail against 0.9.0. There is no compatibility shim; move deletion to the REST API.

v0.8.4 (August 2026) ​

  • A wrong API key says so at startup, where you look. Before this, a bad key still completed the handshake and listed all twelve tools, and the 401 only surfaced mid-conversation on the first real tool call: a green connection followed by silent failure. Now one read-only probe runs in the background after connect: a 401/403 prints one sentence naming MNEMOVERSE_API_KEY on stderr, network errors stay silent (flaky wifi must not cry wolf), and a valid key keeps startup quiet. Keyless startup is unchanged.
  • claude mcp add snippets carry -s user. The CLI's default scope registers the server for the current directory only, so memory installed in one repo was silently absent in the next. That's the opposite of cross-tool memory, and it was true of every snippet we had published.
  • The README stopped claiming a decay that does not happen. "Recall fades by recency" was removed: nothing about a stored memory decays over time or is deleted by age. The engine does apply an always-on recency boost, but that is a ranking nudge, not decay — its magnitude is a tuning value, not part of the contract, so the docs carry no number for it. The re-ranking wording was then finished in 0.9.1 (above) once the engine applied those adjustments before the cut (mcp-memory-server#95).

v0.8.3 (August 2026) ​

  • A refused write in a room prints the rule that applies to rooms. It used to state the personal-domain rule ("a near-duplicate is refused"), which stopped being true in shared rooms: a restatement (a briefing, a status, a decision summary) stores there, because a room is a message bus and receiving what the first agent was told is the point. Only a write the embedder cannot distinguish from one already present is refused.
  • The novelty score carries the same health warning the hosted connector carries: it is a first-generation metric and measurably unreliable.

v0.8.2 (August 2026) ​

  • Dependency security pass: all 32 open Dependabot alerts cleared (7 high, 22 medium, 3 low), every one a transitive dependency of the MCP SDK; npm audit now reports zero. Stated honestly: most never reached running code, since this is a stdio server and the HTTP stack inside the SDK is not on its path.

v0.8.1 (August 2026) ​

  • Empty answers describe their scope instead of claiming absence. An unscoped read never covers shared rooms, so "nothing found" was a claim about the world; both read tools now name the rooms that went unsearched and how to read them.
  • Relevance percentages are gone from result lines. The number read as confidence and wasn't; rank order still carries the ranking, and the percentage stays off until the engine has a dependable signal to show. Each result line now carries its domain tag instead (@"project:acme"), so same-named entries from different projects stay apart.
  • Names print exactly, or not at all. Domain and room names render as exact quoted literals: a Cyrillic name survives, a stray leading space is visible, and two different stores can no longer merge into one printed string.
  • A real test gate: the suite grew from 31 tests to 338, and CI now runs it on every push across three timezones (one fix in this release is invisible under UTC-only CI).

v0.8.0 (August 2026) ​

  • until and exclude_author on the recent feed: memory_list_recent gains the upper time bound (pair with since for a closed window) and the author-exclusion filter memory_read already had, so the two tools take the same time and authorship filters.

v0.7.0 (August 2026) ​

  • Recency controls on memory_read: order_by: "recency" for newest-first results, since / until time bounds, and exclude_author to skip a given author's entries (useful in shared rooms). Read results now show each memory's date.
  • New memory_list_recent tool, the newest memories first with no search query: resume after a break, or check a shared room for fresh entries (since watermark + cursor paging).
  • The server teaches its own use. It now ships MCP server instructions (so agents use memory proactively without prompting), and a first read on an empty store returns a short getting-started greeting instead of a bare "no results".

Full history: GitHub Releases.

Source Code ​

MIT licensed: github.com/mnemoverse/mcp-memory-server