Memory MCP solves the “every conversation starts from zero” problem. It gives the agent a local knowledge graph — entities, relations, observations — that persists between sessions. The model writes to it (“user prefers Postgres over MySQL”), reads from it next time (“what did I learn about this user before?”), and gradually builds a working model of you, your projects, your preferences.
What it produces: a JSON-backed graph with create_entities, create_relations, add_observations, search_nodes, read_graph. Local file by default — no cloud, no telemetry, no third-party data residency.
Best for: long-running founder-agent relationships where the agent should remember “we use Astro, we ship to Cloudflare, the brand voice rejects ‘leverage’ and ‘unlock,’ the active deal is X” without re-stating context each session.
Skip if: you already use a CRM, Notion, or Obsidian for that knowledge — duplicating it in Memory MCP creates two sources of truth that drift. Use the source of truth you have, exposed via Notion MCP.
Setup gotchas: the storage path matters. Default is project-local; an agent reading the graph only sees what’s in that path. Decide early: per-project memory (good for project-specific knowledge), or one global memory (good for personal preferences, but carries cross-project leakage risk). Pick one, document it.
Real-world workflow: I keep a per-project graph. First-day-of-project: “remember that this client is X, the deliverable is Y, the deadline is Z, the voice rules are in voice.md.” Every subsequent session, the agent reads the graph first. Onboarding cost per session: 2 seconds.
Compatible alternatives: Notion MCP for human-readable persistent context, plain CLAUDE.md for static project preferences. Memory MCP earns its keep when the data evolves session-over-session.
Prune the graph monthly. Stale memory is worse than no memory.