MCP Memory: What It Is and How to Give Any MCP Client Persistent Memory

MCP memory is a Model Context Protocol server pattern that exposes remember, recall, and forget tools so MCP-compatible clients like Claude Code, Cursor, and Codex keep state across sessions instead of starting every conversation from scratch. This guide is written for engineers and technical decision-makers already using at least one MCP client who want to understand how MCP memory works under the hood, where the reference memory server stops being enough, what a production-grade server needs to add, and how to actually run one. Cognee, an open-source knowledge-graph memory platform, appears throughout as one practitioner of this pattern.

What MCP Memory Actually Is and the Components It Requires

MCP memory is a Model Context Protocol server that exposes memory tools-typically remember, recall, forget, and search-so any MCP-compatible client like Claude Code, Cursor, or Codex can persist and retrieve information across sessions. Four components must be in place: the MCP server process, a transport (stdio, SSE, or streamable HTTP), a storage layer (JSONL file, vector store, graph database, or a hybrid), and a tool schema the client discovers through tools/list. MCP standardizes this interface for reading files, calling functions, and handling context, and was donated by Anthropic to the Agentic AI Foundation under the Linux Foundation in December 2025. Cognee implements this pattern with a knowledge graph backend and the remember, recall, improve, and forget verbs.

How to Think About MCP Memory in Modern Agent Workflows

Coding agents and chat assistants start every session blank, so MCP memory matters because the Model Context Protocol standardizes how any client reaches an external store that survives those resets. A minimum viable setup is the reference @modelcontextprotocol/server-memory, installed with npx -y @modelcontextprotocol/server-memory, which keeps entities, relations, and observations as a single-user JSONL knowledge graph on local disk. A mature setup adds embeddings for semantic recall, typed graph relationships, multi-user access, pluggable storage, and temporal reasoning behind one shared endpoint across IDEs. Cognee sits at that mature end, combining hybrid graph and vector storage for persistent long-term memory.

Common Challenges Teams Face When Running MCP Memory

MCP memory sounds simple until a second developer, a second IDE, or a second project enters the picture. The reference memory server was designed as a single-user demo: it writes a JSONL file of entities, relations, and observations to local disk, with no embeddings, no shared endpoint, and a schema that is too flat to describe code structures or time-sensitive facts. At scale, teams hit four recurring failure modes, isolated state, literal-match recall, impoverished schemas, and bloated tool payloads. Cognee has worked through each of these in production deployments with Claude Code, Cursor, and other MCP clients.

Key Challenges and Failure Modes When Scaling MCP Memory

• Single-user JSONL storage can't share state across clients. The reference server persists entities, relations, and observations to a local JSONL file, which means a note captured in Claude Desktop is invisible to Cursor on the same machine, and nothing is shared across teammates or CI agents.
• No embeddings means literal-match recall only. Without a vector index, recall degrades to keyword or exact-name lookups against the graph, so paraphrased questions, synonyms, and conceptually related facts never surface even when they are stored.
• Flat entity/relation/observation schema can't model code or temporal facts. A three-node schema cannot express function signatures, module boundaries, or when a fact was true, so code knowledge collapses into generic observations and superseded information lingers alongside current state.
• Tool-list bloat as the memory server grows. As a memory server adds remember, recall, search, prune, and admin tools, every tools/list response balloons, consuming context window on each session and crowding out the application tools the agent actually needs.

Mitigation follows the inverse of each failure mode. Pluggable storage backends replace local JSONL with graph and vector stores that can be shared and backed up. Hybrid graph plus vector retrieval combines semantic search with explicit relationships, which is more accurate than flat RAG and keeps paraphrased queries resolvable. Running the memory server in API mode gives multiple assistants a single shared endpoint instead of per-client silos. And exposing only a small default tool set through tools/list, with the rest reachable through tool search, keeps the payload lean. Cognee implements all four, hybrid graph and vector architecture, contradiction detection and temporal superseding, API mode for shared knowledge graphs, and a trimmed tools/list with tool search, and ships first-party integrations for Claude Code and Cursor so agents can read and write memory without custom glue.

How to Define a Winning Strategy for MCP Memory

A winning MCP memory strategy starts with the storage model and recall semantics, not the server binary. Teams that pick a tool first tend to inherit its assumptions: a flat vector store forces similarity-only recall, a pure graph forces hand-authored schemas, and a single-user process rules out shared context across assistants. Deciding up front how memories should be stored, related, timestamped, revised, and shared across clients makes the server choice almost mechanical. The checklist below covers the capabilities that separate a long-lived MCP memory layer from a prototype that drifts out of sync with reality.

Must-Have Capabilities for a Scalable MCP Memory Strategy

• Hybrid graph and vector retrieval. Semantic search finds candidates by meaning, while explicit graph relationships ground answers in verifiable context, which produces higher accuracy than flat retrieval over chunks alone.
• Temporal reasoning and contradiction handling. Facts in agent memory have dates, and they change. The memory layer should treat timestamps as first-class graph data so before, after, and between questions resolve against a time window, and it should supersede older facts when new ones contradict them.
• Shared multi-client endpoint (API mode). A single standalone process is fine for one developer, but a team strategy needs an API mode where Claude Code, Cursor, Codex, and other MCP clients read and write the same knowledge graph.
• Pluggable storage backends. Memory outlives tooling. Picking a server that abstracts the graph and vector stores lets the same memory move from local files to Postgres, Neo4j, or managed stores without rewriting the agent.
• Four-verb memory lifecycle (remember, recall, improve, forget). A complete lifecycle covers ingestion that builds structure, retrieval that auto-routes over it, refinement of what is already stored, and deletion for correctness and compliance.
• Multiple MCP transports (stdio, SSE, streamable HTTP). Different clients and deployment shapes need different transports: stdio for local processes, SSE and streamable HTTP for shared and remote endpoints.

Cognee maps directly onto this list. Its open-source core combines graph and vector storage so recall uses semantic similarity alongside explicit relationships, and contradiction detection with temporal superseding keeps the graph consistent as sources evolve. SearchType.TEMPORAL reads a time window from the question and reranks results so dated content lands first. The MCP server runs standalone or in API mode for shared graphs across assistants, exposes stdio, SSE, and streamable HTTP transports, and backs the remember, recall, improve, and forget verbs that cover the full memory lifecycle on pluggable graph and vector backends.

How to Choose the Right MCP Memory Server and Architecture

Engineering teams running coding agents across Claude Code, Cursor, and Codex eventually hit the same question: which MCP memory server belongs in the stack, and how should it be deployed. The ideal reader here is a tech lead or platform engineer who needs shared, durable memory that outlives a single session, works for more than one developer, and does not turn into a weekend of ops work. The decisions ahead cover selection criteria, build versus buy posture, a reference architecture that fits the team's size, and the categories of tools that make the system complete.

Tool Selection Criteria That Matter Most

Scalability comes first: the server must hold a growing knowledge graph without rewriting the ingestion path. Interoperability matters almost as much, since the same memory should be reachable from every MCP client the team already uses, Claude Code, Cursor, Codex, Windsurf, and Claude Desktop. Cost model shapes long-term adoption, so usage-based pricing is easier to justify than per-seat licenses. Data residency decides whether the server can run in a specific region or VPC. Finally, operational overhead and maintainability determine whether the memory layer survives the first on-call rotation.

Build vs Buy Tradeoffs

The practical choice is open-source self-hosted, managed cloud, or BYOC. Self-hosting Cognee's Apache-2.0 core suits teams that want full control of the knowledge graph, backends, and network path. Cognee Cloud removes the ops work with usage-based pricing at $1.00 per 1M tokens processed, plus $5 per additional workspace; the free workspace includes tokens, unlimited users, unlimited API calls, and the agentic integrations for Claude Code, Codex, and MCP. Cognee Enterprise is BYOC, running the managed deployment inside a customer-owned AWS, Azure, GCP, or European provider account so data stays in the customer's VPC.

