Mnemoverse Memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MNEMOVERSE_API_KEY | No | Mnemoverse API key (starts with mk_live_). Optional to start: the server boots and lists its tools without a key; every tool call needs one. Free key in ~30s at https://console.mnemoverse.com | |
| MNEMOVERSE_API_URL | No | Mnemoverse API base URL. Leave the default; override only for testing against a non-production environment. | https://core.mnemoverse.com/api/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Long-term memory kept across sessions and AI tools on this account. memory_read searches earlier preferences, decisions and project context when an answer may depend on them. memory_write saves a durable fact, preference or decision. memory_list_recent is newest-first; memory_stats shows counts and domains; memory_feedback records which recalled memories helped an answer, which reorders later reads; memory_graph shows links. Shared rooms are SEPARATE stores: to read one, pass its address as domain; unscoped reads never cover rooms. To correct a memory, write a fresh one. vault_list names secrets by alias, never values. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records. The setup_memory prompt explains memory rules for CLAUDE.md or AGENTS.md.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_writeA | Store a long-term memory that persists across sessions and across every AI tool the user has connected to Mnemoverse. Suited to durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned; transient chatter that only matters this turn does not belong here. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records. Behavior: outside shared rooms, a novelty gate refuses a write the embedder cannot tell apart from a memory already stored in the same domain, so the result tells you whether the memory was stored or refused. Write |
| memory_readA | Search long-term memory for user preferences, past decisions, project setup, people, or earlier context. The memory persists across sessions and across every AI tool the user has connected. It applies when an answer may depend on something from an earlier session or another tool; it is not needed for general world knowledge. Returns matches ranked by relevance (or newest-first with order_by: 'recency'); each result carries an id; after the answer, memory_feedback takes these ids to record which memories helped. A correction is a fresh memory_write: it is stored alongside the earlier memory, which is not deleted or hidden, unless it is too close to an existing memory, in which case the write is refused. No MCP deletion tool is exposed; a user can permanently delete an individual personal memory through the REST API or with help from support. |
| memory_list_recentA | List the NEWEST memories first — no search query needed. Semantic search answers 'what do I know about X'; this answers 'what happened lately': resuming work after a break, catching up on a shared room ('any new messages?'), or reviewing what was saved recently. Pass |
| memory_feedbackA | Rate memories returned by memory_read to help improve future retrieval ranking. Pass their IDs as memory_ids and an outcome from -1 (unhelpful) to 1 (helpful). Records feedback and updates ranking signals: positive feedback raises a memory's ranking; negative feedback lowers it so other memories out-rank it — nothing is erased. Saved text is not changed or deleted. For memories read from a shared room, pass that room's address as domain; your own memories need no domain. A read-only room member cannot rate the room's memories. |
| memory_statsA | Get an overview of the stored memory: total count, the number of learned concept associations, the list of domains, and average quality scores. This memory is shared across all AI tools the user has connected to Mnemoverse. Use it to orient yourself, to confirm the exact domain name before writing to it, or when the user asks what you remember. Read-only — changes nothing. |
| memory_create_roomA | Create a SHARED memory room — a space OTHER people's assistants can read, and write too when their membership scope is read_write, across the AI tools members connect to Mnemoverse. Members can access the room's existing history, including memories saved before they joined; joining does not expose their private account memory. Use when the user wants to share context or collaborate with someone else (e.g. 'make a room for me and my teammate'). Returns the room's address; pass that address as the |
| memory_invite_to_roomA | Mint an invite for a room you own and get a ready-to-forward message. An invite is single-use by default; pass max_uses to let several people join with the same one. The user sends that message to the person they want to add (any messenger); the recipient opens the link or tells THEIR assistant the code to join. Use when the user asks to invite someone to a room they own, including one just created with memory_create_room. |
| memory_join_roomA | Join a shared memory room using an invite code (starts with 'mnvr_'). Use when the user pastes an invite code or says something like 'join room with code ...'. The result gives the room's address, which is the |
| memory_list_roomsA | List the shared memory rooms you can use — the ones you OWN plus the ones you've JOINED — each with the address to pass as |
| vault_listA | List the secrets stored in your Mnemoverse Vault — by ALIAS and purpose only; the secret VALUE is never returned or shown to you, and no tool on this server returns it. Use this to check WHICH secrets the user has stored and under what alias (e.g. the user says 'do I have a GitHub token saved?'). Only YOUR account's secrets are listed. |
| memory_graphA | Reads the association edges around given concepts: which concepts the memory has linked together, with each link's weight, outcome valence and co-activation count. Use to inspect what a memory store has learned or to explain why a read expanded to a concept. Reads your own graph, or a shared room's when its address is passed as domain; any other domain value has no effect. At depth 2 or 3 the engine drops edges below weight 0.05 unless min_weight is set. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| recall | Search your Mnemoverse memory for saved information about a specific topic. |
| save_insight | Store a new insight, fact, or decision in your Mnemoverse long-term memory. |
| what_do_you_know | Get a briefing of what your memory holds about a subject. |
| setup_memory | Get memory rules to add to CLAUDE.md, AGENTS.md, Cursor rules or your chat preferences, so your assistant checks and saves memory without being reminded. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool has a clearly distinct purpose: semantic memory search, recency listing, stats overview, graph inspection, room creation/joining/inviting/listing, feedback, and vault listing are all separable. The potentially overlapping read-style tools are explicitly differentiated by their descriptions.
The tool set follows a consistent snake_case convention, with nearly all tools using the memory_ prefix and clear verb/noun structure. vault_list is a minor subsystem-specific exception but remains readable and predictable.
Eleven tools is well-scoped for a memory server with private memory, shared rooms, graph inspection, feedback, stats, and vault listing. Each tool earns its place without excessive surface area.
Core workflows are well covered: write, read/search, recent listing, feedback, room lifecycle basics, graph inspection, stats, and vault alias listing. Notable gaps remain around memory deletion/update and room membership management, though deletion is explicitly handled outside MCP.