MCP-сервер, предоставляющий возможности семантической памяти и постоянного хранения для Claude Desktop с использованием ChromaDB и преобразователей предложений. Этот сервис обеспечивает долгосрочное хранение памяти с возможностями семантического поиска, что делает его идеальным для поддержания контекста в разговорах и случаях.
Пообщайтесь с репозиторием с помощью TalkToGitHub !
Related MCP server: memcp
Семантический поиск с использованием преобразователей предложений
Припоминание естественного языка с учетом времени (например, «на прошлой неделе», «вчера утром»)
Система извлечения памяти на основе тегов
Постоянное хранилище с использованием ChromaDB
Автоматическое резервное копирование баз данных
Инструменты оптимизации памяти
Поиск точного соответствия
Режим отладки для анализа сходства
Мониторинг работоспособности базы данных
Обнаружение и очистка дубликатов
Настраиваемая модель встраивания
Кроссплатформенная совместимость (Apple Silicon, Intel, Windows, Linux)
Аппаратно-ориентированная оптимизация для различных сред
Изящные откаты при ограниченных аппаратных ресурсах
Расширенный скрипт установки автоматически обнаруживает вашу систему и устанавливает соответствующие зависимости:
# 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.pyСкрипт install.py выполнит следующие действия:
Определите архитектуру вашей системы и доступные аппаратные ускорители
Установите соответствующие зависимости для вашей платформы.
Настройте оптимальные параметры для вашей среды
Проверьте установку и при необходимости проведите диагностику.
Вы можете запустить службу памяти с помощью 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-serviceМы предоставляем несколько конфигураций Docker Compose для различных сценариев:
docker-compose.yml — стандартная конфигурация с использованием pip install
docker-compose.uv.yml — Альтернативная конфигурация с использованием менеджера пакетов UV
docker-compose.pythonpath.yml — Конфигурация с явными настройками PYTHONPATH
Чтобы использовать альтернативную конфигурацию:
docker-compose -f docker-compose.uv.yml upПользователи Windows могут столкнуться с проблемами установки PyTorch из-за доступности колеса для определенной платформы. Используйте наш скрипт установки для Windows:
# After activating your virtual environment
python scripts/install_windows.pyЭтот скрипт обрабатывает:
Определение доступности и версии CUDA
Установка соответствующей версии PyTorch с правильного индексного URL-адреса
Установка других зависимостей без конфликта с PyTorch
Проверка установки
Чтобы автоматически установить Memory Service для Claude Desktop через Smithery :
npx -y @smithery/cli install @doobidoo/mcp-memory-service --client claudeПодробные инструкции по установке и устранению неполадок см. в Руководстве по установке .
Добавьте следующее в файл 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"
}
}
}Пользователям Windows мы рекомендуем использовать скрипт-оболочку, чтобы убедиться, что PyTorch установлен правильно:
{
"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"
}
}
}Скрипт-обертка будет:
Проверьте, установлен ли PyTorch и правильно ли он настроен.
При необходимости установите PyTorch с правильным индексным URL-адресом.
Запустите сервер памяти с соответствующей конфигурацией.
Подробные инструкции по взаимодействию со службой памяти в Claude Desktop:
Руководство по вызову — изучите конкретные ключевые слова и фразы, которые запускают операции с памятью в Claude
Руководство по установке - Подробные инструкции по настройке
Служба памяти вызывается посредством команд естественного языка в ваших разговорах с Клодом. Например:
Сохранить: «Пожалуйста, помните, что крайний срок сдачи моего проекта — 15 мая».
Извлечь: «Помнишь, что я говорил тебе о сроках сдачи моего проекта?»
Удалить: «Пожалуйста, забудьте то, что я вам говорил о моем адресе».
Полный список команд и подробные примеры использования см. в Руководстве по вызову.
Служба памяти обеспечивает выполнение следующих операций через сервер MCP:
store_memory — сохранение новой информации с дополнительными тегами
retrieve_memory — выполнить семантический поиск соответствующих воспоминаний
recall_memory - Извлечение воспоминаний с использованием выражений времени на естественном языке
search_by_tag — поиск воспоминаний с использованием определенных тегов
exact_match_retrieve — поиск воспоминаний с точным совпадением содержания
debug_retrieve — извлечение воспоминаний с оценками сходства
create_backup — Создать резервную копию базы данных
get_stats - Получить статистику памяти
optimize_db — Оптимизация производительности базы данных
check_database_health — получение показателей работоспособности базы данных
check_embedding_model — проверка статуса модели
delete_memory - Удалить определенную память по хешу
delete_by_tag — Удалить все воспоминания с определенным тегом
cleanup_duplicates - Удалить дубликаты записей
Настройте через переменные среды:
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 sizeПлатформа | Архитектура | Ускоритель | Статус |
macOS | Apple Silicon (M1/M2/M3) | МПС | ✅ Полностью поддерживается |
macOS | Apple Silicon под Rosetta 2 | Процессор | ✅ Поддерживается с резервными вариантами |
macOS | Интел | Процессор | ✅ Полностью поддерживается |
Окна | x86_64 | CUDA | ✅ Полностью поддерживается |
Окна | x86_64 | DirectML | ✅ Поддерживается |
Окна | x86_64 | Процессор | ✅ Поддерживается с резервными вариантами |
Линукс | x86_64 | CUDA | ✅ Полностью поддерживается |
Линукс | x86_64 | ROCм | ✅ Поддерживается |
Линукс | x86_64 | Процессор | ✅ Поддерживается с резервными вариантами |
Линукс | ARM64 | Процессор | ✅ Поддерживается с резервными вариантами |
# 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.pyПодробные инструкции по устранению неполадок см. в руководстве по установке .
Ошибки Windows PyTorch : используйте python scripts/install_windows.py
Конфликты зависимостей Intel в macOS : используйте python install.py --force-compatible-deps
Ошибки рекурсии : Запустите python scripts/fix_sitecustomize.py
Проверка среды : Запустите python scripts/verify_environment_enhanced.py
Проблемы с памятью : установите MCP_MEMORY_BATCH_SIZE=4 и попробуйте меньшую модель.
Apple Silicon : убедитесь, что Python 3.10+ собран для ARM64, установите PYTORCH_ENABLE_MPS_FALLBACK=1
Тестирование установки : Запустите python scripts/test_installation.py
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+ с подсказками типов
Используйте классы данных для моделей
Строки документации в тройных кавычках для модулей и функций
Шаблон async/await для всех операций ввода-вывода
Следуйте рекомендациям по стилю PEP 8
Включить тесты для новых функций
Лицензия MIT — подробности см. в файле LICENSE
Команда ChromaDB для векторной базы данных
Проект Sentence Transformers для внедрения моделей
Проект MCP для спецификации протокола
Служба памяти MCP может быть расширена различными инструментами и утилитами. См. раздел Интеграции для списка доступных опций, включая:
MCP Memory Dashboard — веб-интерфейс для просмотра и управления памятью
Контекст памяти Клода — внедрение контекста памяти в инструкции проекта Клода
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.
