Claw Blogs
AI Agent Memory

MCP and Agent Memory: How the Model Context Protocol Became the Universal Memory Interface

AI Agents Memory MCP Model Context Protocol Architecture Knowledge Graphs SQLite

Six months ago, if you built an agent with persistent memory, that memory was locked inside your specific framework. A LangGraph agent stored its context in one format. A CrewAI crew used another. A coding agent running in Claude Code had its own ad-hoc solution. Switch frameworks, and your agent developed amnesia.

Today, you can install a single MCP memory server, connect it to Claude Code, Cursor, Windsurf, Gemini CLI, or any other MCP-compatible client, and your memories travel with you. The agent itself is interchangeable. The memory is not.

This is the quiet revolution that happened while everyone was focused on model capabilities. The Model Context Protocol, introduced by Anthropic in late 2024 as a general-purpose tool interface, has become the universal plug for agent memory. As of this writing, there are over a dozen production-ready MCP memory servers on GitHub, ranging from a 3,500-star Go binary to a full knowledge graph service with OAuth support.

I have covered memory architectures, search algorithms, vector databases, and decay curves in this series. This post is about the layer that sits underneath all of them: the protocol that decides how an agent talks to its memory in the first place.

What MCP Actually Does for Memory

MCP defines a standardized way for AI agents to call tools. In the memory context, “tools” means operations like “store this fact,” “search for relevant memories,” and “delete this observation.” The protocol handles the transport (stdio or HTTP), the message format (JSON-RPC), and the discovery mechanism (the server announces what tools it provides).

The architecture has three components:

┌──────────────────────────────────────────────────┐
│                  MCP Host                        │
│        (Claude Code, Cursor, Copilot, etc.)      │
│                                                  │
│  ┌────────────┐  ┌────────────┐  ┌───────────┐  │
│  │ MCP Client │  │ MCP Client │  │ MCP Client│  │
│  │ (memory)   │  │ (github)   │  │ (files)   │  │
│  └─────┬──────┘  └─────┬──────┘  └─────┬─────┘  │
└────────┼───────────────┼───────────────┼─────────┘
        │               │               │
   stdio/HTTP      stdio/HTTP      stdio/HTTP
        │               │               │
┌───────▼───────┐ ┌─────▼──────┐ ┌─────▼──────┐
│ Memory Server │ │ GitHub Svr │ │ File Server│
│ (persist mem) │ │ (repos)    │ │ (disk)     │
└───────────────┘ └────────────┘ └────────────┘

The host runs the agent. Each client connects to a specific server. Servers expose tools. The protocol is the same whether the tool is “search my codebase” or “remember that the user prefers dark mode.”

What makes this powerful for memory specifically is the decoupling. Your memory server can run locally as a subprocess, remotely as an HTTP service, or in a Docker container on your home server. The agent does not care. It calls search_memories("user's deployment preferences") and the protocol handles the rest.

The Reference Implementation: Knowledge Graph Memory

Anthropic’s official MCP memory server is the knowledge graph memory server. It ships as part of the official MCP servers repository and provides a deceptively simple model: entities, relations, and observations.

Entities are nodes. Each has a name, a type (person, organization, project, concept), and a list of observations (atomic facts stored as strings).

{
  "name": "Sarah",
  "entityType": "person",
  "observations": [
    "Prefers TypeScript over Python for new projects",
    "Uses Vim keybindings in VS Code",
    "Deploys to AWS, avoids GCP due to billing issues in 2024"
  ]
}

Relations connect entities with typed, directed edges:

{
  "from": "Sarah",
  "to": "inventory-service",
  "relationType": "owns"
}

The server stores everything in a single JSONL file on disk. No database, no background process. This is the “Hello World” of agent memory, and its simplicity is deliberate. Anyone can run it with a single npx command:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

The server exposes nine tools: create_entities, create_relations, add_observations, delete_entities, delete_observations, delete_relations, read_graph, search_nodes, and open_nodes. That is the full API. An agent can build a complete memory system from these primitives.