Reference Architectures by Team Size

A solo developer can start with the MCP reference server or a local stdio Cognee process; the memory lives on the laptop and the tool payload stays small because only a subset of tools is listed by default. A small team is better served by a single Docker Cognee MCP container running in API mode on port 8000, so Claude Code, Cursor, and Codex all read and write the same knowledge graph through claude mcp add --transport http cognee http://localhost:8000/mcp -s project. A larger organization usually lands on BYOC with Neo4j or Postgres as the graph backend, enabling TEMPORAL and CYPHER search modes at scale.

Tool Categories Required for a Complete Stack

A production MCP memory stack is not just one server. It needs the MCP server itself, a transport (stdio for local, HTTP or SSE for shared deployments), storage split between a graph database and a vector index, an ingestion pipeline that turns documents, code, and conversations into graph nodes and embeddings, a retrieval and ranking layer that combines vector similarity with graph context, and admin plus observability for permissions, usage, and audit. Keeping these categories explicit makes it easier to swap any single component, including the memory server, without rebuilding the agent workflow around it.

Step-by-Step Guide to Running an MCP Memory Server in Production

Getting an MCP memory server into production is a sequencing problem more than a coding problem. Plan storage first (local file vs. shared graph and vector backends), stand up the server process, wire each MCP client to its endpoint, ingest the documents, code, and conversations that should become memory, verify that recall actually returns the expected graph context, and then operationalize with monitoring, backups, and access controls. Treating these as discrete, verifiable steps keeps rollout predictable and makes it obvious which layer to debug when a client fails to recall.

Implementing an MCP Memory Server End to End

1. Decide storage and mode. Choose between standalone mode for a single developer using local stdio and API mode when several assistants need to share one knowledge graph. Cognee supports standalone, API, and cloud modes, and its MCP server exposes streamable HTTP, SSE, and stdio transports so the same server can serve a solo workflow or a shared team deployment.

2. Start the server. Run the Cognee MCP server with Docker using the cognee/cognee-mcp:main image on port 8000. The server keeps its tool payload small by listing only a subset of its 14 tools (including cognify, codify, remember, recall, and search) in tools/list by default, with the rest discoverable through tool search so the client context stays lean.

3. Connect Claude Code. Register the running server with Claude Code over HTTP:

claude mcp add --transport http cognee http://localhost:8000/mcp -s project

For a single-user local setup, connect over stdio instead. The -s project scope keeps the memory binding tied to the current project so recall stays relevant to that codebase.

4. Connect Cursor. Add an entry to ~/.cursor/mcp.json pointing at the local HTTP endpoint so Cursor's Agent mode can reach the same server:

{
  "mcpServers": {
    "cognee": {
      "url": "http://localhost:8000/mcp"
    }
  }
}

In API mode this configuration lets Cursor and Claude Code share one graph, so a fact remembered in one client is available in the other.

5. Ingest and build memory. Use the remember and cognify tools to pull documents, code, and conversations into the graph. remember ingests content and builds the graph, while cognify processes it into entities, relationships, and time-stamped facts. The four-verb API-remember, recall, improve, forget-covers the full memory lifecycle, so ongoing updates and deletions use the same tool surface.

6. Verify recall and temporal queries. Call recall to confirm the server auto-routes retrieval over the graph and returns the graph context used. Then exercise SearchType.TEMPORAL, a Vector + Graph retriever, with before, after, and between questions; it reads a time window from the question and reranks hybrid results so content dated inside the window comes first. If the backend is Kuzu or Neo4j, SearchType.CYPHER can be used for direct Cypher queries to validate the graph structure.

Best Practices for Operating MCP Memory Long Term

