Wiring Up Memory MCP Myself: Bolting a Local Knowledge Graph Onto an AI's Session Amnesia

I got tired of explaining my project rules from scratch every time I opened a new chat, so I attached Memory MCP to my VS Code plus Cline setup. The short version: the repetitive explaining really did go down. What replaced it was a new chore — cleaning house on the memories. And I also learned that "Memory MCP" is not one thing.

What MCP and Memory MCP are

MCP (Model Context Protocol) is an open standard Anthropic released in November 2024 for connecting AI clients to external tools. Memory MCP is a memory-only server built on top of it, and it comes in roughly three flavors. If you don't know the difference, even the claim "it's stored locally" falls apart.

What I attached: the official knowledge-graph server

I picked the simplest official server. It works off a single local file with no separate account needed. I added it to my Cline config like this:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": "/home/jw/.cline-memory/memory.jsonl"
      }
    }
  }
}

The tools the server offers are entity creation (create_entities), relation creation (create_relations), adding observations (add_observations), reading the graph (read_graph), and node search (search_nodes). The concept is simple: make people, projects, and preferences into entities, hang observations off them, and link them to each other.

I dropped rules in while coding the way I normally do. Things like "In this project, state management is always Zustand." "The auth logic on the server I'm working on right now is JWT-based." The AI pulled the key points out of the conversation and stored them as entities and observations. That's from my own environment.

Three changes I actually felt

First, "finish what we started yesterday" worked. The next day in a new chat I typed "fix the login API permission error I left half-done yesterday," and it pulled up the stored context, read the relevant file, and went straight into the fix. No background explanation needed.

Second, my prompts got shorter. Since it already remembered my coding style and folder structure, one line like "make a new user profile component" produced code matching my existing rules.

Third, context got lighter. Instead of stuffing the whole project into the prompt every time, it just searched for the memories it needed — so responses got faster.

The downside: memories need cleaning

After a few days the store filled up with junk memories. Discarded code logic, passing ideas, that sort of thing. When stale memories are mixed in, the AI grabs the wrong context. Doing regular maintenance — deleting old observations with delete_observations, pruning entities — was essential. A memory-capable AI is convenient, but left alone it turns into a junk drawer.

The difference I wish I'd known before choosing

Hosted mem0 is convenient, but your memory lives in a Mem0 account rather than on your computer. The "stored in a local database" description only applies to the self-hosting type. On the other hand, mcp-memory-service is local-first and even has a dashboard, but it's storage-and-search focused, so lifetime management tools like update_memory and delete_memory are missing. If you want to automate the fixing-and-editing flow too, the official server or mem0 is the better call.

Verdict

It feels like having a partner who shares the project history, not a chatbot. Memory isn't free, though. You have to know where it's stored and who does the cleaning. Given those premises, going back to an AI that resets every time is hard.