MnemoverseDocs

Appearance

Olga Timoshina·Published Aug 23, 2026

What is an MCP memory server? ​

An MCP memory server is a small program that does two things. It offers a model a few tools over the Model Context Protocol, and it keeps what it is told on disk after the conversation ends, so the same facts can come back later.

TL;DR

  • MCP standardises discovery, calling and answer shape. It does not standardise memory: no relevance model, no sessions, no storage rules. Everything interesting is the server's own design.
  • A retrieved memory returns to the model as plain text, in the same context window as everything else. That single fact drives most of what follows.
  • Every claim here is checked against the specification and the public reference server, both pinned. No product talk, no performance numbers.

That is the whole definition, and almost everything interesting about one of these is in the second half rather than the first. What follows walks the entire path: what the protocol actually pins down, how a client discovers the tools, what happens inside one tool call, how a server decides what to return, and what shape the answer takes when it reaches the model.

A note on who is writing. We build one of these servers ourselves, Mnemoverse, and that is exactly why nothing of ours appears in this article: the subject is the category, seen plainly. Every example is the specification or the public reference memory server, so any line can be checked without taking our word for it. There are also no performance numbers here; ours are frozen pending our own measurement harness, and we are not borrowing anyone else's to fill the gap.

The same walk-through exists on video, with every mechanism animated rather than described: twelve minutes, chaptered, for anyone who would rather watch it move. The text below stands on its own.

More of these on our YouTube channel — the same arguments, drawn out rather than written up.

What does the Model Context Protocol actually standardise? ​

The specification says MCP provides a standardized way to share contextual information with language models and to expose tools. A way to connect. Not a capability.

A server offers three things: resources, prompts and tools. There is no memory primitive among them.

Here is a check you can run yourself in under a minute. The TypeScript schema is the protocol's source of truth. Search it for the word memory. It turns up once, in a comment about a boolean hint, distinguishing a web search tool that reaches into an open world from a memory tool that does not. Search it for persistence, storage, retrieval or vector and you get nothing.

Search it for session and you also get nothing, and that part is new. Older revisions of the specification described MCP as a stateful session protocol. The 2026-07-28 revision opens by calling MCP a stateless protocol in which every request is self-contained, and the tools page puts it flatly:

MCP has no protocol-level session.

If you have read older writing about MCP, including ours, this is the sentence that dates it.

The revision did add caching, and it is worth being precise about what that is, because it is easy to mistake for the protocol growing a memory. A client can cache the list of tools, resources or prompts a server offers, with HTTP-style cache semantics. That is a cached directory listing. It is not stored conversation content and it is not anything you said.

So the honest sentence, the one worth keeping:

MCP standardises how a client discovers a tool, how it calls it, and what shape the answer comes back in. What gets stored, and what comes back, is the server's own design, outside the protocol.

Every memory server invents that part. Which means every claim about memory quality is a claim about a specific server, never about MCP.

How does a client discover the tools? ​

The client sends tools/list and gets back an array of tool definitions. Each definition has a name, a title, a description, an input schema, an optional output schema, annotations, and as of this revision an optional icons field.

Notice what a tool definition is made of. The name is an identifier. The inputSchema is JSON Schema, which a client can validate against. And the description is a string of prose written by whoever wrote the server.

That description string is not decoration. It is the entire basis on which a model decides whether to call the tool. Nothing else in the definition tells the model when the tool is appropriate. This becomes the whole story in a moment.

There is no negotiation handshake in this revision, and server/discover is optional for clients.

What methods does a memory server actually expose? ​

Two, as far as the protocol is concerned: tools/list and tools/call. Plus the resource methods if the server offers resources, which the reference server does.

This trips people up constantly, so it is worth saying directly: the tool names a memory server offers are not protocol methods. The reference server's nine tools are nine strings that server invented. Another memory server invents nine different ones. The protocol knows about tools/call and nothing about what you named your tools.

What happens when the model calls a memory tool? ​

The model emits a tool call. The client, not the protocol, routes it to the server. The server runs whatever code it likes. The result comes back as a CallToolResult.

And here is the shape of that result, from the schema:

typescript
export interface CallToolResult extends Result {
  /** A list of content objects that represent the unstructured result of the tool call. */
  content: ContentBlock[];
  /** An optional JSON object that represents the structured result of the tool call. */
  structuredContent?: { [key: string]: unknown };
  isError?: boolean;
}

A content block is one of exactly five things:

typescript
export type ContentBlock =
  TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;

Note that at this revision structuredContent was widened, and its own documentation now says it can be any JSON value, so "a JSON value" is the accurate phrase rather than "a JSON object".

How does a memory server choose what to return? ​

The protocol does not say. It defines no relevance model, no ordering rule for results, and no opinion about what a good answer is.

So look at what the reference implementation actually does. Its search lowercases your query and checks whether that string turns up in an entity's name, its type, or any of its observations. From src/memory/index.ts at commit 7b1170d, lines 192 to 196:

javascript
e.name.toLowerCase().includes(query.toLowerCase()) ||
e.entityType.toLowerCase().includes(query.toLowerCase()) ||
e.observations.some(o => o.toLowerCase().includes(query.toLowerCase()))

A case-insensitive substring test. The server's own comment five lines above it, at line 187, reads:

javascript
// Very basic search function

That comment is not a criticism of the file. The reference server is a reference, and it is honest about being one. But it is worth knowing what you are looking at when someone says "MCP memory server" as though the phrase implied a retrieval system.

Grep that file at that commit and you will find, case-insensitively: no limit, no rank, no score, no embed, no vector, no sort, no slice, no cursor, no page, no database, no sqlite. Results arrive in whatever order they sit in the file.