Durable MCP memory is less about picking the right server once and more about ongoing discipline: controlling what gets ingested, letting the schema evolve as domains change, and reviewing stored facts before they rot. Teams that treat the memory layer like a database, with scoped writes, lifecycle operations, and a backend chosen for the queries that actually run, avoid the slow drift where recall quality degrades week over week. Cognee is built around these patterns and exposes them directly through its MCP server, so the practices below map to concrete settings rather than hand-rolled wrappers.

• Keep the tool payload small. The Cognee MCP server lists only a subset of its catalog in tools/list by default and makes the rest discoverable through tool search, which keeps context windows lean and prevents the client from being overwhelmed by dozens of memory verbs at once.
• Prefer API mode when memory is shared. Running the MCP server standalone is fine for a single user, but switching to API mode lets several assistants, different IDEs, teammates, or background agents, read and write against one knowledge graph instead of fragmenting state across local files.
• Enable temporal mode for evolving facts. Turning on temporal_cognify=True extracts events and timestamps from text as it is ingested, so dated facts are superseded in the graph rather than duplicated. For deeper history, Graphiti mode stores each document as a timestamped episode in Neo4j and tracks how entities change over time.
• Use the four-verb lifecycle to prune state. The remember, recall, improve, forget API covers the full memory lifecycle: remember ingests and builds the graph, recall auto-routes retrieval, improve refines stored knowledge, and forget removes entries that are no longer true. Scheduling periodic forget passes is what keeps long-lived memory from accumulating contradictions.
• Match the backend to the query shape. Choose Kuzu or Neo4j when Cypher queries matter, Cognee's CYPHER search mode requires a Cypher-capable graph store, and lean on the TEMPORAL vector-plus-graph retriever for time-aware semantic recall. Pairing the right backend with contradiction detection and temporal superseding keeps answers consistent as sources disagree or evolve.

How Cognee Simplifies and Scales MCP Memory

Cognee is a free, open-source AI memory platform from Topoteretes UG, licensed under Apache-2.0, with 32.5k stars, 3.4k forks, and 112 watchers on the topoteretes/cognee GitHub repository. It turns documents, code, and conversations into a self-hosted knowledge graph that agents can search and reuse across sessions. The Cognee MCP server exposes 14 specialized tools, including cognify, codify, remember, recall, and search, and runs in standalone, API, or cloud mode. It supports streamable HTTP, SSE, and stdio transports, so Claude Code, Cursor, Codex, LangGraph, OpenClaw, and any other MCP-compatible client can read and write the same memory without custom glue.

Under the hood, Cognee combines a hybrid graph and vector store with a native temporal mode (temporal_cognify=True) that extracts events and timestamps into the graph, plus a Graphiti mode that stores each document as a timestamped episode in Neo4j. SearchType.TEMPORAL handles before, after, and between questions, while CYPHER mode runs direct queries against a Cypher-capable backend such as Kuzu or Neo4j. Cognee Cloud is usage-based at $1.00 per 1M tokens processed, plus $5 per additional workspace, with a free workspace that includes tokens, unlimited users, unlimited API calls, and the agentic integrations. Cognee Enterprise is BYOC, running inside the customer's own AWS, Azure, GCP, or European provider account with data staying in the VPC.

Key Takeaways and How to Get Started

MCP memory is the standardized way to give coding agents durable state across sessions and clients. The reference knowledge-graph server is useful for demos, but production workloads need hybrid vector-and-graph retrieval, temporal reasoning, multi-client sharing, and pluggable storage. Cognee implements that pattern end to end, turning documents, code, and conversations into a self-hosted knowledge graph agents can search and reuse. To try it, run the open-source MCP server locally with docker run -p 8000:8000 cognee/cognee-mcp:main, or start on Cognee Cloud's free workspace with unlimited users and API calls.

Related guides

• Cognee MCP Server
• Best MCP Memory Servers for AI Coding Assistants
• Claude Code Memory: CLAUDE.md, Auto Memory, and Persistent Memory Across Sessions
• Codex Memory: How to Give OpenAI Codex Persistent Memory Across Sessions
• Hermes Agent Memory: How It Works and How to Improve It
• Cognee CLI Replaces MCP OAuth

