MCP memory server: what it is and how to evaluate one
The MCP connection is standardized. What a memory server stores, returns and keeps as evidence is not. Here is how to judge one in an afternoon, with a test you can repeat.
What an MCP memory server is
MCP, the Model Context Protocol, is an open standard for connecting AI applications to external systems: local files, databases, tools and workflows. The protocol describes an MCP host, the AI application, opening one client connection per server, with each server providing context to that client. Claude, ChatGPT, Visual Studio Code and Cursor all appear in the protocol's own list of supporting clients.
A memory server is one use of that pattern. The tool names vary from one implementation to the next, but the job is the same: an agent calls one tool to save something, another to search for it in a later session, and the server holds the record in between. That is why searching for a memory server returns so many results. The interesting question for a buyer is not what MCP is, since the protocol is documented and short. It is which of these servers deserves to hold project context.
A directory listing and a working memory are different things. A server that answers a search with plausible text can look convincing in a demo and fail a week later, when the code has changed and the note has not.
Sources: Model Context Protocol, What is MCP; Model Context Protocol, Architecture overview
The protocol standardizes the pipe, not the memory
The architecture overview is explicit about scope: MCP focuses solely on the protocol for context exchange, and it does not dictate how AI applications use LLMs or manage the provided context. Nothing in the standard says what counts as a memory, who may read it, how a stale memory is corrected, or where a saved claim came from.
Two servers can expose similarly named tools and behave nothing alike. One writes a line to a local file and drops the origin. Another keeps the source revision with the claim and can show it later. From the agent's side both look like a save tool. From your side they are different products with different failure modes.
So the useful question is not whether a server speaks MCP. Almost all of them do, because that part is solved. The useful question is what the server promises after the connection is made, and what you can still check when an answer looks wrong.
Three shapes, and what each one costs
Most memory servers fall into three shapes. Each trades away something different, and the trade is worth naming before you install anything. The protocol's architecture page notes that local servers using the STDIO transport typically serve a single client, while remote servers over Streamable HTTP typically serve many. That is a design consequence rather than a quality ranking.
| Shape | What it gives you | What it costs |
|---|---|---|
| Local server over STDIO | Runs on your machine, serves one client at a time, and records stay on your disk | Nothing is shared between machines or agents, so every client needs its own server or its own file |
| Hosted service over HTTP | Several authorized clients and machines read one store, and the vendor runs it | Records you save leave your machine, and availability, pricing and retention depend on the operator |
| Workspace with documents, tasks and memory | Context, work state and the evidence behind them live in one place several agents can read | More surface to authorize and audit, and the store has to be trusted with more than recall |
The table is a starting point, not a verdict. A single developer on one laptop can run a local file for months and never feel the first limitation, while a team with two agents and a server will feel it on the first day.
The two setups most guides start with
The reference server comes from the MCP project itself. Published on npm as @modelcontextprotocol/server-memory, the Knowledge Graph Memory Server stores entities, directed relations between them, and observations, which are short facts attached to an entity. An agent writes with tools such as create_entities and add_observations, and reads with search_nodes, open_nodes or read_graph. Everything lands in one JSONL file: memory.jsonl in the server directory, unless MEMORY_FILE_PATH points somewhere else.
It is a clear baseline, and its own README calls it a basic implementation. Search matches entity names, entity types and observation text, and each observation is a plain string, so the documented schema has no field for where a fact came from or when it stopped being true. It runs as a local process over STDIO, which puts it in the first row of the table above.
The memory bank is a file pattern rather than a server. Tweag's Agentic Coding Handbook describes it as a structured, Markdown-based documentation system, with files such as projectbrief.md, systemPatterns.md, activeContext.md and progress.md that the agent reads at the start of a session and updates as work moves. Memory bank MCP servers, such as alioshr/memory-bank-mcp, put those files behind MCP tools so that banks for several projects can be read and written through one server.
Memory bank files are readable, and they can be reviewed in a pull request, which is their main strength. Their weakness is the one the test below is built to catch: a Markdown note does not know when the code or the decision it describes has changed.
Sources: Model Context Protocol, Knowledge Graph Memory Server (@modelcontextprotocol/server-memory); Tweag, Agentic Coding Handbook: Memory Bank; alioshr, Memory Bank MCP Server
Cline memory bank: how it works and where it stops
Cline's documentation spells the memory bank out in full, and calls it a documentation methodology rather than a feature. It is six Markdown files in a memory-bank/ folder inside the project (projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md and progress.md) plus a block of custom instructions telling Cline to read all of them at the start of every task. The instructions go in a Cline Rules file such as .clinerules/memory-bank.md, or in the global custom instructions.
Three phrases run it. "initialize memory bank" creates the files for a new project, "update memory bank" makes Cline review every file, and "follow your custom instructions" tells a fresh conversation to read the bank and pick up where the last one stopped. When the context window fills, the documented routine is to update the bank, start a new conversation and give that last instruction. activeContext.md changes most often, and progress.md holds milestones and known issues.
The design has real strengths. There is no server and no account, the files sit in the repository next to the code, and a rules file committed with them gives every collaborator the same setup. Cline's FAQ adds that the method works with any AI that can read documents, although the commands differ from tool to tool.
Its limits come from the same design. Every task begins by reading every file, so a growing bank spends context before any work starts. A file is only as current as the last update someone asked for, and nothing in it records which conversation or commit a line came from. The bank also belongs to one repository: a decision taken in another project, or in a chat app that never opens this repository, does not reach it. If those limits start to bite, run the 30 minute test below on the bank exactly as you would on a server, because a fact that was saved and then changed exposes a stale file as quickly as a stale database.
Sources: Cline, Memory Bank; Cline, Cline Rules
Five questions that separate the options
Ask these before a demo, because each one changes what the tool can do when something goes wrong rather than when everything works.
- Where does it live, and who can read it? A local file and a hosted multi-tenant service are different privacy decisions, and only one of them survives a lost laptop.
- Does a saved memory keep its source? A claim traced to a document revision can be checked and corrected. A claim with no origin can only be believed or deleted.
- What happens when the source changes? If the document is edited, does the memory follow it, go visibly stale, or quietly keep the old wording?
- Can you see why a memory was returned? Ranking you cannot inspect is hard to debug and impossible to audit.
- Does it work in the clients you actually use? A protocol badge is not a tested connection, and compatibility is a claim someone should be able to show you.
A vendor that answers all five with specifics, including the limits, is more useful than one that answers with adjectives. If an answer to the third question is vague, that is the one to press: stale context is the failure buyers notice last.
A 30 minute test with your own agent
This is a check worth running before trusting any memory server with a real project. It needs one server, one agent client, and a document you are willing to edit. It measures the behaviour that matters more than any feature list: what happens on the second session, and after the source changes.
Prepare eight facts in three groups. First, a rule that must always apply, such as a build command or a naming convention. Second, a decision with evidence behind it, such as why a queue was moved to Postgres, with a link to the note that records the reasoning. Third, a personal preference, such as how you like code reviews written. Save them through the server, and keep a copy of exactly what you sent.
Close the session completely and open a new one, ideally in a second client. Ask three things in order. A question that needs two saved facts combined. A 'where does that come from' question about the decision. Then a question about something you never saved, which is the step most evaluations skip: a server that invents an answer there has failed, however good the first two looked.
Finally, edit the document that supported the decision. Change the reason, or remove the paragraph. Ask the same question in a fresh session. A memory that follows the change, flags itself as stale, or reports that the source moved is behaving correctly. One that repeats the old sentence has become a liability, and you found out in half an hour instead of a month.
Record four things for each run: the input, what was saved, what was loaded, and the final answer. That record is what turns a convincing demo into a judgement you can defend, and it is comparable the next time you evaluate something else.
Sources: Model Context Protocol, Architecture overview; Anthropic, Connect Claude Code to tools via MCP
Where Space sits against that test
Space is the workspace this site documents, so it should be judged by the same five questions. It holds documents, tasks and memories, reached over MCP by an agent you authorize from the Agents page of your Space. Codex was its first client with a verified document and task connection in a development environment, and Claude Code, Hermes, Cursor, Claude, ChatGPT, Gemini and Cline have each been tested with Space since.
On sourcing, a saved claim can keep the revision it came from, so the claim can be inspected against its evidence later. On correction, editing a source and forgetting a claim are separate actions, and removing a claim from recall does not erase every retained revision or backup. On privacy, stored text is encrypted while search embeddings and hashes remain readable, so Space does not claim end-to-end encryption or that an installation operator cannot read content. Extraction may be asynchronous, and it may be wrong.
Space is open: create an account at app.getspace.sh and connect agents from its Agents page. Connecting an agent does not import earlier conversations, so the first useful memory is one you save deliberately. Shared team Spaces are coming later.
Sources: Space, Agent connections; Space, Memories, claims, and sources
What no memory server promises
None of these tools guarantees that the right context arrives. Retrieval is a ranking, ranking moves with the query, and a memory that answered well last month can be wrong today. The protocol's own scope statement is careful about this for the same reason: MCP moves context, and it does not decide what is true.
Three limits are worth stating before you install or buy anything. A hosted store is only as private as its operators, and you are trusting them with whatever you save. Connecting a server is a trust decision, because a server that fetches outside content can carry injected instructions into a session. And no connection imports what your agent already knew, so the first useful memory is always one that someone saved on purpose.
Test those three, and the rest of the comparison gets easier. What you want is not the longest feature list. It is the store whose failures you can see.
Sources: Model Context Protocol, What is MCP; Anthropic, Connect Claude Code to tools via MCP