一个 MCP 服务器，使用 ChromaDB 和句子转换器为 Claude Desktop 提供语义记忆和持久存储功能。该服务支持长期记忆存储和语义搜索功能，非常适合跨对话和实例维护上下文。
使用TalkToGitHub与 Repo 对话！
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.pyinstall.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由于特定平台的 Wheel 可用性，Windows 用户可能会遇到 PyTorch 安装问题。请使用我们 Windows 专用的安装脚本：
# After activating your virtual environment
python scripts/install_windows.py该脚本处理：
检测 CUDA 可用性和版本
从正确的索引 URL 安装适当的 PyTorch 版本
安装其他依赖项而不与 PyTorch 冲突
验证安装
要通过Smithery自动为 Claude Desktop 安装内存服务：
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 是否已安装并正确配置
如果需要，使用正确的索引 URL 安装 PyTorch
使用适当的配置运行内存服务器
有关如何与 Claude Desktop 中的内存服务交互的详细说明：
在您与 Claude 的对话中，记忆服务会通过自然语言命令调用。例如：
对商店说：“请记住，我的项目截止日期是 5 月 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 | 苹果硅片 (M1/M2/M3) | 国会议员 | ✅ 完全支持 |
macOS | Rosetta 2 下的 Apple Silicon | 中央处理器 | ✅ 支持后备 |
macOS | 英特尔 | 中央处理器 | ✅ 完全支持 |
视窗 | x86_64 | CUDA | ✅ 完全支持 |
视窗 | x86_64 | DirectML | ✅ 支持 |
视窗 | x86_64 | 中央处理器 | ✅ 支持后备 |
Linux | x86_64 | CUDA | ✅ 完全支持 |
Linux | x86_64 | ROC | ✅ 支持 |
Linux | x86_64 | 中央处理器 | ✅ 支持后备 |
Linux | 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
macOS Intel 依赖冲突：使用python install.py --force-compatible-deps
递归错误：运行python scripts/fix_sitecustomize.py
环境验证：运行python scripts/verify_environment_enhanced.py
内存问题：设置MCP_MEMORY_BATCH_SIZE=4并尝试较小的模型
Apple Silicon ：确保为 ARM64 构建 Python 3.10+，设置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 suite带有类型提示的 Python 3.10+
使用数据类作为模型
模块和函数的三重引号文档字符串
所有 I/O 操作的异步/等待模式
遵循 PEP 8 样式指南
包括新功能的测试
MIT 许可证 - 详情请参阅许可证文件
ChromaDB矢量数据库团队
用于嵌入模型的句子转换器项目
协议规范的 MCP 项目
MCP 内存服务可以通过各种工具和实用程序进行扩展。请参阅集成以获取可用选项列表，包括：
MCP 内存仪表板- 用于浏览和管理内存的 Web UI
Claude Memory Context - 将内存上下文注入 Claude 项目说明
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.
