MCP Memory Service
The MCP Memory Service provides semantic memory and persistent storage for Claude Desktop. Key capabilities include:
Store information with optional metadata tags
Retrieve memories using semantic search with similarity scores
Search by tags to find stored memories
Time-based recall using natural language expressions
Find memories via exact content match
Manage duplicates by detecting and removing them
Database operations: optimization, health monitoring, statistics
Memory management: delete specific memories or tagged sets
Data protection: create automatic backups
Debug tools for analyzing retrieval processes
Cross-platform compatibility with hardware-aware optimization
Mentioned as a potential cloud storage option where users should ensure sync is complete before accessing from another device.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Memory Servicesearch for my notes about authentication setup"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-memory-service
Persistent Shared Memory for AI Agent Pipelines
Open-source memory backend for AI agents — REST API, MCP, OAuth, CLI, dashboard. One self-hosted service, every transport. Agents store decisions, share causal knowledge graphs, and retrieve context in 5ms — without cloud lock-in or API costs.
Works with LangGraph · CrewAI · AutoGen · any HTTP client · Claude Desktop · OpenCode
Related MCP server: memcp
Why Agents Need This
Your AI assistant forgets everything when you start a new chat. You spend 10 minutes re-explaining your architecture. Again. MCP Memory Service captures project context, architecture decisions, and code patterns automatically — new sessions start with everything already known.
Without mcp-memory-service | With mcp-memory-service |
Each agent run starts from zero | Agents retrieve prior decisions in 5ms |
Memory is local to one graph/run | Memory is shared across all agents and runs |
You manage Redis + Pinecone + glue code | One self-hosted service, zero cloud cost |
No causal relationships between facts | Knowledge graph with typed edges (causes, fixes, contradicts) |
Context window limits create amnesia | Autonomous consolidation compresses old memories |
Key capabilities for agent pipelines:
Framework-agnostic REST API — 76 endpoints, no MCP client library needed
Knowledge graph — agents share causal chains, not just facts
X-Agent-IDheader — auto-tag memories by agent identity for scoped retrievalconversation_id— bypass deduplication for incremental conversation storageSSE events — real-time notifications when any agent stores or deletes a memory
Embeddings run locally via ONNX — memory never leaves your infrastructure
🚀 Get Started in 60 Seconds
Not sure which setup fits your needs? See the Setup Guide — a decision tree walks you to the right path in under a minute.
1. Install:
pip install mcp-memory-service2. Configure your AI client:
Add to your config file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"memory": {
"command": "memory",
"args": ["server"]
}
}
}Restart Claude Desktop. Your AI now remembers everything across sessions.
claude mcp add memory -- memory serverRestart Claude Code. Memory tools will appear automatically.
MCP_ALLOW_ANONYMOUS_ACCESS=true memory server --http
# REST API running at http://localhost:8000import asyncio
import httpx
BASE_URL = "http://localhost:8000"
async def main():
async with httpx.AsyncClient() as client:
# Store — auto-tag with X-Agent-ID header
await client.post(f"{BASE_URL}/api/memories", json={
"content": "API rate limit is 100 req/min",
"tags": ["api", "limits"],
}, headers={"X-Agent-ID": "researcher"})
# Stored with tags: ["api", "limits", "agent:researcher"]
# Search — scope to a specific agent
results = await client.post(f"{BASE_URL}/api/memories/search", json={
"query": "API rate limits",
"tags": ["agent:researcher"],
})
print(results.json()["memories"])
asyncio.run(main())Framework-specific guides: docs/agents/
Start the HTTP API:
MCP_ALLOW_ANONYMOUS_ACCESS=true memory server --httpInstall the local plugin:
git clone https://github.com/doobidoo/mcp-memory-service.git
cd mcp-memory-service
mkdir -p ~/.config/opencode/plugins
cp opencode/memory-plugin.js ~/.config/opencode/plugins/
cp opencode/memory-plugin.config.example.json ~/.config/opencode/memory-plugin.jsonOpenCode automatically loads local plugins from ~/.config/opencode/plugins/ and .opencode/plugins/.
Optional: register the /memory slash command in ~/.config/opencode/opencode.json to query status, search, and health from inside the TUI:
{
"command": {
"memory": {
"description": "Show MCP Memory Service status. Usage: /memory, /memory search <query>, /memory health",
"template": ""
}
}
}See OpenCode integration guide for configuration, project-local installs, slash command details, TUI toasts, and current limitations.
The current OpenCode integration ships as repository files for the local plugin directory. If you installed only the PyPI package, clone the repository once to copy the plugin files.
The plugin defaults to
http://127.0.0.1:8000, butmemoryService.endpointandOPENCODE_MEMORY_ENDPOINTlet you target any reachable HTTP deployment.
Unlike desktop-only MCP servers, mcp-memory-service supports Remote MCP: persistent memory directly in your browser, on any device — no Claude Desktop required. Enterprise-ready (OAuth 2.0 + HTTPS + CORS), self-hosted or cloud-hosted.
# 1. Start server with Remote MCP
MCP_STREAMABLE_HTTP_MODE=1 \
MCP_SSE_HOST=0.0.0.0 \
MCP_OAUTH_ENABLED=true \
python -m mcp_memory_service.server
# 2. Expose publicly (Cloudflare Tunnel)
cloudflared tunnel --url http://localhost:8765
# 3. Add connector in claude.ai Settings → Connectors with the tunnel URL
# OAuth flow will handle authentication automaticallyProduction Setup: Remote MCP Setup Guide (Let's Encrypt, nginx, Docker, firewall). Step-by-Step Tutorial: Blog: 5-Minute claude.ai Setup | Wiki Guide
For production deployments, team collaboration, or cloud sync:
git clone https://github.com/doobidoo/mcp-memory-service.git
cd mcp-memory-service
python scripts/installation/install.pyChoose from:
SQLite (local, fast, single-user)
Cloudflare (cloud, multi-device sync)
Hybrid (best of both: 5ms local + background cloud sync)
Milvus (dedicated vector DB — Milvus Lite file, self-hosted, or Zilliz Cloud)
ℹ️ For long-lived services (MCP servers, web backends, notebook sessions), prefer Docker Milvus or Zilliz Cloud over Milvus Lite. See docs/milvus-backend.md for why.
⚡ Works With Your Favorite AI Tools
🤖 Agent Frameworks (REST API)
LangGraph · CrewAI · AutoGen · Any HTTP Client · OpenClaw/Nanobot · Custom Pipelines
🖥️ CLI & Terminal AI (MCP)
Claude Code · Gemini CLI · Gemini Code Assist · OpenCode · Codex CLI · Goose · Aider · GitHub Copilot CLI · Amp · Continue · Zed · Cody
🎨 Desktop & IDE (MCP)
Claude Desktop · VS Code · Cursor · Windsurf · Kilo Code · Raycast · JetBrains · Replit · Sourcegraph · Qodo
💬 Chat Interfaces (MCP)
ChatGPT (Developer Mode) · claude.ai (Remote MCP via HTTPS)
Works seamlessly with any MCP-compatible client or HTTP client - whether you're building agent pipelines, coding in the terminal, IDE, or browser.
💡 NEW: ChatGPT now supports MCP! Enable Developer Mode to connect your memory service directly. See setup guide →
✨ Features
🧠 Persistent Memory – Context survives across sessions with semantic search
🔍 Smart Retrieval – Finds relevant context automatically using AI embeddings
⚡ 5ms Speed – Instant context injection, no latency
🔄 Multi-Client – Works across 25+ AI applications
☁️ Cloud Sync – Optional Cloudflare backend for team collaboration
🔒 Privacy-First – Local-first, you control your data
📊 Web Dashboard – Visualize and manage memories at http://localhost:8000
🧬 Knowledge Graph – Interactive D3.js visualization of memory relationships
🏠 Homelab Quality Scoring – Point scoring at any OpenAI-compatible endpoint (Ollama, LiteLLM, vLLM)
🔗 Entity Extraction – Auto-links @mentions, #tags, URLs, and file paths from memory content to a queryable entity graph
💡 Insight Cards – Consolidation detects patterns, trends, and knowledge gaps across your memory corpus and surfaces them as structured insights
🏷️ Tag Match Filtering – tag_match=AND/OR on memory_search for precise multi-tag queries
🖥️ Dashboard Preview
8 Dashboard Tabs: Dashboard • Search • Browse • Documents • Manage • Analytics • Quality • API Docs
🎬 Watch the Web Dashboard Walkthrough on YouTube — semantic search, tag browser, document ingestion, analytics, quality scoring, and API docs in under 2 minutes. 📖 See Web Dashboard Guide for complete documentation.
Real-World Deployments
Multi-Agent Cluster with Shared Memory
"After I work with one of the cluster agents on something I want my local agent to know about, the cluster agent adds a special tag to the memory entry that my local agent recognizes as a message from a cluster agent. So they end up using it as a comms bridge — and it's pretty delightful." — @jeremykoerber (originally GitHub issue #591)
A 5-agent openclaw cluster uses mcp-memory-service as shared state and as an inter-agent messaging bus — without any custom protocol. Cluster agents tag memories with a sentinel like msg:cluster, and the local agent filters on that tag to receive cross-cluster signals. The memory service becomes the coordination layer with zero additional infrastructure.
# Cluster agent stores a learning and flags it for the local agent
await client.post(f"{BASE_URL}/api/memories", json={
"content": "Rate limit on provider X is 50 RPM — switch to provider Y after 40",
"tags": ["api", "limits", "msg:cluster"], # sentinel tag
}, headers={"X-Agent-ID": "cluster-agent-3"})
# Local agent polls for cluster messages
results = await client.post(f"{BASE_URL}/api/memories/search", json={
"query": "messages from cluster",
"tags": ["msg:cluster"],
})This pattern — tags as inter-agent signals — emerges naturally from the tagging system and requires no additional infrastructure.
Self-Hosted Docker Stack with Cloudflare Tunnel
"The quality of life that session-independent memory adds to AI workflows is immense. File-based memory demands constant discipline. Semantic recall from a live database doesn't. Storing data on my own hardware while making it remotely accessible across platforms turned out to be a feature I didn't know I needed." — @PL-Peter (originally GitHub discussion #602)
A production-tested self-hosted deployment using Docker containers behind a Cloudflare tunnel, with AuthMCP Gateway handling authentication:
Layer | Role |
Cloudflare Tunnel | Name-based routing, subnet-based access control, authentication before hitting self-hosted resources |
AuthMCP Gateway | Auth/aggregation with locally managed users, admin UI, per-user MCP server access control, bearer token auth |
mcp-memory-service | Two Docker containers sharing one SQLite backend — one for MCP, one for the web UI (document ingestion) |
Security best practices for this setup:
Use Cloudflare ZeroTrust with subnet-based access control (e.g., allow Anthropic subnets + your own IPs)
Add Client IP Address Filtering to all Cloudflare API tokens (Dashboard → My Profile → API Tokens → Edit → Client IP Address Filtering) to limit abuse if a token leaks
If using IPv6, include your IPv6 /64 network in the allowlist (Python prefers IPv6 by default)
For long-running browser sessions, request the
offline_accessscope during authorization to receive a rotatingrefresh_token(lifetime viaMCP_OAUTH_REFRESH_TOKEN_EXPIRE_DAYS, default 30 days). Without this scope, access tokens are the only credential — extendMCP_OAUTH_ACCESS_TOKEN_EXPIRE_MINUTESup to1440(24h) if you need longer single-shot sessions.Consider an auth proxy like AuthMCP or mcp-auth-proxy for robust session management
Fully-Offline Shared Memory Across Four Agents
"mcp-memory-service has been the shared memory layer for all my coding agents since February — Claude Code, Claude Desktop, Codex CLI and OpenCode all talk to the same sqlite-vec DB over stdio on my Mac. ~5,900 memories and counting. Every session starts by pulling a bootstrap profile from memory and ends by committing a session summary, so any agent can pick up where another left off — work context, project state, even a 'mistakes I made before' log. It's the closest thing to persistent identity my agents have." — Mingjian Shao (AI PM & AI consultant, via LinkedIn)
A single local sqlite-vec database on a Mac acts as the shared brain for four different agents over stdio — no server, no cloud. Embeddings run fully offline via a local Qwen3-Embedding-0.6B (1024-dim) on MPS, with daily automated backups, scheduled consolidation, and the dashboard kept alive by a LaunchAgent.
Lesson worth stealing (offline embeddings): when the custom embedding model fails to load, the service can silently fall back to the default MiniLM (384-dim) and subsequent writes fail with dimension mismatches. If you pin a non-default embedding model, also pin the model path and set the Hugging Face offline flags so a load failure surfaces loudly instead of degrading — then a dimension mismatch can't corrupt the store.
Comparison with Alternatives
vs. Commercial Memory APIs
Mem0 | Zep | DIY Redis+Pinecone | mcp-memory-service | |
License | Proprietary | Enterprise | — | Apache 2.0 |
Cost | Per-call API | Enterprise | Infra costs | $0 |
🌐 claude.ai Browser | ❌ Desktop only | ❌ Desktop only | ❌ | ✅ Remote MCP |
OAuth 2.0 + DCR | ❓ Unknown | ❓ Unknown | ❌ | ✅ Enterprise-ready |
Streamable HTTP | ❌ | ❌ | ❌ | ✅ (SSE also supported) |
Framework integration | SDK | SDK | Manual | REST API (any HTTP client) |
Knowledge graph | No | Limited | No | Yes (typed edges) |
Auto consolidation | No | No | No | Yes (decay + compression) |
On-premise embeddings | No | No | Manual | Yes (ONNX, local) |
Privacy | Cloud | Cloud | Partial | 100% local |
Hybrid search | No | Yes | Manual | Yes (BM25 + vector) |
MCP protocol | No | No | No | Yes |
REST API | Yes | Yes | Manual | Yes (76 endpoints) |
vs. MCP-Native Alternatives
MemPalace is an MCP-native alternative that went viral in April 2026 with strong LongMemEval claims. A community code review (Issue #27) subsequently showed that the headline numbers reflect the underlying vector store rather than the advertised Palace architecture, and the maintainers acknowledged most points. We keep the comparison here for transparency, but readers should interpret the scores with that context in mind.
MemPalace | mcp-memory-service | |
LongMemEval R@5 (raw ChromaDB, zero LLM) | 96.6%¹ | 86.0% (session) / 80.4% (turn) |
LongMemEval R@5 (with reranking) | 100%² | — |
Storage granularity | Session-level | Turn-level + session-level |
Team / multi-device sync | ❌ Local only | ✅ Cloudflare sync |
REST API / Web dashboard | ❌ | ✅ |
OAuth 2.1 + multi-user | ❌ | ✅ |
Knowledge graph | ❌ | ✅ (typed edges) |
Auto consolidation | ❌ | ✅ (decay + compression) |
Compatible AI tools | Claude-focused | 25+ tools |
License | MIT | Apache 2.0 |
Why the benchmark gap? MemPalace stores whole sessions as single units — LongMemEval's "which session contains the answer?" question is answered structurally by that granularity. mcp-memory-service defaults to turn-level storage for fine-grained retrieval; using memory_store_session brings our score to 86.0% R@5. And per Issue #27, the 96.6% headline measures a raw ChromaDB baseline with the Palace architecture inactive — an apples-to-apples architectural comparison is not possible with the published numbers.
¹ Measured in MemPalace "raw mode" (plain text in ChromaDB with default embeddings). Per Issue #27, the Palace structural features are bypassed in this configuration.
² 100% result uses optional LLM reranking (~500 API calls) on a partially tuned test set. Clean held-out score (as reported by the maintainers): 98.4% R@5.
📊 Retrieval Benchmarks
Three benchmarks measure retrieval quality (all-MiniLM-L6-v2, 384d embeddings, zero LLM API calls):
LongMemEval (500 questions, ~45–62 distractor sessions per question):
Question Type | R@5 | R@10 | NDCG@10 | MRR |
Overall | 80.4% | 90.4% | 82.2% | 89.1% |
single-session-assistant | 100.0% | 100.0% | 99.3% | 99.1% |
knowledge-update | 84.6% | 96.8% | 86.2% | 95.5% |
single-session-user | 91.4% | 92.9% | 86.0% | 83.8% |
temporal-reasoning | 72.0% | 84.1% | 75.1% | 85.7% |
multi-session | 70.7% | 86.0% | 77.6% | 89.4% |
DevBench (practical developer workflow queries):
Category | Recall@5 | MRR |
Overall | 91.1% | 0.861 |
exact | 100% | 1.000 |
semantic | 80.0% | 0.700 |
cross-type | 90.0% | 0.867 |
LoCoMo (ACL 2024 long-term conversational memory):
Category | Recall@5 | MRR |
Overall | 49.7% | 0.414 |
multi-hop | 72.0% | 0.600 |
temporal | 33.5% | 0.274 |
Run benchmarks: python scripts/benchmarks/benchmark_longmemeval.py, python scripts/benchmarks/benchmark_devbench.py, python scripts/benchmarks/benchmark_locomo.py
🛠️ Configuration Highlights
Full reference: Configuration Guide
Server Lifecycle (CLI)
memory launch # Start HTTP server in background (127.0.0.1:8000)
memory launch --port 8192 # Custom port
memory info # Status and health
memory logs --lines 50 # Recent logs
memory stop # Stop serverThese commands are optimized for fast startup and avoid loading heavy ML dependencies unless needed.
⚠️ Security Note: By default, the server binds to
127.0.0.1(localhost only).--host 0.0.0.0/MCP_HTTP_HOST=0.0.0.0exposes the API to your network — do this only in trusted environments with proper authentication and firewall rules. For untrusted networks, use TLS termination (reverse proxy with HTTPS) or VPN overlays.
Embedding Model Selection
The default model (all-MiniLM-L6-v2) works well for English-only content. If you store memories in other languages, switch to a multilingual model:
Model | Languages | Dimensions | Use case |
| English only | 384 | Fastest, English-only deployments |
| 50+ languages | 384 | Mixed-language or non-English content |
export MCP_EMBEDDING_MODEL=paraphrase-multilingual-MiniLM-L12-v2⚠️ Switching models requires re-embedding existing memories (cross-language cosine drops from ~0.95 to ~0.10 otherwise): stop the service, run
python scripts/maintenance/regenerate_embeddings.pywith the new model env var, restart.
Quality Scoring with Your Local LLM
Homelab / self-hosted quality scoring (v10.45.0+): set MCP_QUALITY_AI_PROVIDER=openai-compatible to score memories with your local LLM instead of ONNX or a cloud API:
MCP_QUALITY_AI_PROVIDER=openai-compatible
MCP_QUALITY_AI_BASE_URL=http://localhost:11434/v1 # Ollama
MCP_QUALITY_AI_MODEL=qwen2.5:7b-instruct
# MCP_QUALITY_AI_API_KEY=ollama # optionalRecommended models: qwen2.5:7b-instruct (Ollama), mlx-community/Qwen2.5-7B-Instruct-4bit (MLX), or any instruct model via LiteLLM proxy. On endpoint failure, scoring falls back to implicit signals automatically.
Local quality scoring in a container. The standard and :slim images ship onnxruntime but not the exported ONNX models, and not the torch/transformers needed to export them — so MCP_QUALITY_AI_PROVIDER=local needs the models supplied from outside. There is no published :quality-cpu tag; it was retired rather than rebuilt per release, because the ONNX models are version-independent and rebuilding them on every patch was waste. Three supported paths:
Export once, mount the directory (recommended). Run
scripts/quality/export_deberta_onnx.pyon any machine withtorch/transformers, then mount the result and pointMCP_QUALITY_ONNX_MODEL_DIRat it.Build the image yourself —
tools/docker/Dockerfile.quality-cpustays in the tree and does the export at build time.Use an endpoint you already run —
MCP_QUALITY_AI_PROVIDER=openai-compatibleagainst Ollama, vLLM, or a LiteLLM proxy, as configured above. No models to manage.
Recipes for all three, including a verified non-root read-only-rootfs Kubernetes setup: tools/docker/README.md.
🌐 SHODH Ecosystem Compatibility
MCP Memory Service is fully compatible with the SHODH Unified Memory API Specification v1.0.0: all SHODH implementations share the same memory schema (emotional metadata, episodic memory, source tracking, quality scoring), so memories export/import across implementations with full fidelity.
Implementation | Backend | Embeddings | Use Case |
RocksDB | MiniLM-L6-v2 (ONNX) | Reference implementation | |
shodh-cloudflare | Cloudflare Workers + Vectorize | Workers AI (bge-small) | Edge deployment, multi-device sync |
mcp-memory-service (this) | SQLite-vec / Hybrid | MiniLM-L6-v2 (ONNX) | Desktop AI assistants (MCP) |
📰 In the Media
Agents Overdrawn at the Memory Bank — Heavybit's Humans in the Loop deep dive talks to maintainer Heinrich Krupp about agent amnesia, why persistent memory is the missing infrastructure layer for agentic systems, and how mcp-memory-service closes the gap with local vector storage, ONNX embeddings, and typed knowledge graphs.
"Your project has inspired me in many ways. In my view, it's the best implementation of MCP memory I've found so far." — Michał Zubkowicz
AI Tinkerers Zürich Talk (full video) — Maintainer Heinrich Krupp presents mcp-memory-service to the AI Tinkerers Zürich meetup, covering persistent memory architecture, semantic search, and multi-agent memory sharing.
Latest Release: v11.11.0 (September 5, 2026)
MINOR: three critical advisories closed (remote transports served filesystem tools, SSE had no authentication, open DCR handed out read-write tokens), and development moved back to GitHub
What's New:
fix(security): filesystem tools were reachable over remote transports (GHSA-7crr-2r7w-cpfm).
memory_harvestandmemory_ingesttake a caller-controlled path, and thelocal_only_tools()filter ran in only one of three transports. It now lives inMemoryServer.list_tools()andcall_tool(), so every transport inherits it.fix(security): the SSE transport had no authentication (GHSA-2hh8-qjxc-43x3).
/sseand/messages/both reach the full tool surface and neither was gated. The check was a closure inside another transport's function and simply not reachable from SSE.fix(security): open DCR handed out read-write tokens (GHSA-6mvm-q4j3-27qg). A caller could register itself as a confidential client and exchange its own credentials for a
read writetoken without the owner being consulted.Development moved back to GitHub. Issues, PRs, CI, releases and the wiki are here again; the Forgejo workflows were ported to GitHub Actions. Codeberg stays readable as an archive so old links resolve.
Upgrade notes — two deliberate behaviour changes, both fail loudly rather than degrading quietly:
client_credentialsis refused while Dynamic Client Registration is open. SetMCP_DCR_REGISTRATION_KEYand register with it, or useauthorization_codewith PKCE (the flow Claude.ai Remote MCP uses, unaffected).An MCP transport refuses to start on a non-loopback bind with no authentication configured. Set
MCP_API_KEY, enable OAuth, or bind to127.0.0.1.
Previous Releases (v11 series — full history for all earlier versions in CHANGELOG.md):
v11.10.0 - MINOR: clustering fails loudly instead of silently degrading without scikit-learn, a consolidation time-horizon fix, three hook fixes (#329, #325, #321, #323, #330) (August 28, 2026)
v11.9.0 - MINOR: transformers 5.x closes two high-severity advisories with no 4.x fix, plus a quality-system bug the new ml-extras CI job caught on day one (#305, #316, #307, #303) (August 27, 2026)
v11.8.5 - PATCH: two Docker fixes reproduced against the published images, plus a timezone-boundary bug in timeframe deletion, external contributor (#295, #297, #237, #298) (August 25, 2026)
v11.8.4 - PATCH: hybrid deployment was burning through Cloudflare's D1 free-tier read allowance, plus three smaller correctness fixes (#289, #290, #287) (August 25, 2026)
v11.8.3 - PATCH: reachable MCP transport advisory (CVE-2026-52869), HTTPS silently downgraded to HTTP on every restart, API key written to the access log (#277, #279, #285) (August 24, 2026)
v11.8.2 - PATCH: OAuth
client_credentialsbypassed the owner API key (GHSA-5p27-64mv-pr73, CVSS 9.1) (August 23, 2026)v11.8.1 - PATCH: eight fixes on top of v11.8.0, six from timkjr — OAuth issuer validation and Docker HTTPS behaviour (#239, #231) (August 22, 2026)
v11.8.0 - MINOR: the knowledge-graph layer actually works now — entity extraction was discarding every memory tag, and two features were gated on a storage attribute nothing ever set (#218, #219) (August 9, 2026)
v11.7.0 - MINOR: three TLS certificate-verification bypasses gated behind explicit opt-in, a committed credential removed (#198, #210, #197/#200) (August 5, 2026)
v11.6.1 - PATCH: harvest classifier provider chain fix (#180), Claude Code plugin manifest at 1.0.2 (#195) (August 3, 2026)
v11.6.0 - MINOR: migration no longer drops the knowledge graph and derived beliefs when re-embedding (#189), locale-aware NER/NLI via YAML plugins (#54), Docker images ship the maintenance and migration scripts (#188) (August 2, 2026)
v11.5.5 - PATCH: standard Docker image ships tokenizers so the ONNX backend actually loads (#162, #163, #164) (July 24, 2026)
v11.5.4 - PATCH: web dashboard GitHub references replaced with Codeberg (#158, #159, @sunnyagain) (July 22, 2026)
v11.5.3 - PATCH: Claude Code hooks config resolution under Marketplace install + graph orphan-prune
has_entityfix + belief-derivation noise filter (#155, #156, #150, #151, #121, #152, @filhocf, @tecnobrat) (July 22, 2026)v11.5.2 - PATCH: sqlite_vec
delete_memoryproxy fix + hash-embedding fallback guard + embedding-dimension mismatch guard (#140, #135, #143, @jonatanbellido, @nxxxsooo) (July 15, 2026)v11.5.1 - PATCH: multi-store migration dimension safety + embedding-backend verification in
memory status(#134, #136, @nxxxsooo) (July 15, 2026)v11.5.0 - MINOR: conditional temporal decay + functional belief derivation + consolidation clustering fix + bootstrap belief injection (#123, #124, #126, #127, @filhocf) (July 10, 2026)
v11.4.0 - MINOR: memory merge action + pluggable domain NER extractors + mcpmemory.services landing page (#100, #54, @filhocf) (July 4, 2026)
v11.3.3 - PATCH: fix(cli): memory CLI commands respect MCP_HTTPS_ENABLED (fixes silent failures when TLS is enabled) (July 1, 2026)
v11.3.2 - PATCH: declare numpy>=1.24.0 as core dependency (fixes uvx bare install crash, closes #98) (June 30, 2026)
v11.3.1 - PATCH: claude-hooks noise reduction - auto-capture moved to Stop event and gated on substantive content (June 22, 2026)
v11.3.0 - MINOR: Interactive 3D knowledge graph visualization (Orrery-inspired), node cap 100→1000/max 500→10000 (June 21, 2026)
v11.2.0 - MINOR: OAuth security hardening (#91), sqlite-vec rowid collision fix (#90), composite graph scoring (#55/#77, @filhocf), OpenCode XDG state dir fix (#84) (June 20, 2026)
v11.1.0 - MINOR: two-phase query API aggregation + maintenance script hardening (PR #78, @filhocf) (June 18, 2026)
v11.0.0 - MAJOR: legacy tool-name alias removal + optional ML dependencies / ONNX-first fallback (PR #72, #49, #71) (June 13, 2026)
Full version history: CHANGELOG.md | Older versions (v10.36.3 and earlier) | All Releases
📚 Documentation & Resources
Agent Integration Guides – LangGraph, CrewAI, AutoGen, HTTP generic
OpenCode Integration – Local plugin for memory retrieval and context injection
Remote MCP Setup (claude.ai) – Browser integration via HTTPS + OAuth
Setup Guide – Decision tree + step-by-step paths for all use cases
Configuration Guide – Backend options and customization
Architecture Overview – How it works under the hood
Team Setup Guide – OAuth and cloud collaboration
Token-Efficient Retrieval – Bounding search responses (
limit,max_response_chars) and thememory_explore→memory_detailknowledge mapKnowledge Graph Dashboard – Interactive graph visualization guide
Memory Type Ontology – Built-in taxonomy and
MCP_CUSTOM_MEMORY_TYPESenv varMigration Guide – Upgrading between major versions (v9+ migrations run automatically on restart)
Troubleshooting – Common issues and solutions
Technical Video Demo (2 min) – Performance, architecture, AI/ML intelligence
API Reference – Programmatic usage
Wiki – Complete documentation
– AI-powered documentation assistant
MCP Starter Kit – Build your own MCP server using the patterns from this project
🤝 Contributing
We welcome contributions! See CONTRIBUTING.md for guidelines.
Who authors this project, who holds copyright, and what every change passes before
it reaches main: AUTHORSHIP.md.
Quick Development Setup:
git clone https://github.com/doobidoo/mcp-memory-service.git
cd mcp-memory-service
pip install -e . # Editable install
pytest tests/ # Run test suiteAvailable Tools
3 toolsretrieve_memoryC
Find relevant memories based on query
| Name | Required | Description | Default |
|---|---|---|---|
| n_results | No | ||
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It mentions 'find relevant memories' but doesn't disclose how relevance is scored, whether results are paginated, if there are rate limits, authentication needs, or what happens on failure. The description lacks details needed for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Find relevant memories'), though it could be more structured with additional context. For its brevity, it communicates the essence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and two parameters, the description is incomplete. It doesn't explain what 'memories' are, how they're retrieved, the return format, or error handling. For a tool with query and result-limit parameters, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter-specific information. It mentions 'query' generally but doesn't explain its format, constraints, or how 'n_results' affects output. The description fails to clarify semantics beyond the bare schema, leaving parameters poorly understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find relevant memories based on query' states the general purpose (verb 'find' + resource 'memories') but lacks specificity about what 'memories' are or how relevance is determined. It distinguishes from 'store_memory' but not clearly from 'search_by_tag' (both involve finding memories). The purpose is understandable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_by_tag'. The description implies usage for query-based retrieval, but there's no explicit mention of when-not-to-use, prerequisites, or comparison with siblings. Usage is implied from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_tagC
Search memories by tags
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Search' which implies a read operation, but doesn't disclose behavioral traits like whether it's paginated, returns partial matches, requires authentication, or has rate limits. This is inadequate for a search tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks information on return values, error conditions, and behavioral context, making it insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by tags' which hints at the 'tags' parameter, but doesn't add meaning beyond the schema's basic type information—no details on tag format, case sensitivity, or how multiple tags are combined (AND/OR). This partially compensates but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search memories by tags' clearly states the verb ('Search') and resource ('memories'), but it's vague about scope and doesn't distinguish from sibling tools like 'retrieve_memory'. It doesn't specify whether this searches all memories or a subset, or how it differs from the retrieval sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'retrieve_memory'. The description implies usage for tag-based searching but doesn't mention prerequisites, exclusions, or comparative contexts with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_memoryC
Store new information with optional tags
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'store new information' which implies a write/mutation operation, but doesn't specify permissions needed, whether storage is persistent, rate limits, or what happens on success/failure. This leaves significant gaps for a tool that appears to create data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the core purpose without any wasted words. Every element ('store', 'new information', 'optional tags') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 2 parameters (one nested), 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain what 'storing' entails operationally, what format the information should be in, how tags are used, or what the tool returns. The agent lacks critical context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'information' and 'optional tags' which loosely map to 'content' and 'metadata.tags', but doesn't explain the 'metadata.type' parameter at all or provide any format/constraint details. This partial coverage is insufficient given the schema's complexity with nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('store') and resource ('new information') with additional functionality ('with optional tags'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'retrieve_memory' or 'search_by_tag', which would require mentioning this is specifically for creating/adding new memories rather than retrieving or searching existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'retrieve_memory' or 'search_by_tag'. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage based solely on the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
- First observed
retrieve_memory - First observed
search_by_tag - First observed
store_memory
This server cannot be installed
TDQS
Each tool has a clearly distinct purpose: retrieve_memory finds memories based on content queries, search_by_tag filters by tags, and store_memory creates new entries. There is no overlap or ambiguity between these three operations.
All tools follow a consistent verb_noun pattern (retrieve_memory, search_by_tag, store_memory) with snake_case throughout. The naming is predictable and uniform across the set.
With only 3 tools, the set feels minimal but functional for a memory service. It covers basic operations (store, retrieve, search), but lacks advanced features like updating or deleting memories, which might be expected in a more comprehensive service.
The tools provide core CRUD-like operations for storing and retrieving memories, but there are notable gaps: no update_memory or delete_memory tools, which limits lifecycle management. Agents can work around this for basic use but may encounter dead ends for modifications.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides Claude AI with persistent, searchable memory management across sessions using SQL database, semantic analysis with multi-provider LLM support (Anthropic/Ollama), vector search via ChromaDB, and graph-based knowledge relationships through Neo4j integration.1-
- -licenseNot gradedqualityDmaintenanceProvides persistent memory for AI assistants like Claude, storing and retrieving information across conversations using a local SQLite database.-
- FlicenseAqualityCmaintenanceSupercharges Claude Desktop with persistent semantic memory, sandboxed file I/O, live web search, and local emotional intelligence using a local ChromaDB and Hugging Face model.6-
- AlicenseNot gradedqualityDmaintenanceProvides persistent, searchable memory for Claude Code using local SQLite, semantic embeddings, and full-text search, enabling Claude to recall and retrieve context across sessions and projects without external services.194MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/doobidoo/mcp-memory-service'
If you have feedback or need assistance with the MCP directory API, please join our Discord server