mcp-memory-service: a self-hosted memory backend for agent pipelines

The problem it addresses: memory that dies with the process

Agent frameworks give you short-term state inside a run. They do not give you anything that survives the run. The README frames this bluntly: your assistant forgets everything when you start a new chat, and you re-explain your architecture again. The table it publishes contrasts a world where each agent run starts from zero against one where prior decisions are retrieved and memory is shared across agents and runs. The target user is not a chatbot hobbyist. It is someone running multi-agent pipelines where a researcher agent stores a constraint and a writer agent needs that constraint three steps later, possibly in a different process. The service also targets single-client use through MCP, so Claude Desktop and Claude Code can point at the same backend. The unifying claim is transport-agnostic storage: REST for pipelines, MCP for chat clients, CLI for humans.

How the pieces fit: SQLite vectors, a graph, and local ONNX embeddings

The repository topics name the storage layer: sqlite-vec and vector-database. That means the vector index lives in a SQLite file rather than a separate server. Embeddings are generated locally through ONNX, and the README states that memory never leaves your infrastructure. That is the architectural decision everything else follows from. There is no embedding API call in the write path, so ingestion cost is CPU time, not tokens. On top of the vector store sits a knowledge graph with typed edges. The README lists causes, fixes and contradicts as edge types, which is a different retrieval model from plain similarity search: an agent can ask what a fact contradicts, not only what it resembles. Autonomous consolidation is described as compressing old memories, which addresses the context window limit named in the comparison table. A dashboard is mentioned among the interfaces, and the README embeds a 3D graph visualisation hosted on the project site. I have not run any of this, so I can describe the shape of the system but not its retrieval quality.

Getting it running: pip, one config block, or an HTTP server

Installation is a single command: pip install mcp-memory-service. For Claude Desktop the README gives a JSON block to add to claude_desktop_config.json, with platform-specific paths for macOS, Windows and Linux, registering a server named memory whose command is memory with args ["server"]. For Claude Code the equivalent is claude mcp add memory -- memory server. For pipelines the service runs as an HTTP API with MCP_ALLOW_ANONYMOUS_ACCESS=true memory server --http, which the README says listens on http://localhost:8000. The Python example uses httpx to POST to /api/memories with a content field and a tags list, and POST to /api/memories/search with a query and a tags filter. Two headers and fields carry real behaviour. X-Agent-ID is appended to the stored tags as agent:researcher, so retrieval can be scoped per agent. conversation_id bypasses deduplication, which matters when you want incremental conversation turns stored verbatim rather than collapsed into one memory. The README also claims 76 REST endpoints, SSE events on store and delete, and OAuth 2.0 with DCR for remote MCP setups.

Deduplication is a default you will have to reason about

The existence of conversation_id as a deduplication bypass tells you the default behaviour: the service tries to avoid storing near-identical memories. For a decision log that is usually right. For a conversation transcript it is wrong, which is why the escape hatch exists. The risk is asymmetric. If deduplication is too aggressive, an agent that stores a corrected fact may find the correction merged into or discarded against the original, and the knowledge graph edge that should say contradicts never gets created. If it is too loose, consolidation has more to compress and retrieval returns near-duplicates. The README does not state the similarity threshold or the merge policy, so this is the first thing I would probe with real data before trusting it in a pipeline. It is a design trade-off, not a defect, but it is invisible from the quickstart.

Where it is the wrong tool

This is a stateful service. Your agents now have a runtime dependency that can be down, slow, or holding a SQLite lock. The quickstart runs the HTTP server with anonymous access enabled, which the README presents as a convenience flag for local use. Exposing that port beyond localhost without the OAuth path documented in docs/oauth-setup.md would hand your memory store to anyone who can reach it. There is a second boundary: the local ONNX embedding path trades API cost for CPU. On a machine without a usable accelerator, embedding a large backfill competes with the agents themselves. And if your workload is a single short-lived script that reads a file and exits, a persistent memory service is pure overhead. The README's 5ms retrieval figure has no stated hardware, dataset size or measurement method attached, so treat it as a design target rather than a number you can plan capacity around.

The alternative: a hosted vector database plus your own glue

The obvious comparison is a managed vector store such as Pinecone, which the README itself names in its comparison table alongside Redis. The difference in approach is where the work sits. A hosted vector database gives you an index and an SLA, and you write the schema, the agent-identity tagging, the deduplication logic, the graph edges and the consolidation job yourself. mcp-memory-service ships those as product features: the X-Agent-ID tagging convention, typed graph edges, autonomous consolidation, and an MCP server so a chat client can use the same store without custom code. The trade is control for operational burden. You get no vendor bill and no data leaving your infrastructure, and you take on backups, upgrades and uptime for a service your agents call on every step. For a team already running Redis and comfortable writing that glue, the service's value is smaller than the README implies. For a team that has never wanted to operate a vector database, it is the whole point.

Maintenance, releases and the licence

The project is active: the last push is dated 2026-09-10, and three releases landed on 2026-09-05, v11.9.0, v11.10.0 and v11.11.0. A major version in the elevens after that many point releases suggests a fast-moving surface, and the README's own docs tree (setup-guide.md, remote-mcp-setup.md, oauth-setup.md, docs/agents/) is where the version-specific details live. Upgrade cost is the real question. If you deploy via pip and pin a version, an upgrade is a restart, but the SQLite schema and the embedding model behind ONNX are the two things that can make an upgrade non-trivial, and the supplied material does not describe a migration procedure. Licence is Apache-2.0, which permits commercial use and modification and includes a patent grant; it also requires that you preserve notices and state changes. That is a summary of the identifier, not legal advice, and if you redistribute the service inside a product you should read the licence text and your own counsel's view.

Editorial conclusion

Adopt it if your agents run on your own machines and you want memory to survive a process restart without renting a vector database. Skip it if you need a managed SLA, if your agents are stateless by design, or if you cannot run a long-lived HTTP process next to them. Before you commit, check what the search endpoint returns when you store the same fact twice, and confirm that ONNX embedding generation on your hardware is fast enough for the write path, because the README's 5ms figure is not attached to a stated benchmark.

Official sources

1. doobidoo/mcp-memory-service on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases