Ein MCP-Server, der semantischen Speicher und persistente Speicherfunktionen für Claude Desktop mithilfe von ChromaDB und Satztransformatoren bereitstellt. Dieser Dienst ermöglicht Langzeitspeicherung mit semantischen Suchfunktionen und eignet sich daher ideal für die Kontextpflege über Konversationen und Instanzen hinweg.
Sprechen Sie mit TalkToGitHub mit dem Repo!
Related MCP server: memcp
Semantische Suche mit Satztransformatoren
Zeitbasiertes Erinnern in natürlicher Sprache (z. B. „letzte Woche“, „gestern Morgen“)
Tag-basiertes Speicherabrufsystem
Persistenter Speicher mit ChromaDB
Automatische Datenbanksicherungen
Tools zur Speicheroptimierung
Genaue Übereinstimmungssuche
Debug-Modus für Ähnlichkeitsanalyse
Überwachung der Datenbankintegrität
Duplikaterkennung und -bereinigung
Anpassbares Einbettungsmodell
Plattformübergreifende Kompatibilität (Apple Silicon, Intel, Windows, Linux)
Hardwarebewusste Optimierungen für verschiedene Umgebungen
Anmutige Fallbacks für begrenzte Hardwareressourcen
Das erweiterte Installationsskript erkennt Ihr System automatisch und installiert die entsprechenden Abhängigkeiten:
# Clone the repository
git clone https://github.com/doobidoo/mcp-memory-service.git
cd mcp-memory-service
# Create and activate a virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Run the installation script
python install.pyDas Skript install.py führt Folgendes aus:
Ermitteln Sie Ihre Systemarchitektur und verfügbare Hardwarebeschleuniger
Installieren Sie die entsprechenden Abhängigkeiten für Ihre Plattform
Konfigurieren Sie die optimalen Einstellungen für Ihre Umgebung
Überprüfen Sie die Installation und stellen Sie bei Bedarf eine Diagnose bereit
Sie können den Memory Service mit Docker ausführen:
# Using Docker Compose (recommended)
docker-compose up
# Using Docker directly
docker build -t mcp-memory-service .
docker run -p 8000:8000 -v /path/to/data:/app/chroma_db -v /path/to/backups:/app/backups mcp-memory-serviceWir bieten mehrere Docker Compose-Konfigurationen für verschiedene Szenarien:
docker-compose.yml – Standardkonfiguration mit Pip-Installation
docker-compose.uv.yml – Alternative Konfiguration mit UV-Paketmanager
docker-compose.pythonpath.yml – Konfiguration mit expliziten PYTHONPATH-Einstellungen
So verwenden Sie eine alternative Konfiguration:
docker-compose -f docker-compose.uv.yml upWindows-Benutzer können aufgrund der plattformspezifischen Verfügbarkeit von Wheels auf Probleme bei der PyTorch-Installation stoßen. Verwenden Sie unser Windows-spezifisches Installationsskript:
# After activating your virtual environment
python scripts/install_windows.pyDieses Skript behandelt:
Erkennen der CUDA-Verfügbarkeit und -Version
Installieren der entsprechenden PyTorch-Version von der richtigen Index-URL
Installieren anderer Abhängigkeiten ohne Konflikte mit PyTorch
Überprüfen der Installation
So installieren Sie Memory Service für Claude Desktop automatisch über Smithery :
npx -y @smithery/cli install @doobidoo/mcp-memory-service --client claudeAusführliche Installationsanweisungen und Hinweise zur Fehlerbehebung finden Sie im Installationshandbuch .
Fügen Sie Ihrer Datei claude_desktop_config.json Folgendes hinzu:
{
"memory": {
"command": "uv",
"args": [
"--directory",
"your_mcp_memory_service_directory", // e.g., "C:\\REPOSITORIES\\mcp-memory-service"
"run",
"memory"
],
"env": {
"MCP_MEMORY_CHROMA_PATH": "your_chroma_db_path", // e.g., "C:\\Users\\John.Doe\\AppData\\Local\\mcp-memory\\chroma_db"
"MCP_MEMORY_BACKUPS_PATH": "your_backups_path" // e.g., "C:\\Users\\John.Doe\\AppData\\Local\\mcp-memory\\backups"
}
}
}Für Windows-Benutzer empfehlen wir die Verwendung des Wrapper-Skripts, um sicherzustellen, dass PyTorch ordnungsgemäß installiert ist:
{
"memory": {
"command": "python",
"args": [
"C:\\path\\to\\mcp-memory-service\\memory_wrapper.py"
],
"env": {
"MCP_MEMORY_CHROMA_PATH": "C:\\Users\\YourUsername\\AppData\\Local\\mcp-memory\\chroma_db",
"MCP_MEMORY_BACKUPS_PATH": "C:\\Users\\YourUsername\\AppData\\Local\\mcp-memory\\backups"
}
}
}Das Wrapper-Skript wird:
Überprüfen Sie, ob PyTorch installiert und richtig konfiguriert ist
Installieren Sie PyTorch bei Bedarf mit der richtigen Index-URL
Führen Sie den Speicherserver mit der entsprechenden Konfiguration aus
Ausführliche Anweisungen zur Interaktion mit dem Speicherdienst in Claude Desktop:
Aufrufhandbuch - Lernen Sie die spezifischen Schlüsselwörter und Ausdrücke, die Speicheroperationen in Claude auslösen
Installationshandbuch - Detaillierte Einrichtungsanweisungen
Der Speicherdienst wird in Ihren Gesprächen mit Claude über natürliche Sprachbefehle aufgerufen. Beispiel:
Zum Speichern: „Bitte denken Sie daran, dass der Abgabetermin für mein Projekt der 15. Mai ist.“
Zum Abrufen: „Erinnern Sie sich, was ich Ihnen über die Deadline meines Projekts gesagt habe?“
Zum Löschen: „Bitte vergessen Sie, was ich Ihnen über meine Adresse gesagt habe.“
Eine vollständige Liste der Befehle und ausführliche Anwendungsbeispiele finden Sie im Aufrufhandbuch .
Der Speicherdienst stellt über den MCP-Server die folgenden Vorgänge bereit:
store_memory - Neue Informationen mit optionalen Tags speichern
retrieve_memory - Semantische Suche nach relevanten Erinnerungen durchführen
recall_memory - Erinnerungen mithilfe natürlicher Sprachzeitausdrücke abrufen
search_by_tag – Finden Sie Erinnerungen mithilfe bestimmter Tags
exact_match_retrieve - Finde Erinnerungen mit exakter Inhaltsübereinstimmung
debug_retrieve - Erinnerungen mit Ähnlichkeitsbewertungen abrufen
create_backup - Datenbanksicherung erstellen
get_stats - Speicherstatistiken abrufen
optimize_db - Datenbankleistung optimieren
check_database_health - Datenbank-Integritätsmetriken abrufen
check_embedding_model - Modellstatus überprüfen
delete_memory - Löscht bestimmten Speicher nach Hash
delete_by_tag - Löscht alle Erinnerungen mit einem bestimmten Tag
cleanup_duplicates - Doppelte Einträge entfernen
Konfigurieren Sie über Umgebungsvariablen:
CHROMA_DB_PATH: Path to ChromaDB storage
BACKUP_PATH: Path for backups
AUTO_BACKUP_INTERVAL: Backup interval in hours (default: 24)
MAX_MEMORIES_BEFORE_OPTIMIZE: Threshold for auto-optimization (default: 10000)
SIMILARITY_THRESHOLD: Default similarity threshold (default: 0.7)
MAX_RESULTS_PER_QUERY: Maximum results per query (default: 10)
BACKUP_RETENTION_DAYS: Number of days to keep backups (default: 7)
LOG_LEVEL: Logging level (default: INFO)
# Hardware-specific environment variables
PYTORCH_ENABLE_MPS_FALLBACK: Enable MPS fallback for Apple Silicon (default: 1)
MCP_MEMORY_USE_ONNX: Use ONNX Runtime for CPU-only deployments (default: 0)
MCP_MEMORY_USE_DIRECTML: Use DirectML for Windows acceleration (default: 0)
MCP_MEMORY_MODEL_NAME: Override the default embedding model
MCP_MEMORY_BATCH_SIZE: Override the default batch sizePlattform | Architektur | Beschleuniger | Status |
macOS | Apple Silicon (M1/M2/M3) | MPS | ✅ Vollständig unterstützt |
macOS | Apple Silicon unter Rosetta 2 | CPU | ✅ Unterstützt mit Fallbacks |
macOS | Intel | CPU | ✅ Vollständig unterstützt |
Windows | x86_64 | CUDA | ✅ Vollständig unterstützt |
Windows | x86_64 | DirectML | ✅ Unterstützt |
Windows | x86_64 | CPU | ✅ Unterstützt mit Fallbacks |
Linux | x86_64 | CUDA | ✅ Vollständig unterstützt |
Linux | x86_64 | ROCm | ✅ Unterstützt |
Linux | x86_64 | CPU | ✅ Unterstützt mit Fallbacks |
Linux | ARM64 | CPU | ✅ Unterstützt mit Fallbacks |
# Install test dependencies
pip install pytest pytest-asyncio
# Run all tests
pytest tests/
# Run specific test categories
pytest tests/test_memory_ops.py
pytest tests/test_semantic_search.py
pytest tests/test_database.py
# Verify environment compatibility
python scripts/verify_environment_enhanced.py
# Verify PyTorch installation on Windows
python scripts/verify_pytorch_windows.py
# Perform comprehensive installation verification
python scripts/test_installation.pyAusführliche Schritte zur Fehlerbehebung finden Sie in der Installationsanleitung .
Windows PyTorch-Fehler : Verwenden Sie python scripts/install_windows.py
macOS Intel-Abhängigkeitskonflikte : Verwenden Sie python install.py --force-compatible-deps
Rekursionsfehler : Führen Sie python scripts/fix_sitecustomize.py aus
Umgebungsüberprüfung : Führen Sie python scripts/verify_environment_enhanced.py aus
Speicherprobleme : Setzen Sie MCP_MEMORY_BATCH_SIZE=4 und versuchen Sie es mit einem kleineren Modell
Apple Silicon : Stellen Sie sicher, dass Python 3.10+ für ARM64 erstellt wurde, und setzen Sie PYTORCH_ENABLE_MPS_FALLBACK=1
Installationstest : Führen Sie python scripts/test_installation.py aus
mcp-memory-service/
├── src/mcp_memory_service/ # Core package code
│ ├── __init__.py
│ ├── config.py # Configuration utilities
│ ├── models/ # Data models
│ ├── storage/ # Storage implementations
│ ├── utils/ # Utility functions
│ └── server.py # Main MCP server
├── scripts/ # Helper scripts
├── memory_wrapper.py # Windows wrapper script
├── install.py # Enhanced installation script
└── tests/ # Test suitePython 3.10+ mit Typhinweisen
Verwenden Sie Datenklassen für Modelle
Dreifach zitierte Docstrings für Module und Funktionen
Async/Await-Muster für alle E/A-Vorgänge
Befolgen Sie die PEP 8-Stilrichtlinien
Schließen Sie Tests für neue Funktionen ein
MIT-Lizenz – Einzelheiten finden Sie in der Datei „LICENSE“
ChromaDB-Team für die Vektordatenbank
Sentence Transformers-Projekt zum Einbetten von Modellen
MCP-Projekt zur Protokollspezifikation
Der MCP Memory Service kann mit verschiedenen Tools und Dienstprogrammen erweitert werden. Eine Liste der verfügbaren Optionen finden Sie unter Integrationen , darunter:
MCP Memory Dashboard – Web-Benutzeroberfläche zum Durchsuchen und Verwalten von Erinnerungen
Claude-Speicherkontext – Speicherkontext in Claude-Projektanweisungen einfügen
Find relevant memories based on query
| Name | Required | Description | Default |
|---|---|---|---|
| n_results | No | ||
| query | Yes |
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 memories by tags
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes |
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 new information with optional tags
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| metadata | No |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
retrieve_memorysearch_by_tagstore_memoryThis server cannot be deployed
Scored across 3 tools
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.
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.
