mcp-memory-service: the coding-agent memory with a real retrieval benchmark (86% R@5)
A plain-English guide to mcp-memory-service — the auto-capturing memory layer built specifically for Claude Code and Cursor sessions. Installs via uvx in 10 minutes. Benchmarked, not vibes.
Short version: mcp-memory-service is a purpose-built memory layer for coding agents. Install it once via uvx, restart your client, and it silently consolidates what your Claude Code or Cursor sessions actually do — files edited, architecture decisions, recurring patterns — into retrievable memory. Scores 86% recall at 5 on session retrieval, which is unusually strong. 10-minute install. By doobidoo, MIT licensed.
What is mcp-memory-service?
Most AI-agent memory tools are generic. mcp-memory-service is tuned for coding — specifically for the pattern where you open Claude Code, work on a feature, close it, and tomorrow open it again. The service watches your sessions (what files get touched, what architectural decisions you make, which code patterns recur) and consolidates that into a retrievable memory store.
The standout claim: 86% recall at 5 on session retrieval, from the project's published benchmark. That's unusually specific for an OSS memory tool — most ship on vibes alone. If you care about "will my agent actually find the right past context", this is the one that's shown its work.
Who this is for
- Engineering teams using Claude Code or Cursor daily.
- Anyone tired of re-explaining architecture to a fresh agent every morning.
- Teams that want retrieval-quality numbers, not promises.
- Solo developers who want persistent project memory without running a server.
Skip this if
You're a non-engineering user. This is tuned for code-session memory — for general org memory, look at mem0, supermemory, or the LLM-wiki pattern.
What problem it solves
The core pain of AI-assisted coding: context dies at the end of every session. You spend 45 minutes explaining to Claude why your auth flow looks weird, what the history of this file is, why you refactored this one way and not another. Tomorrow you do it again.
mcp-memory-service remembers that work for you. It captures decisions automatically — no manual tagging, no "save this memory" calls. The next session starts with context loaded. Your agent knows what it knows, and you skip the onboarding monologue.
How to install it (plain English)
- Make sure
uvis installed. Runpip install uvonce if you haven't.uvis Python's modern package runner — it lets us run MCP servers without globally installing them. - Add the MCP config. In your client's
.mcp.json:{ "mcpServers": { "memory-service": { "command": "uvx", "args": ["mcp-memory-service"] } } } - Restart your client. The first time,
uvxdownloads the service (~20 seconds). After that, it starts instantly. - Work normally. The service autocaptures in the background. No labels. No manual writes.
Full walkthrough: /memory/tools/mcp-memory-service.
What you can do with it (for a non-technical founder)
Even if you're not the one writing code, your engineering team using this means:
- No repeated onboarding — engineers stop re-explaining architecture every morning.
- Consistent decisions — the agent remembers "we use tRPC, not REST, because of X" so it doesn't push the wrong pattern.
- Faster feature shipping — new sessions start at velocity instead of from zero.
- Auditable memory — the service exposes tools to list and edit what's stored, so your team can catch wrong memories early.
What CLO adds on top
mcp-memory-service remembers what your agent needs to know about the codebase. Cognition CLO models what your team is retaining — about architecture, security practices, onboarding docs, the actual human knowledge. Different layers. The agent-memory layer is tactical (this session's context). The CLO layer is strategic (what your people actually know and forget).
FAQ
Does it work with both Claude Code and Cursor?
Yes. Any MCP-speaking client. Same config, different .mcp.json location per client.
How much does the autocapture cost in tokens?
The consolidation step uses an LLM. For a typical dev day, cost is single-digit dollars on Claude Haiku or GPT-4o-mini. Configurable in the service settings.
What does the memory store look like? Can I inspect it?
Yes. The service ships with tools to list, inspect, and edit memories. Your agent calls those tools; you can also call them directly from a terminal.
What's R@5 and why should I care?
Recall-at-5 = "given a query, does the right memory appear in the top 5 results?" The mcp-memory-service benchmark shows 86% on session-retrieval tasks, which is a published number you can verify in the repo.
Does it handle multiple projects?
Yes — it scopes memories per project path. Switching repos doesn't pollute one codebase's memory with another's context.
What if I want a simpler tool?
Look at memory-mcp (Anthropic's reference) or agentmemory. Both are simpler and more generic; neither is tuned for coding specifically.
Ready to install? Full walkthrough at /memory/tools/mcp-memory-service. Credit to @doobidoo for building and maintaining the project — star the repo if it earns your trust.
Share this post: