MCP Memory Service
Servicio de memoria MCP
Un servidor MCP que proporciona memoria semántica y capacidades de almacenamiento persistente para Claude Desktop mediante ChromaDB y transformadores de oraciones. Este servicio permite el almacenamiento en memoria a largo plazo con funciones de búsqueda semántica, lo que lo hace ideal para mantener el contexto entre conversaciones e instancias.
Ayuda
¡Hable con el repositorio con TalkToGitHub !
Related MCP server: Neuro MCP V2
Características
Búsqueda semántica mediante transformadores de oraciones
Recuerdo basado en el tiempo del lenguaje natural (por ejemplo, "la semana pasada", "ayer por la mañana")
Sistema de recuperación de memoria basado en etiquetas
Almacenamiento persistente mediante ChromaDB
Copias de seguridad automáticas de bases de datos
Herramientas de optimización de memoria
Recuperación de coincidencias exactas
Modo de depuración para análisis de similitud
Monitoreo del estado de la base de datos
Detección y limpieza de duplicados
Modelo de incrustación personalizable
Compatibilidad entre plataformas (Apple Silicon, Intel, Windows, Linux)
Optimizaciones basadas en hardware para diferentes entornos
Respaldos elegantes para recursos de hardware limitados
Instalación
Inicio rápido (recomendado)
El script de instalación mejorado detecta automáticamente su sistema e instala las dependencias adecuadas:
# 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.pyEl script install.py hará lo siguiente:
Detecte la arquitectura de su sistema y los aceleradores de hardware disponibles
Instale las dependencias adecuadas para su plataforma
Configure los ajustes óptimos para su entorno
Verificar la instalación y proporcionar diagnósticos si es necesario
Instalación de Docker
Puede ejecutar el servicio de memoria usando Docker:
# 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-serviceProporcionamos múltiples configuraciones de Docker Compose para diferentes escenarios:
docker-compose.yml- Configuración estándar mediante pip installdocker-compose.uv.yml: configuración alternativa mediante el administrador de paquetes UVdocker-compose.pythonpath.yml: configuración con ajustes PYTHONPATH explícitos
Para utilizar una configuración alternativa:
docker-compose -f docker-compose.uv.yml upInstalación de Windows (caso especial)
Los usuarios de Windows podrían experimentar problemas de instalación de PyTorch debido a la disponibilidad de ruedas específicas de cada plataforma. Utilice nuestro script de instalación específico para Windows:
# After activating your virtual environment
python scripts/install_windows.pyEste script maneja:
Detección de la disponibilidad y versión de CUDA
Instalar la versión adecuada de PyTorch desde la URL de índice correcta
Instalar otras dependencias sin entrar en conflicto con PyTorch
Verificando la instalación
Instalación mediante herrería
Para instalar el Servicio de memoria para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @doobidoo/mcp-memory-service --client claudeGuía de instalación detallada
Para obtener instrucciones completas de instalación y solución de problemas, consulte la Guía de instalación .
Configuración de Claude MCP
Configuración estándar
Agregue lo siguiente a su archivo claude_desktop_config.json :
{
"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"
}
}
}Configuración específica de Windows (recomendada)
Para los usuarios de Windows, recomendamos utilizar el script contenedor para garantizar que PyTorch esté instalado correctamente:
{
"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"
}
}
}El script contenedor hará lo siguiente:
Compruebe si PyTorch está instalado y configurado correctamente
Instale PyTorch con la URL de índice correcta si es necesario
Ejecute el servidor de memoria con la configuración adecuada
Guía de uso
Para obtener instrucciones detalladas sobre cómo interactuar con el servicio de memoria en Claude Desktop:
Guía de invocación : aprenda las palabras clave y frases específicas que activan las operaciones de memoria en Claude
Guía de instalación : instrucciones de configuración detalladas
El servicio de memoria se invoca mediante comandos de lenguaje natural en tus conversaciones con Claude. Por ejemplo:
Para guardar: "Por favor, recuerde que la fecha límite de mi proyecto es el 15 de mayo".
Para recuperar: "¿Recuerdas lo que te dije sobre la fecha límite de mi proyecto?"
Para borrar: "Por favor olvida lo que te dije sobre mi dirección".
Consulte la Guía de invocación para obtener una lista completa de comandos y ejemplos de uso detallados.
Operaciones de memoria
El servicio de memoria proporciona las siguientes operaciones a través del servidor MCP:
Operaciones de memoria central
store_memory- Almacena nueva información con etiquetas opcionalesretrieve_memory- Realizar una búsqueda semántica de recuerdos relevantesrecall_memory- Recupera recuerdos usando expresiones de tiempo en lenguaje naturalsearch_by_tag- Encuentra recuerdos usando etiquetas específicasexact_match_retrieve- Encuentra recuerdos con coincidencia exacta de contenidodebug_retrieve- Recupera memorias con puntuaciones de similitud
Gestión de bases de datos
create_backup- Crear copia de seguridad de la base de datosget_stats- Obtener estadísticas de memoriaoptimize_db- Optimizar el rendimiento de la base de datoscheck_database_health- Obtener métricas de salud de la base de datoscheck_embedding_model- Verificar el estado del modelo
Gestión de la memoria
delete_memory- Eliminar memoria específica por hashdelete_by_tag- Elimina todos los recuerdos con una etiqueta específicacleanup_duplicates- Eliminar entradas duplicadas
Opciones de configuración
Configurar a través de variables de entorno:
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 sizeCompatibilidad de hardware
Plataforma | Arquitectura | Acelerador | Estado |
macOS | Silicona de Apple (M1/M2/M3) | MPS | ✅ Totalmente compatible |
macOS | Apple Silicon bajo Rosetta 2 | UPC | ✅ Compatible con alternativas |
macOS | Intel | UPC | ✅ Totalmente compatible |
Ventanas | x86_64 | CUDA | ✅ Totalmente compatible |
Ventanas | x86_64 | DirectML | ✅ Compatible |
Ventanas | x86_64 | UPC | ✅ Compatible con alternativas |
Linux | x86_64 | CUDA | ✅ Totalmente compatible |
Linux | x86_64 | ROCm | ✅ Compatible |
Linux | x86_64 | UPC | ✅ Compatible con alternativas |
Linux | ARM64 | UPC | ✅ Compatible con alternativas |
Pruebas
# 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.pySolución de problemas
Consulte la Guía de instalación para obtener pasos detallados para la solución de problemas.
Consejos rápidos para la solución de problemas
Errores de PyTorch de Windows : utilice
python scripts/install_windows.pyConflictos de dependencia de Intel en macOS : use
python install.py --force-compatible-depsErrores de recursión : Ejecute
python scripts/fix_sitecustomize.pyVerificación del entorno : ejecutar
python scripts/verify_environment_enhanced.pyProblemas de memoria : establezca
MCP_MEMORY_BATCH_SIZE=4y pruebe un modelo más pequeñoApple Silicon : asegúrese de que Python 3.10+ esté creado para ARM64, configure
PYTORCH_ENABLE_MPS_FALLBACK=1Prueba de instalación : ejecute
python scripts/test_installation.py
Estructura del proyecto
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 suiteDirectrices de desarrollo
Python 3.10+ con sugerencias de tipos
Utilice clases de datos para modelos
Documentstrings entre comillas triples para módulos y funciones
Patrón asíncrono/en espera para todas las operaciones de E/S
Siga las pautas de estilo de PEP 8
Incluir pruebas para nuevas funciones
Licencia
Licencia MIT: consulte el archivo de LICENCIA para obtener más detalles
Expresiones de gratitud
Equipo de ChromaDB para la base de datos vectorial
Proyecto Transformadores de Sentencias para incrustar modelos
Proyecto MCP para la especificación del protocolo
Contacto
Integraciones
El servicio de memoria MCP se puede ampliar con diversas herramientas y utilidades. Consulte Integraciones para ver una lista de las opciones disponibles, entre ellas:
Panel de memoria MCP : interfaz web para explorar y administrar memorias
Contexto de memoria de Claude : Inyectar contexto de memoria en las instrucciones del proyecto Claude
Available 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.
3 tool updates
- First observed
retrieve_memory - First observed
search_by_tag - First observed
store_memory
This server cannot be deployed
TDQS
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.
Maintenance
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-
- FlicenseAqualityDmaintenanceSupercharges 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.15 npm4MIT
- AlicenseNot gradedqualityFmaintenanceProvides Claude with long-term memory by indexing conversation history, enabling semantic search, decision tracking, and cross-project search.18 npm29MIT