M3 Memory MCP server

🧠 m3 Memory

A memory layer that outlives your agents. You switch from Claude Code to Cursor, upgrade your model, start fresh next week — and everything your tools learned about your project is gone. You re-explain the same decisions, the same preferences, the same hard-won context, over and over.

m3 fixes that. It's a private, local-first memory your agents share and build on — so your project's knowledge accumulates instead of resetting every time the agent does. One memory store, on your machine, that your tools and agents read from and write to — whether that's Claude Code, Cursor, Gemini CLI, or any MCP-compatible agent.

Building something yourself? m3 is a memory backend, not a framework, and MCP is optional — every tool is a JSON-in/JSON-out CLI call, scriptable from any language, hook or CI job. Jump to the developer section ↓

Under the hood, m3 treats agent memory as a distributed-systems infrastructure problem, not a simple retrieval feature — a shared, evolving, bitemporal, contradiction-aware knowledge base that multiple heterogeneous agents and machines read and write, built to stay consistent over months and years.

The memory improves without being asked. m3 is not only a store you write to and read back. An autonomous Cognitive Loop (m3cognitiveloop.py) runs in the background and keeps working on what you already saved: deferred enrichment — classification, embedding, and entity extraction — runs off the hot path, so a write stays fast while the understanding of it deepens afterwards, and the loop builds an entity relationship graph from memories that arrived as plain text. Curation is m3's own work, not an LLM's. Near-duplicate detection is cosine similarity over embeddings against a threshold; decay and pruning are age-and-signal rules; and applying a curation plan — bulk deletes, merges, supersessions — is one deterministic function issuing direct SQL, with no model in the loop. That is deliberate: the apply step used to be an LLM agent, and it failed by looping single-row deletes across hundreds of IDs until it ran out of budget. An agent's judgement is still welcome for the genuinely subjective calls ("is this worth keeping?"), but it emits a plan and m3 executes it — one round-trip instead of N, and no model needed for the mechanical part.

Contradictions are caught on three paths, not one: deterministically on the write path (cosine similarity against a threshold, no model), by the loop's Reflector pass during enrichment (which writes supersedes edges), and by an explicit curation plan. Promotion of chat turns into long-term memory is the one thing that stays deliberate — nothing promotes on your behalf.

It runs where your data has to stay. A single pip install with no account, no API key, and no outbound calls — at home in a homelab, on a corporate or government network, or fully air-gapped. Embedding runs on your own hardware via a shared local embed server — one model in RAM that every m3 process reuses, rather than a copy per process — the store is a file you own, and installation works with no internet at all. On the metric that isolates the memory layer — retrieval accuracy, no answer model or judge involved — m3 reaches 99.2% session-hit-rate @ k=10 and 100% @ k=20 on LongMemEval-S.

🎬 Quick video overview

One decision saved from a conversation, then recalled by a different agent in a new session, on a different machine. Captioned throughout, so it reads fine muted.

https://github.com/user-attachments/assets/09ab194a-d2a0-4fe5-a7db-69ae8225e39b

Shortened. The full README is on GitHub.