mem0 Memory System
@pinkpixel/mem0-mcp MCP サーバー ✨
Mem0.aiと統合し、LLMに永続メモリ機能を提供するモデルコンテキストプロトコル(MCP)サーバー。AIエージェントがセッションをまたいで情報を保存・取得できるようにします。
このサーバーは、コア機能としてmem0ai Node.js SDK を使用します。
機能🧠
ツール
add_memory: テキスト コンテンツを特定のuserIdに関連付けられたメモリとして保存します。入力:
content(文字列、必須)、userId(文字列、必須)、sessionId(文字列、オプション)、agentId(文字列、オプション)、metadata(オブジェクト、オプション)提供されたテキストを保存し、将来のやり取りで呼び出すことができるようにします。
search_memory: 特定のuserIdに対する自然言語クエリに基づいて、保存されたメモリを検索します。入力:
query(文字列、必須)、userId(文字列、必須)、sessionId(文字列、オプション)、agentId(文字列、オプション)、filters(オブジェクト、オプション)、threshold(数値、オプション)意味的類似性に基づいて関連するメモリを検索します。
delete_memory: ID によって特定のメモリをストレージから削除します。入力:
memoryId(文字列、必須)、userId(文字列、必須)、sessionId(文字列、オプション)、agentId(文字列、オプション)指定されたメモリを完全に削除します。
意味的類似性に基づいて関連するメモリを検索します。
Related MCP server: mindcore-memory-mcp
前提条件🔑
このサーバーは、次の 2 つのストレージ モードをサポートしています。
クラウド ストレージ モード☁️ (推奨)
Mem0 APIキーが必要です(
MEM0_API_KEY環境変数として提供されます)記憶はMem0のクラウドサーバーに永続的に保存されます
ローカルデータベースは不要
ローカルストレージモード💾
OpenAI API キーが必要です (
OPENAI_API_KEY環境変数として提供されます)メモリはメモリ内のベクトルデータベースに保存されます(デフォルトでは非永続的)
永続ストレージが設定されていない限り、サーバーを再起動するとデータが失われます
インストールと設定 ⚙️
このサーバーは主に 2 つの方法で実行できます。
1. npxを使用する(手軽に使う場合におすすめ)
npm を使用してパッケージをグローバルにインストールします。
npm install -g @pinkpixel/mem0-mcpnpxを使用してサーバーを実行するように MCP クライアント (Claude Desktop、Cursor、Cline、Roo Code など) を構成します。
クラウド ストレージ構成 (推奨)
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory"
]
}
}
}注: "YOUR_MEM0_API_KEY_HERE"実際の Mem0 API キーに置き換えます。
ローカルストレージ構成(代替)
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory"
]
}
}
}注: "YOUR_OPENAI_API_KEY_HERE"実際の OpenAI API キーに置き換えます。
2. クローンリポジトリから実行
注意: この方法では、最初にリポジトリを git clone する必要があります。
リポジトリをクローンし、依存関係をインストールして、サーバーを構築します。
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build次に、 nodeを使用してビルドされたスクリプトを直接実行するように MCP クライアントを構成します。
{
"mcpServers": {
"mem0-mcp": {
"command": "node",
"args": [
"/absolute/path/to/mem0-mcp/build/index.js"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
// OR use "OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE" for local storage
},
"disabled": false,
"alwaysAllow": [
"add_memory",
"search_memory"
]
}
}
}重要な注意事項:
/absolute/path/to/mem0-mcp/をクローンしたリポジトリへの実際の絶対パスに置き換えます。src/index.tsファイルではなく、build/index.jsファイルを使用してください。MCP サーバーはプロトコル通信のためにクリーンな stdout を必要とします。stdout に書き込むライブラリやコードはプロトコルに干渉する可能性があります。
デフォルトのユーザー ID (オプションのフォールバック)
add_memoryとsearch_memoryツールの両方で、メモリを特定のユーザーに関連付けるにはuserId引数が必要です。
テスト中やシングルユーザーシナリオでの利便性のため、サーバー起動時にDEFAULT_USER_ID環境変数を設定することができます。この変数が設定されており、 search_memoryツールの呼び出し時にuserId引数が省略されている場合、サーバーは検索にDEFAULT_USER_IDの値を使用します。
**注:**このフォールバックが存在する場合、あいまいさを避けるために、呼び出しエージェント (LLM) がメモリの追加と検索の両方に対して正しいuserId明示的に提供することが一般的に推奨されます。
DEFAULT_USER_IDを使用した構成例:
{
"mcpServers": {
"mem0-mcp": {
"command": "npx",
"args": [
"-y",
"@pinkpixel/mem0-mcp"
],
"env": {
"MEM0_API_KEY": "YOUR_MEM0_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
}
}
}または、 nodeで直接実行する場合:
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build{
"mcpServers": {
"mem0-mcp": {
"command": "node",
"args": [
"path/to/mem0-mcp/build/index.js"
],
"env": {
"OPENAI_API_KEY": "YOUR_OPENAI_API_KEY_HERE",
"DEFAULT_USER_ID": "user123"
},
}
}
}クラウド vs. ローカルストレージ 🔄
クラウドストレージ(Mem0 API)
デフォルトで永続的- セッションやサーバーの再起動後も記憶は利用可能
ローカルデータベースは不要- すべてのデータはMem0のサーバーに保存されます
より高い検索品質- Mem0の最適化された検索アルゴリズムを使用
追加フィールド-
agent_idとthresholdパラメータをサポート必要なもの- Mem0 APIキー
ローカルストレージ(OpenAI API)
デフォルトでメモリ内- データはRAMにのみ保存され、長期保存されません。キャッシュが行われる場合もありますが、永続的な保存には利用しないでください。
データ損失のリスク- サーバーの再起動、システムの再起動、またはプロセスが終了した場合、メモリデータが失われます。
推奨用途- 開発、テスト、または一時的な使用のみ
永続的なストレージの場合- 信頼性の高い長期メモリが必要な場合は、Mem0 API でクラウド ストレージ オプションを使用します。
OpenAI埋め込みを使用- ベクトル検索機能用
自己完結型- すべてのデータはマシン上に残ります
必要なもの- OpenAI APIキー
開発💻
リポジトリをクローンし、依存関係をインストールします。
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm installサーバーを構築します。
npm run buildファイルの変更時に自動再構築する開発の場合:
npm run watchデバッグ🐞
MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。以下にいくつかのアプローチを示します。
MCP インスペクターを使用する: このツールは、MCP プロトコル通信を監視できます。
npm run inspectorコンソールログ: コンソールログを追加するときは、MCPプロトコルに干渉しないように、常に
console.error()``console.log()を使用してください。環境ファイル: ローカル開発では
.envファイルを使用して、API キーやその他の構成オプションの設定を簡素化します。
技術実装ノート 🔧
高度なMem0 APIパラメータ
Mem0 APIでCloud Storageモードを使用する場合、追加のパラメータを利用してより高度なメモリ管理を行うことができます。ツールスキーマでは明示的に公開されていませんが、メモリを追加する際にはmetadataオブジェクトに含めることができます。
add_memoryの高度なパラメータ:
パラメータ | タイプ | 説明 |
| 物体 | メモリに関する追加のコンテキスト(例:場所、時間、識別子)を保存します。これは、検索時のフィルタリングに使用できます。 |
| 弦 | メモリに含める特定の設定。 |
| 弦 | メモリから除外する特定の設定。 |
| ブール値 | メモリを推測するか、メッセージを直接保存するか (デフォルト: true)。 |
| 弦 | フォーマットのバージョン。v1.0 (デフォルト、非推奨) または v1.1 (推奨) のいずれか。 |
| 物体 | 名前と説明が付いたカテゴリのリスト。 |
| 弦 | メモリの処理と整理に関するプロジェクト固有のガイドライン。 |
| ブール値 | メモリが不変かどうか (デフォルト: false)。 |
| 弦 | メモリの有効期限 (形式: YYYY-MM-DD)。 |
| 弦 | このメモリに関連付けられた組織 ID。 |
| 弦 | このメモリに関連付けられたプロジェクト ID。 |
| 弦 | メモリ バージョン (v1 は非推奨、新しいアプリケーションには v2 が推奨されます)。 |
MCPサーバーでこれらのパラメータを使用するには、 add_memoryツールを呼び出す際にメタデータオブジェクトにパラメータを含めます。例:
{
"content": "Important information to remember",
"userId": "user123",
"sessionId": "project-abc",
"metadata": {
"includes": "important context",
"excludes": "sensitive data",
"immutable": true,
"expiration_date": "2025-12-31",
"custom_instructions": "Prioritize this memory for financial questions",
"version": "v2"
}
}search_memoryの高度なパラメータ:
Mem0 v2 検索 API は、 filtersパラメータを通じて利用できる強力なフィルタリング機能を提供します。
パラメータ | タイプ | 説明 |
| 物体 | 論理演算子と比較条件を使用した複雑なフィルター |
| 整数 | 返される上位結果の数(デフォルト: 10) |
| 弦[] | 応答に含める特定のフィールド |
| ブール値 | メモリを再ランク付けするかどうか(デフォルト:false) |
| ブール値 | キーワードに基づいて検索するかどうか(デフォルト:false) |
| ブール値 | 思い出をフィルタリングするかどうか(デフォルト:false) |
| 番号 | 結果の最小類似度しきい値(デフォルト: 0.3) |
| 弦 | 記憶をフィルタリングするための組織ID |
| 弦 | 記憶をフィルタリングするためのプロジェクトID |
filtersパラメータは、複雑な論理演算 (AND、OR) とさまざまな比較演算子をサポートします。
オペレーター | 説明 |
| 指定された値のいずれかに一致する |
| より大きいか等しい |
| 以下 |
| より大きい |
| 未満 |
| 等しくない |
| 大文字と小文字を区別しない包含チェック |
search_memoryツールで複雑なフィルターを使用する例:
{
"query": "What are Alice's hobbies?",
"userId": "user123",
"filters": {
"AND": [
{
"user_id": "alice"
},
{
"agent_id": {"in": ["travel-agent", "sports-agent"]}
}
]
},
"threshold": 0.5,
"top_k": 5
}これは、user_id が「alice」であり、agent_id が「travel-agent」または「sports-agent」のいずれかである Alice の趣味に関連する思い出を検索し、類似度スコアが少なくとも 0.5 である結果が最大 5 件返されます。
これらのパラメータの詳細については、 Mem0 API ドキュメントを参照してください。
セーフロガー
MCP サーバーは、MCP プロトコルを中断することなく、mem0ai ライブラリからの console.log 呼び出しを stderr に選択的にリダイレクトするSafeLoggerクラスを実装します。
console.log の呼び出しを傍受し、スタックトレースを調べてソースを特定します。
mem0ai ライブラリまたは独自のコードからのログ呼び出しのみをリダイレクトします
MCPプロトコル通信用のクリーンな標準出力を保持します
プロセス終了時にリソースを自動的にクリーンアップします
これにより、有用なデバッグ情報を維持しながら、MCP クライアント内で適切に機能できるようになります。
環境変数
サーバーは、その動作を制御するいくつかの環境変数を認識します。
MEM0_API_KEY: クラウドストレージモードのAPIキーOPENAI_API_KEY: ローカルストレージモード(埋め込み)のAPIキーDEFAULT_USER_ID: メモリ操作のデフォルトのユーザーID
Pink Pixel が ❤️ を込めて作りました
Available Tools
3 toolsadd_memoryC
Stores a piece of text as a memory in Mem0.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID to associate with the memory (for cloud API). | |
| content | Yes | The text content to store as memory. | |
| metadata | No | Optional key-value metadata. | |
| sessionId | No | Optional session ID to associate with the memory. | |
| userId | Yes | User ID to associate with the memory. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool stores text as memory but doesn't mention whether this is a write operation (implied), what permissions are needed, how the memory is persisted, rate limits, or what happens on success/failure. This is inadequate for a mutation 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 that gets straight to the point with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances like idempotency. Given the complexity (5 parameters including nested objects) and lack of structured coverage, more context is needed.
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 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain format constraints or usage examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Stores') and resource ('a piece of text as a memory in Mem0'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_memory' or 'search_memory' beyond the obvious verb difference, which prevents a perfect score.
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 'search_memory' or 'delete_memory'. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_memoryC
Deletes a specific memory from Mem0 by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID associated with the memory (for cloud API). | |
| memoryId | Yes | The unique ID of the memory to delete. | |
| sessionId | No | Optional session ID associated with the memory. | |
| userId | Yes | User ID associated with the memory. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive operation, but doesn't cover critical aspects like permissions needed, whether deletion is permanent or reversible, rate limits, or error handling. This leaves significant gaps for a mutation tool.
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, clear sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it highly efficient.
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 tool's complexity (a destructive operation with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain behavioral traits, return values, or usage context, leaving the agent with incomplete information for safe and effective 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?
The schema description coverage is 100%, so all parameters are documented in the input schema. The description mentions 'by ID', which aligns with the 'memoryId' parameter but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Deletes') and resource ('a specific memory from Mem0 by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_memory' or 'search_memory' beyond the obvious verb difference, which is why it doesn't reach a 5.
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 'search_memory' or 'add_memory', nor does it mention prerequisites or exclusions. It's a straightforward statement of function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_memoryC
Searches stored memories in Mem0 based on a query.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | No | Optional agent ID to filter search (for cloud API). | |
| filters | No | Optional key-value filters for metadata. | |
| query | Yes | The search query. | |
| sessionId | No | Optional session ID to filter search. | |
| threshold | No | Optional similarity threshold for results (for cloud API). | |
| userId | Yes | User ID to filter search. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action of searching without detailing aspects like whether it's read-only (implied but not explicit), potential side effects, rate limits, authentication needs, or what the search returns. This leaves significant gaps for a tool with multiple parameters and no output schema.
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 that directly states the tool's purpose without any fluff or redundancy. 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 (6 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits, return values, or how to interpret results, leaving the agent with incomplete information to use the tool effectively in context with its siblings.
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?
The description mentions 'based on a query,' which aligns with the 'query' parameter, but adds no additional meaning beyond what the schema provides. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters well, and the description doesn't compensate with extra context or examples.
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 ('searches') and resource ('stored memories in Mem0'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add_memory' or 'delete_memory' beyond the basic verb difference, missing specific scope or functional distinctions that would warrant a 5.
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, such as how it differs from 'add_memory' or 'delete_memory' in practice, nor does it mention any prerequisites or exclusions. It's a generic statement that offers no contextual usage advice.
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
v1.0.0- First observed
add_memory - First observed
delete_memory - First observed
search_memory
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: add_memory stores new data, delete_memory removes by ID, and search_memory retrieves based on queries. There is no overlap or ambiguity between these three core operations.
All tools follow a consistent verb_noun pattern (add_memory, delete_memory, search_memory) with snake_case throughout. The naming is predictable and uniform across the set.
With only 3 tools, the set feels minimal for a memory system. While it covers basic CRUD operations (create, delete, read), it lacks update functionality and other potential features like listing or managing memory collections, making it borderline thin for the domain.
The tools provide essential CRUD coverage (add, delete, search) for a memory system, but there are minor gaps such as no update_memory tool to modify existing memories and no way to list all memories without a query. Agents can work around this by deleting and re-adding, but it's not ideal.
Maintenance
Related MCP Connectors
An MCP memory server. One memory your agents share — across models, devices and apps.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceAn MCP-native, local-first memory server that gives AI agents persistent, structured memory across sessions and tools, enabling them to maintain identity and context without reconfiguration.3MIT
- AlicenseAqualityCmaintenanceA production-grade long-term memory MCP server that enables AI agents to persist and recall memories across sessions with importance weighting, confidence calibration, and efficient context window management.973 PyPI1MIT
- AlicenseAqualityDmaintenanceAn MCP server that provides persistent memory capabilities for AI agents using Mem0, enabling storage, search, and management of contextual information across conversations with support for multiple backends and LLM providers.1824 PyPIMIT
- AlicenseNot gradedqualityDmaintenanceA portable MCP server providing a shared intelligent memory system for any MCP-compatible AI tool, enabling storage, retrieval, extraction, and governance of memories across sessions.10 npmMIT