MCP Memory Server vs Memocall — MCP Server Comparison | AllMCPs
Side-by-Side Model Context Protocol Comparison
MCP Memory Server vs Memocall
In-depth architectural comparison of the MCP Memory Server and Memocall MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
MCP Memory Server
Knowledge & Memory · Local stdio
Quality: 61/100 (Good) | Auth: API Key required
Memocall
Knowledge & Memory · Local stdio
Quality: 59/100 (Good) | Auth: No auth required
Verdict Summary: Choose MCP Memory Server if you need specialized Knowledge & Memory tools running via a local process. Choose Memocall if your workspace requires Knowledge & Memory integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose MCP Memory Server when:
You need dedicated capabilities in the Knowledge & Memory domain.
You prefer local stdio subprocess transport architecture.
Your security boundary fits: API Key required (Freemium).
You have access to required keys: MNEMOVERSE_API_KEY, MNEMOVERSE_API_URL.
Hosted memory that learns and forgets — feedback re-ranks what helps, recall fades by recency, similar memories consolidate. One key across Claude, Cursor, VS Code & ChatGPT.
Recall past Claude Code conversations from any project. Lists and searches your sessions, then loads one on demand as clean, compact Markdown — with outline, turn-range, and in-session search for large sessions. Read-only over local /.claude transcripts; collapses tool calls to stay under the context cap. npx -y memocall
Category & Scope
Tools & Capabilities Breakdown
MCP Memory Server Tools (10)
memory_write
Store a long-term memory that persists across sessions AND across every AI tool the user has connected to Mnemoverse (Claude, ChatGPT, Cursor, VS Code) — write once, recall everywhere. Call this PROACTIVELY the moment the user states a preference, makes a decision, or you learn a durable fact (people, roles, project setup, a lesson). Don't wait to be asked. Never store passwords, API keys, payment data, MFA codes, government IDs, or health records; skip transient chatter that only matters this turn. Behavior: an importance gate may filter low-value writes, so the result tells you whether the memory was stored or filtered. Write `content` as a self-contained statement that still makes sense when recalled out of context.
memory_read
Search your long-term memory before answering anything that may have come up before — user preferences, past decisions, project setup, people, or earlier context. This memory is shared: it persists across sessions and across every AI tool the user has connected (Claude, ChatGPT, Cursor, VS Code). ALWAYS check here first when you're unsure whether you already know something; no need to call it for general world knowledge you already hold. Returns matches ranked by relevance (or newest-first with order_by: 'recency'); each result carries an id you can pass to memory_feedback. A wrong or stale memory is corrected by writing a fresh one with memory_write, not by deleting it.
memory_list_recent
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 `since` (your last-seen time) to get only what's new, and page through older entries with the returned cursor. Complete by construction WITHIN ONE SCOPE — nothing is skipped there, unlike a semantic search. A page is also bounded by SIZE, so a page of long entries comes back shorter than `limit` and hands you a cursor for the rest — nothing is dropped, and following the cursor is how you get it. To catch up on a shared room you MUST pass its address as `domain`: rooms are separate stores and an unscoped call never covers them.
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
MCP Memory Server is categorized under Knowledge & Memory and uses a local stdio subprocess. In contrast, Memocall belongs to Knowledge & Memory using local stdio subprocess. Select MCP Memory Server when you need capabilities focused on knowledge & memory and Memocall when you require tools for knowledge & memory.
Report whether memories returned by memory_read were actually helpful. This is a learning signal, not a log: positive feedback raises a memory's ranking so it surfaces faster next time (across all of the user's tools), negative feedback lowers it so other memories out-rank it — nothing is erased and nothing decays with time. Call it right after you act on (or reject) recalled memories, passing the ids from the memory_read results. NOTE: this reaches your own domains only — it takes no domain argument, so rating a memory that lives in a shared room silently does nothing.
memory_stats
Get an overview of the stored memory: total count, episodes vs consolidated prototypes, number of learned 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_room
Create a SHARED memory room — a space OTHER people's assistants can read, and write too when their invite granted read_write (the default scope), across Claude/ChatGPT/Cursor. Use when the user wants to share context or collaborate with someone else (e.g. 'make a room for me and Olya'). Returns the room's address; pass that address as the `domain` on memory_write/memory_read to use it. To bring someone in, call memory_invite_to_room next.
memory_invite_to_room
Mint a one-time invite for a room you own and get a ready-to-forward message. 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 after memory_create_room, or whenever the user says 'invite <someone>' to an existing room.
memory_join_room
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 ...'. After joining, use the returned address as the `domain` on memory_read to read the shared room — the result tells you what you may do with it: memory_write to that address is only allowed when your membership scope is read_write; a read-only membership has that write refused; and when the server does not report a scope, whether memory_write would succeed is stated as unknown rather than promised either way.
memory_list_rooms
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 `domain` on memory_read, and on memory_write too where your membership scope is read_write; a read-only membership has that write refused. Use this to RE-FIND a room in a new session (e.g. 'what rooms do I have?', 'resume the room with Olya') instead of having to create or re-join it.
vault_list
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.
Memocall Tools (5)
list_sessions
List your recent Claude Code conversations across ALL projects, grouped by project directory. Use this to answer 'what sessions have I worked on recently?' or to find a past session before loading it. Returns each session's title, date, turn count, and id.
search_sessions
Search your past Claude Code conversations (across all projects) by keyword — matches session titles, first messages, and project paths. Use when the user refers to a past conversation by topic (e.g. 'the session where we set up the license system'). Returns matching sessions with their ids.
load_session
Load the context of a past Claude Code conversation as compact Markdown (human turns, collapsed tool-call summaries, and assistant replies — tool outputs are elided). Provide either a session `id` (from list_sessions/search_sessions) or a free-text `query` to find it. Use this to pull a previous conversation's context into the current session. For a very large session, either pass `turns` to load a specific window (turn numbers come from session_outline), or prefer session_outline / search_in_session.
session_outline
Get a quick MAP of a past Claude Code conversation: the numbered list of the user's prompts, one line each. Very cheap even for huge sessions. Use this to see what a session covered, or to find which turn numbers to then load with load_session's `turns`. Identify the session by `id` or free-text `query`.
search_in_session
Find specific turns WITHIN one past Claude Code conversation by keyword — returns only the matching turns (with their turn numbers). Use when the user asks what was decided or discussed about a topic inside a known or large session (e.g. 'what did we decide about retries in that session'). Pick the session by `id` or `session` (free-text); `query` is the keyword to find inside it.