The catch is that “complete” here means “functionally complete,” not “production-ready.” The JSONL backing store does not scale past a few thousand entities. Search is a simple text match across names, types, and observations. There is no vector search, no BM25, no decay, no deduplication, no multi-user isolation. The reference implementation is a proof of concept that demonstrates what an MCP memory server looks like, not what you would deploy for a serious agent.

That gap between reference and production is where the ecosystem stepped in.

The Ecosystem: Six Memory Servers That Actually Scale

A year after the reference implementation, the MCP memory server landscape has exploded. Here are the six most interesting projects, each taking a fundamentally different approach to the same problem.

Engram: The Local-First Purist

Engram (3,500 stars) is a single Go binary that stores memories in SQLite with FTS5 full-text search. No Node.js, no Python, no Docker. Install it with Homebrew, connect it to any MCP-compatible agent, and you have persistent memory with sub-millisecond recall.

What sets Engram apart is its focus on the coding agent workflow. It exposes 19 MCP tools organized into five categories: save and update, search and retrieve, session lifecycle, conflict surfacing, and utilities. The session lifecycle tools are particularly well thought out. mem_session_start and mem_session_end bracket each agent session, letting Engram track what happened during that session and provide contextual summaries for the next one.

Agent (Claude Code / OpenCode / Gemini CLI / Codex / VS Code / ...)
    ↓ MCP stdio
Engram (single Go binary)
    ↓
SQLite + FTS5 (~/.engram/engram.db)

Engram also solves a problem that plagues coding agents specifically: compaction recovery. When a long coding session exceeds the context window and the conversation gets compacted, the agent loses the detailed context of its earlier work. Engram’s session summaries survive compaction because they live outside the context window entirely.

The conflict surfacing tools, mem_judge and mem_compare, are unique to Engram. When a new observation contradicts an existing one, the agent can explicitly ask the memory server to surface the conflict. This is a far more sophisticated approach than the “latest write wins” default that most memory systems use.

mcp-memory-service: The Full-Stack Solution

mcp-memory-service (1,850 stars) takes the opposite approach from Engram. Rather than a minimal local binary, it is a full Python service with a REST API (76 endpoints), a web dashboard, OAuth 2.0 authentication, and a knowledge graph with typed edges.

The knowledge graph is the key differentiator. While most MCP memory servers store flat observations, mcp-memory-service stores memories with causal relationships. An edge can be typed as causes, fixes, contradicts, leads_to, or any custom type you define. This lets agents reason about why something happened, not just what happened.

# Store with causal relationship
await client.post(f"{BASE_URL}/api/memories", json={
    "content": "API rate limit is 100 req/min",
    "tags": ["api", "limits"],
}, headers={"X-Agent-ID": "researcher"})

# Search scoped to a specific agent
results = await client.post(f"{BASE_URL}/api/memories/search", json={
    "query": "API rate limits",
    "tags": ["agent:researcher"],
})

The X-Agent-ID header auto-tags every memory with its source agent. In multi-agent setups, this means each agent can search its own memories, shared memories, or all memories. The project documents a real-world deployment where a five-agent cluster uses mcp-memory-service as both shared state and an inter-agent messaging bus, using sentinel tags like msg:cluster to signal across agents.

The service also supports Remote MCP, which means it works with claude.ai in the browser, not just desktop clients. This is currently the only MCP memory server with that capability.

Token Savior Recall: The Memory-as-Performance-Optimizer

Token Savior Recall (858 stars) approaches memory from a different angle entirely. It is not just a memory server, it is a structural code navigation engine that happens to have a memory system bolted on. And the combination produces remarkable results.

The benchmark numbers are striking: 100% on a 180-task coding benchmark (up from 78.3% baseline), with 77% fewer active tokens per task and 76% less wall time. The memory engine stores every decision, bugfix, convention, and session rollup in SQLite with FTS5 and optional vector search, ranked by Bayesian validity and ROI.

What makes Token Savior’s memory system interesting is its progressive disclosure contract. Instead of dumping all relevant memories at session start, it uses three layers:

  1. Layer 1 (memory_index): A shortlist of relevant memory categories, costing roughly 15 tokens per result
  2. Layer 2 (memory_search): Detailed search results with more context
  3. Layer 3 (memory_get): Full observation retrieval by citation URI