Frequently Asked Questions

What is MCP memory?+

MCP memory is a Model Context Protocol server that exposes remember, recall, and forget style tools so any MCP client gets state that survives sessions. MCP itself is a standardized interface for reading files, executing functions, and handling contextual prompts, adopted by providers including OpenAI and Google DeepMind. A memory server implements that interface for persistent storage of entities, relations, and observations. Cognee ships one such server, backed by a knowledge graph plus vector index, and it works with Claude Code, Cursor, and Codex through the same tool contract any MCP client already speaks.

How do I give Claude Code or Cursor persistent memory with an MCP server?+

Run a memory server and register it with the client. The Cognee MCP server can be started with Docker using the cognee/cognee-mcp:main image on port 8000. Claude Code connects with claude mcp add --transport http cognee http://localhost:8000/mcp -s project, or locally over stdio. Cursor picks it up by adding an entry in ~/.cursor/mcp.json pointing to the local HTTP endpoint, which enables Agent mode to use the shared graph. After registration, the assistant sees remember, recall, and search tools and begins writing memories into the Cognee graph automatically.

What are the limits of the reference @modelcontextprotocol/server-memory?+

The reference memory server, installed with npx -y @modelcontextprotocol/server-memory, is a knowledge graph persistent memory system that lets assistants like Claude remember information across chats by storing entities, relations, and observations as a JSONL file in the reference server's format. That design is fine for a single user on a single machine, but it has no embeddings for semantic retrieval, no multi-user isolation, no pluggable graph or vector stores, and no temporal reasoning. Cognee replaces the JSONL file with a hybrid graph and vector architecture and adds 14 specialized tools including cognify, codify, remember, recall, and search.

How does Cognee's MCP memory compare to Mem0 and Zep?+

Mem0 ships OpenMemory as an official local MCP server and stores memories as vector embeddings retrieved by semantic similarity; its managed cloud starts at $0.01 per memory operation with 1,000 free operations per month. Zep offers an official MCP server backed by a temporal knowledge graph of nodes and edges, with Zep's Context MCP Server starting at Flex $125 a month for 5 MCP seats and Zep's managed cloud starting at $104/mo on a credit-based Flex plan. Cognee combines both approaches, pairing a temporal knowledge graph with a vector index and exposing them through one MCP server.

Can multiple MCP clients share the same memory store?+

Yes. The Cognee MCP server can be run standalone for one user or in API Mode so several assistants share one knowledge graph. In API Mode, Claude Code, Cursor, and Codex all connect to the same Cognee instance and read and write to the same graph plus vector index, so a fact written by one client is immediately recallable by another. The server also keeps the tool payload small by listing only a subset of its catalog in tools/list by default, with the rest discoverable through tool search, which keeps shared sessions responsive.

How much does Cognee cost to run as an MCP memory server?+

Cognee is open source under Apache-2.0, so self-hosting the MCP server is free aside from infrastructure. Cognee Cloud is usage-based: $1.00 per 1M tokens processed, plus $5 per additional workspace. The free workspace includes tokens, unlimited users, and unlimited API calls, and supports the agentic integrations including Claude Code, Codex, and MCP, which is enough to evaluate Cognee as an MCP memory backend end to end. Teams that need bring-your-own-cloud deployment can move to the Enterprise tier while keeping the same MCP server image.

Does Cognee's MCP memory support temporal queries and contradiction detection?+

Yes. Cognee builds a temporal knowledge graph by default: dates in the data become part of the graph, and SearchType.TEMPORAL answers before, after, and between questions by reading a time window from the question and reranking hybrid results so content dated inside it comes first. A native temporal mode, temporal_cognify=True, extracts events and timestamps from text and adds them to the graph, and a Graphiti mode stores each document as a timestamped episode in Neo4j. Contradiction detection with temporal superseding is available for domains where sources disagree or evolve over time.