ChromaDBとセンテンストランスフォーマーを活用し、Claude Desktopにセマンティックメモリと永続ストレージ機能を提供するMCPサーバー。このサービスは、セマンティック検索機能を備えた長期メモリストレージを可能にし、会話やインスタンス間でのコンテキスト維持に最適です。
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.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 upWindows ユーザーは、プラットフォーム固有のホイールの可用性により、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 のメモリ サービスと対話する方法の詳細な手順については、以下を参照してください。
メモリサービスは、クロードとの会話の中で自然言語コマンドを通じて呼び出されます。例えば：
店舗へ: 「私のプロジェクトの締め切りは 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 | Appleシリコン（M1/M2/M3） | MPS | ✅ 完全にサポートされています |
macOS | Rosetta 2 搭載の Apple Silicon | CPU | ✅ フォールバックでサポートされています |
macOS | インテル | CPU | ✅ 完全にサポートされています |
ウィンドウズ | x86_64 | CUDA | ✅ 完全にサポートされています |
ウィンドウズ | x86_64 | ダイレクトML | ✅ サポートされています |
ウィンドウズ | x86_64 | CPU | ✅ フォールバックでサポートされています |
リナックス | x86_64 | CUDA | ✅ 完全にサポートされています |
リナックス | x86_64 | ROCm | ✅ サポートされています |
リナックス | x86_64 | CPU | ✅ フォールバックでサポートされています |
リナックス | ARM64 | CPU | ✅ フォールバックでサポートされています |
# 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 : 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 suite型ヒント付きのPython 3.10+
モデルにデータクラスを使用する
モジュールと関数の三重引用符で囲まれたドキュメント文字列
すべてのI/O操作の非同期/待機パターン
PEP 8スタイルガイドラインに従う
新機能のテストを含める
MITライセンス - 詳細はLICENSEファイルを参照
ベクターデータベースのChromaDBチーム
埋め込みモデルのためのSentence Transformersプロジェクト
プロトコル仕様のMCPプロジェクト
MCPメモリサービスは、様々なツールやユーティリティで拡張できます。利用可能なオプションの一覧については、 「統合」をご覧ください。
MCP メモリダッシュボード- メモリの閲覧と管理のための Web UI
Claude メモリ コンテキスト- 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.
