mem0 Memory System
@pinkpixel/mem0-mcp MCP 服务器 ✨
模型上下文协议 (MCP) 服务器与Mem0.ai集成,为 LLM 提供持久内存功能。它允许 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
先决条件🔑
该服务器支持两种存储模式:
云存储模式☁️(推荐)
需要Mem0 API 密钥(作为
MEM0_API_KEY环境变量提供)记忆永久存储在 Mem0 的云服务器上
无需本地数据库
本地存储模式💾
需要OpenAI API 密钥(作为
OPENAI_API_KEY环境变量提供)记忆存储在内存向量数据库中(默认情况下是非持久性的)
除非配置为持久存储,否则服务器重启时数据会丢失
安装和配置⚙️
您可以通过两种主要方式运行此服务器:
1. 使用npx (推荐快速使用)
使用 npm 全局安装包:
npm install -g @pinkpixel/mem0-mcp配置您的 MCP 客户端(例如,Claude Desktop、Cursor、Cline、Roo Code 等)以使用npx运行服务器:
云存储配置(推荐)
{
"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"
]
}
}
}**注意:**用您的实际 OpenAI API 密钥替换"YOUR_OPENAI_API_KEY_HERE" 。
2. 从克隆的存储库运行
注意:此方法要求您先 git clone 存储库。
克隆存储库、安装依赖项并构建服务器:
git clone https://github.com/pinkpixel-dev/mem0-mcp
cd mem0-mcp
npm install
npm run build然后,配置您的 MCP 客户端以使用node直接运行构建的脚本:
{
"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/替换为克隆存储库的实际绝对路径使用
build/index.js文件,而不是src/index.ts文件MCP 服务器需要干净的标准输出来进行协议通信 - 任何写入标准输出的库或代码都可能干扰协议
默认用户 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 Inspector :此工具可以监控 MCP 协议通信:
npm run inspector控制台日志:添加控制台日志时,请始终使用
console.error()而不是console.log()以避免干扰 MCP 协议环境文件:使用
.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
}这将搜索与 Alice 的爱好相关的记忆,其中 user_id 为“alice”并且 agent_id 为“travel-agent”或“sports-agent”,返回最多 5 个结果,相似度得分至少为 0.5。
有关这些参数的更多详细信息,请参阅Mem0 API 文档。
安全记录器
MCP 服务器实现了一个SafeLogger类,该类可以选择性地将 console.log 调用从 mem0ai 库重定向到 stderr,而不会中断 MCP 协议:
拦截 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