This mirrors the progressive retrieval pattern I described in earlier posts, but enforces it at the protocol level. The agent cannot accidentally over-retrieve because the tools themselves enforce the budget hierarchy.

The Bayesian validity system is also notable. Every observation carries a validity prior and an explicit update rule. When the underlying code changes (detected via content hash), linked observations are automatically invalidated. This is the “symbol staleness” problem, and Token Savior is one of the few memory systems that handles it proactively rather than waiting for the agent to encounter stale information.

Nocturne Memory: The Personality-First Approach

Nocturne Memory (1,080 stars) is designed around a different assumption than every other server on this list. It assumes that memory is not just about facts and decisions. It is about identity.

Nocturne stores memories in a hierarchical URI scheme: system://boot for identity and personality, core://work_project/ for project-specific knowledge, core://user/ for personal context. The boot sequence loads identity before anything else, so the agent starts each session knowing who it is before it knows what it is working on.

This matters more than it sounds. An agent that remembers your deployment preferences but does not remember that it is a sarcastic, technically precise assistant will produce technically correct but tonally jarring responses. Nocturne treats personality continuity as a first-class memory problem.

The project also emphasizes cross-model portability. Because the memory lives in an independent MCP server, you can switch from Claude to GPT to a local model without losing accumulated context. The memory is model-agnostic by construction.

MCP-Mem0: The Managed Memory Bridge

MCP-Mem0 (677 stars) bridges MCP with the Mem0 managed memory API I covered in a previous post. It exposes three tools: save_memory, get_all_memories, and search_memories.

The value here is not the memory system itself (that is Mem0’s job) but the protocol bridge. If you already use Mem0 for your agent memory, MCP-Mem0 lets any MCP-compatible client access it without writing custom integration code. The template implementation is deliberately simple, making it a good starting point for anyone building their own MCP memory server.

Codebase Memory MCP: Code as Memory

Codebase Memory MCP (2,370 stars) takes a different approach to the memory problem. Instead of asking the agent to explicitly store and retrieve memories, it indexes your entire codebase into a persistent knowledge graph. Every function, class, import, and call relationship becomes a node or edge that the agent can query.

This is not traditional “memory” in the episodic sense. It is structural knowledge that persists across sessions without the agent having to actively “remember” anything. The indexer processes an average repository in minutes, and the resulting graph lets the agent answer questions like “where is authentication handled?” or “what depends on the payment module?” without reading files.

How the Protocol Shapes the Memory

Here is something I learned from running my own memory system: the protocol you use to access memory constrains the kind of memory you can have.

The official MCP memory server uses entities and relations because JSONL can store them. That is a graph model, and it works well for knowledge that is inherently relational: “Sarah works at Acme” or “the auth service depends on Redis.”

Engram uses structured observations with type and project fields because SQLite with FTS5 can index them efficiently. That is a document model, and it works well for episodic memory: “fixed a race condition in the payment handler on May 15.”

Token Savior uses citation URIs and progressive disclosure layers because the tool interface enforces budget boundaries. That is a retrieval model, and it works well when token efficiency matters more than recall completeness.

The protocol is not neutral. Every MCP memory server makes implicit claims about what memory is for, and those claims shape what the agent can do.

A server that only provides save and search tools assumes memory is a bag of facts. A server that provides create_relations assumes memory is a graph. A server that provides session_start and session_end assumes memory is organized around work sessions. A server that provides judge and compare assumes memories can contradict each other and the agent should know when they do.

When you choose an MCP memory server, you are choosing a model of memory. That choice matters more than the underlying storage technology.

The Gotcha: MCP Memory Is Not Automatic

The biggest misconception about MCP memory servers is that installing one gives your agent persistent memory. It does not. It gives your agent the ability to have persistent memory. The agent still has to decide when to save, what to save, what to search for, and how to interpret the results.

This is the write-path problem I described in an earlier post, and MCP does not solve it. The protocol provides the plumbing. The agent still has to turn on the faucet.

