What are the standard tools exposed by an MCP memory server?

You wire a memory server into your editor, it works, and you write the obvious instruction into your agent's setup: call add_memory when the user states a preference, call the search tool before answering anything about the project. A month later you try a different memory server, because the first one was slow or expensive or went down, and the instruction stops working. The tool names are different. Worse, one of them has a tool with the same name as before, and it does something else.

So the question people ask sounds reasonable: what are the standard tools an MCP memory server exposes? The answer is that there are none. Not few, none. The protocol standardises how a client finds a tool and calls it, and every tool name after that is the server's own invention.

One line to carry: MCP defines tools/list and tools/call, the word memory appears once in its schema, in a comment, and three popular memory servers each ship a tool called add_memory that does a different thing.

What the protocol actually pins down

A server can offer three kinds of thing, per the architecture page: resources, prompts and tools. There is no memory primitive among them.

You can check the rest yourself in under a minute. The TypeScript schema is the protocol's source of truth. Search it for memory and you find it once, in the comment on a boolean hint, where a memory tool is the example of a closed world:

For example, the world of a web search tool is open, whereas that of a memory tool is not.

Search it for persistence, storage, retrieval, vector or session and you get nothing. The session part is recent. The current revision lists "Stateless, self-contained requests" among its design points, and the tools page says it without qualification:

MCP has no protocol-level session.

What the protocol does standardise is the plumbing. A client asks tools/list and gets back definitions. The model picks one, the client sends tools/call, the result comes back. That is the whole contract as far as memory is concerned: two methods, and a shape for the answer.

Five servers, five vocabularies

Here is what that looks like in practice. Tool names as registered in each server's source or listed in its own documentation, read on 18 September 2026. The last row is ours, since I work on it.

server	write	search	tools in total
MCP reference memory server	create_entities, add_observations	search_nodes	9
Mem0, hosted MCP	add_memory	search_memories	11
Graphiti MCP server	add_memory	search_nodes, search_memory_facts	13
Supermemory MCP	add_memory, save-memory	search_memory	16
Mnemoverse, 0.10.1	memory_write	memory_read	10

Five servers, five different names for writing, and not even one naming convention: Supermemory registers add_memory with an underscore and save-memory with a hyphen in the same server.

The collisions are more instructive than the differences. Three of the five have a tool called add_memory, and the name is the only thing they share. Mem0's documentation describes its add_memory as "Save text or conversation history for a user/agent". Graphiti's docstring opens with "Add an episode to memory" and says the function "returns immediately and processes the episode addition in the background". Supermemory's description begins "Add (save) or forget a memory in the user's ACTIVE space", and its input takes an action of save or forget, so the tool named add can also remove.

search_nodes repeats the pattern. The reference server's version is a substring test over names, types and observations. Graphiti's is described as "Search for nodes (entities) in the graph memory" and takes group filters, a node cap with a default of 10, and entity type filters. Same name, unrelated mechanisms.

If your agent instructions name a tool, they are written for one server. That is the practical cost of there being no standard, and it is invisible until you switch.

What the model actually sees when it chooses

A tool definition has a name, an input schema, and a description. The schema's own comment on that description field is worth reading in full:

This can be used by clients to improve the LLM's understanding of available tools. It can be thought of like a "hint" to the model.

The quotes around hint are theirs. The field is declared description?: string, so it is optional: a server can register a tool with a name and an input schema and nothing that says when to use it. Whatever the model knows about when to call your memory tool, it learned from a sentence the server's author wrote, sitting next to every other tool's sentence.

How a server decides what comes back

The protocol does not say. It defines no relevance model, no ordering, no opinion about a good answer, so each server invents one, and this is where they genuinely differ.

The reference server is honest about its choice. In src/memory/index.ts the search lowercases the query and checks whether it appears in an entity's name, type or observations, and the comment above the function reads:

// Very basic search function

On the current main branch the file has no ranking, no scoring, no embeddings and no timestamps, so nothing in a stored record says when a fact was written. It keeps everything in one newline-delimited JSON file on disk. And it registers no prompts: the instructions for when to recall and what to save live in its README as text you paste into your client, opening with "Follow these steps for each interaction:". The server stores and returns. The remembering is done by the model, following text a person pasted.

That is not a criticism. It is a reference implementation and it says so. It is worth knowing before you read "MCP memory server" as though the phrase implied a retrieval system.

How the answer reaches the model

As text. A tool result is a list of content blocks, and the schema describes a text block in one line:

Text provided to or from an LLM.

The result then goes back into the conversation as an ordinary message. Anthropic's tool-call documentation states there is no special channel for it:

Unlike APIs that separate tool use or use special roles like tool or function, the Claude API integrates tools directly into the user and assistant message structure.

However clever a memory server's ranking is, what arrives is a string in the same window as everything else, competing for the same attention and subject to the same limits.

What to ask instead of which tools

Since the names carry no guarantee, the questions that separate one memory server from another are the ones the protocol leaves open. What gets admitted, and who decides a thing is worth storing. What comes back for a given question, and in what order. What happens when two clients write at once. Whether you can get your data out. And one more that follows from the table above: does the server's tools/list stay the same between versions, or will the names your instructions depend on move under you.

The cheapest check is to read the list yourself. Connect the server, ask for tools/list, and read every description the way the model will: as the only thing it knows about when to call that tool.

When you do not need one

If nothing needs to survive the conversation, you do not need a memory server, because surviving the conversation is the entire function. If the facts already fit in the window, putting them there is more reliable, because a pasted fact is always present and a tool call is a decision the model makes from a description string. And if what you want is a JSON file with nine tools on it, the reference server is exactly that, and it is worth reading before you buy anything, including from us.

What does your agent setup name by tool, and has a server switch ever broken it?

Disclosure: I work on Mnemoverse, one of the five servers in the table, so weigh the argument accordingly. The longer walk-through of the protocol, with every source, is on our library, and the MCP server is open source (MIT): github.com/mnemoverse/mcp-memory-server.