Grep it case-sensitively for Date and you find none of it either, nor timestamp, nor recenc. (A case-insensitive grep for date returns hits, but all of them are the word "updated" inside notifyGraphUpdated and the notifications/resources/updated string. Run it case-sensitively or the result argues with you.)

No timestamps means nothing in the stored record says when a fact was written or last touched. Recency and decay are not expressible by this server. Not badly implemented: not expressible.

Then the part that surprises people most. The behaviour everyone means by the word memory, deciding when to recall something and what is worth saving, is not in the server at all. The reference server registers no prompts. Those instructions live in its README as a block of text you paste into your client's custom instructions, opening with "Follow these steps for each interaction:".

The server stores and returns. The remembering is done by the model, following text a human pasted.

What text does a memory server put back in the prompt? ​

This is the part almost nobody shows you, and it is the reason the whole category is harder than it looks.

The memory does not arrive as memory. It arrives as tokens.

The protocol's own one-line description of a text content block is the most important sentence in the specification for this purpose:

Text provided to or from an LLM.

That is it. That is what a memory becomes.

The specification adds that, for backwards compatibility, a tool that returns structured content should also return the serialized JSON in a TextContent block. Read that condition carefully: it is scoped to tools that return structured content, and it is framed as backwards compatibility rather than as the recommended design.

The reference server satisfies the condition, at ten call sites. From read_graph, lines 482 to 485:

javascript
content: [{ type: "text" as const, text: JSON.stringify(graph, null, 2) }],
structuredContent: { ...graph }

search_nodes and open_nodes carry the same two lines. The same graph is serialised twice into a single result, and the text block is the half that becomes tokens in the window.

Then that result goes back into the conversation as an ordinary message. Anthropic's documentation is explicit that 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.

OpenAI's Responses API pushes a function_call_output item into the input; Chat Completions uses a dedicated tool role. The mechanism differs, the consequence does not.

So a retrieved memory is a JSON string, pasted into the conversation, competing for the same window as everything else in it, subject to all the same limits. It is not privileged. It is not pinned. It is text.

Whatever your memory layer does, however clever its ranking, the last step is always this one.

Where does it keep data between sessions? ​

The reference server keeps a single file of newline-delimited JSON. One line per entity or relation, appended. About six hundred lines of TypeScript around it, one dependency.

That is the entire persistence story, and it is worth sitting with, because "MCP memory server" sounds like infrastructure and this one is a text file with nine functions on it.

When do you not need one? ​

Three honest cases, and we sell a memory server, so weigh these accordingly.

If nothing needs to survive the conversation, you do not need one. That is the entire function. A long conversation is not a memory problem.

If the facts already fit in the window, putting them there is more reliable. On the reference server, nothing pushes memory into a conversation. It arrives when the model decides to call a tool, or when the client reads the graph as a resource. And the model makes that decision from a description string and its reading of the conversation. Pasting a fact into the prompt is a certainty. A tool call is a decision, and decisions have a failure rate.

If what you want is a text file with nine functions on it, the reference server is exactly that. Read it before you buy anything, including from us.

What to actually shop for ​

If you do need one, the useful questions are all in the part the protocol does not specify:

  • What gets admitted? What decides that something is worth storing at all?
  • What comes back for a given question, and in what order? There is no protocol answer here. Every server invents it, and most say very little about theirs.
  • What happens when two clients write at once?
  • Can you get your data out?

Because however each of those gets answered, what comes back is still tokens in one window.

Common questions ​

What is an MCP memory server? ​

A small program that does two things. It offers a model a few tools over the Model Context Protocol, and it keeps what it is told on disk after the conversation ends, so the same facts can come back later. Everything beyond that, what gets stored and what comes back for a given question, is the server's own design rather than anything the protocol specifies.

Does MCP give an agent memory? ​

No. MCP standardises how a client discovers a tool, how it calls it, and what shape the answer comes back in. The TypeScript schema is the protocol's source of truth and the word memory appears in it once, in a comment about a boolean hint. Search it for persistence, storage, retrieval or vector and you get nothing.

Does MCP have sessions? ​

Not at revision 2026-07-28. Older revisions described MCP as a stateful session protocol. The current one opens by calling MCP a stateless protocol in which every request is self-contained, and the tools page states that MCP has no protocol-level session. The caching added in this revision lets a client avoid re-fetching a list of tools; that is a cached directory listing, not stored conversation content.

How does an MCP memory server decide what to return? ​

The protocol defines no relevance model, no ordering rule and no opinion about what a good answer is, so every server invents it. The public reference server lowercases the query and runs a substring test against an entity's name, type and observations, with its own source comment above it reading "Very basic search function". No scoring, no ordering, no cap, no pagination and no timestamps, so recency and decay are not expressible by it at all.

How does a retrieved memory reach the model? ​

As text. A tool result is a list of content blocks, and the protocol's own description of a text block is "Text provided to or from an LLM." The result then goes back into the conversation as an ordinary message rather than through a special channel. A retrieved memory is a string competing for the same context window as everything else in the conversation, subject to the same limits.

When do you not need an MCP memory server? ​

Three cases. If nothing needs to survive the conversation, since that is the entire function. If the facts already fit in the window, because pasting a fact is a certainty while a tool call is a decision the model makes from a description string. And if what you want is a text file with nine functions on it, because the public reference server is exactly that.

Sources ​

Specification, the source of truth for every protocol claim above:

Reference implementation, for every claim about what a real memory server does:

Client-side handling:

The source base is deliberately narrow: this article is a walk-through of one specification and one reference implementation, both pinned, rather than a survey. The survey lives in Memory MCP Servers Compared.

— Olga Timoshina · Last updated 2026-08-23