Consider what happens in practice. You install Engram, configure it as an MCP server, and start a coding session. Engram sits there with 19 tools ready to go. The agent can call mem_save at any time. But nothing in the MCP specification tells the agent when to call it.

The same applies to retrieval. Engram provides mem_search, but the agent has to decide to call it. If the agent does not search its memory at the start of a session, the memories might as well not exist. If the agent searches for the wrong thing, it gets the wrong memories. The retrieval quality depends entirely on the agent’s ability to formulate a good query, which depends on the agent knowing what it does not know.

This is why the most successful MCP memory deployments pair the server with explicit instructions in the agent’s system prompt. Token Savior ships with a detailed system prompt that tells Claude Code exactly when to call each tool and what to pass. Engram provides session lifecycle hooks that fire automatically. mcp-memory-service provides agent-specific documentation for LangGraph, CrewAI, and AutoGen.

The protocol is necessary but not sufficient. You still need the orchestration layer that decides when and how to use it.

The Security Surface

I covered memory security in depth in a previous post, but MCP introduces a specific angle worth revisiting: the protocol itself expands the attack surface.

MCP memory servers that expose HTTP endpoints (mcp-memory-service, Engram Cloud, Nocturne with PostgreSQL) can be misconfigured to listen on 0.0.0.0. The context endpoint, designed to serve rich structured data to LLMs, becomes accessible to anyone on the network. The Orca Security research team documented this exact scenario in their analysis of MCP security risks.

The supply chain risk is also amplified. An MCP memory server is a dependency that has write access to your agent’s knowledge. A compromised server could poison memories, exfiltrate data, or inject false observations. The X-Agent-ID header in mcp-memory-service provides some isolation, but it relies on the client sending the correct value. An attacker who can intercept or replay MCP messages can impersonate any agent.

The community response has been encouraging. mcp-memory-service supports OAuth 2.0 with Dynamic Client Registration (DCR). Engram Cloud uses project-scoped authentication. The official MCP specification now includes authentication guidance. But the default configuration for most memory servers is still “trust everything on localhost,” which is fine for development and dangerous for production.

Practical Takeaways

If you are building or configuring an agent memory system with MCP today, here is what I would recommend based on the current ecosystem:

Start with Engram if you want local-first simplicity. A single binary, SQLite storage, FTS5 search, 19 tools, and it works with every major coding agent out of the box. Install it in 30 seconds with Homebrew.

Use mcp-memory-service if you need multi-agent coordination. The knowledge graph with typed edges, agent-scoped tagging, and 76-endpoint REST API make it the best choice for teams running multiple agents that need to share context.

Consider Token Savior Recall if you primarily care about coding performance. The benchmark numbers are real, and the progressive disclosure contract is a genuinely novel approach to token-efficient memory retrieval.

Do not underestimate the write-path problem. Your MCP memory server is useless without explicit instructions telling the agent when and how to store memories. Invest time in your system prompt and session hooks.

Secure your memory endpoint. If your MCP memory server exposes HTTP, bind it to 127.0.0.1, not 0.0.0.0. Use OAuth if you need remote access. Treat your memory endpoint like the sensitive database it is.

Design for portability. The whole point of MCP is decoupling. Store your memories in a server-agnostic format and avoid vendor-specific features that would lock you into one implementation. JSONL, SQLite, and standard REST APIs give you the most flexibility.

What Is Next

MCP is still evolving rapidly. The specification itself is under active development, and the memory server ecosystem is barely a year old. The most interesting direction is the convergence of MCP with Google’s A2A (Agent-to-Agent) protocol. MCP handles how an agent talks to its tools and memory. A2A handles how agents talk to each other. Together, they form the two halves of a complete agent communication stack.

I will be covering that convergence in a future post. For now, the key insight is this: MCP did for agent memory what USB-C did for peripherals. It did not make the devices better. It made them interchangeable. And that interoperability is what turns a collection of isolated, forgetful agents into a coherent system that can actually learn.

Previous post in the series: Markdown-First Memory: The OpenClaw Model and Why It Changes Everything