通过 MCP 为编码代理提供自托管的记忆功能。无需 Docker。无需 Mem0 平台。无需 REST 守护进程。
该 MCP 封装了 mem0ai 的 Memory()，向量数据存储在磁盘上的 ~/.mem0/qdrant 目录下。工具调用在进程内完成。侧车保持 Qdrant 打开状态；第二个 MCP 在同一目录下通过 lite.lock / lite.want 进行协调——无需额外的守护进程。
官方 Mem0 提供了三个组件，但它们并不适合本地 MCP 环境的组合使用：
官方路径 | 此处的问题 |
平台 MCP ( | 记忆数据离开你的机器，需要付费。 |
开源 REST 服务器 | 需要 Docker + Postgres；重量级，难以维护，在非 Linux 机器上消耗电池。 |
| 仅客户端，不包含服务器 |
mem0-lite 是一个轻量级的本地 Python 应用，将开源 mem0 库作为 MCP 服务暴露出来。
Related MCP server: Cortex
MCP 工具 — add_memory、search_memories、get_memory_by_id、list_memories、update_memory、delete_memory、delete_all_memories（调用方式见工具文档）
本地存储 — 磁盘上的 Qdrant（on_disk=True），非 /tmp，具有并发协调机制
使用时机 — 精简的 AGENTS.md 指引
MCP 注册 — uv 启动片段
向量数据库、历史记录、配置、访问日志、lite.lock 和 lite.want 均存储在 ~/.mem0 目录下
需要 uv、Python 3.11+ 和 OPENAI_API_KEY（或 Ollama——参见 架构）。
克隆此仓库。
向你的主机注册 MCP 服务器（见下方片段）。在主机配置或系统环境中设置 OPENAI_API_KEY；不要提交到版本控制。
粘贴 AGENTS.md 指引。
MCP 从进程环境中读取以下变量。如果某个变量已在系统环境中设置，并且 MCP 未在沙箱中运行，主机将直接传递该变量——你无需在主机 env 块中重复设置。该 env 块中的值会覆盖系统环境中的值。
OPENAI_API_KEY — 必需，除非使用 Ollama（见下文）
MEM0_DIR — 数据目录（默认 ~/.mem0）
MEM0_LITE_USER_ID — 默认用户作用域（默认 $USER）
MEM0_LITE_AGENT_ID — 可选的代理作用域
MEM0_LITE_LOCK_TIMEOUT — 存储锁等待时间（秒，默认 30）
MEM0_LITE_LLM_PROVIDER — 例如 ollama（默认：通过 mem0ai 使用 OpenAI）
MEM0_LITE_LLM_MODEL — 大模型名称（使用 Ollama 时默认 llama3.2）
MEM0_LITE_EMBEDDER_PROVIDER — 例如 openai 或 ollama
MEM0_LITE_EMBEDDER_MODEL — 嵌入模型（使用 Ollama 时默认 nomic-embed-text）
完整默认值：架构。可选评分：反馈模式（MEM0_LITE_FEEDBACK_MODE，默认关闭）。
合并到你的 MCP 主机配置文件中。Cursor：~/.cursor/mcp.json 或项目根目录下的 .cursor/mcp.json。替换目录路径。
{
"mcpServers": {
"mem0-lite": {
"command": "uv",
"args": ["run", "--directory", "/ABS/PATH/TO/mem0-lite", "mem0-lite", "mcp"],
"env": { "OPENAI_API_KEY": "sk-..." }
}
}
}粘贴到 AGENTS.md（或用户规则中）。工具的具体调用方式在 MCP schemas 中。以下说明何时使用。
## Memory
MCP `mem0-lite` is registered. Search at task start, context switch, or when the user references past work. After the reply, write only if a new agent would benefit in days/weeks (future utility, novelty, factual, no secrets). Do not announce recall. Prefer `update_memory`. Most turns write nothing.每次工具调用都会向 ~/.mem0/access-log.jsonl 追加一行（工具、代理、连接复用、锁等待、耗时）。汇总：
uv run python scripts/access-report.py追踪记忆存储的有效性。
启用后，工具响应中包含 ts 字段，可用于通过 rate_memory_call 工具对响应进行评分。
启用后（MEM0_LITE_FEEDBACK_MODE=1）：
检索响应中包含 ts
代理可以在命中、未命中或噪声后调用 rate_memory_call(call_ts, helpful, reason)
评分追加到 ~/.mem0/feedback.jsonl
scripts/access-report.py 将评分与访问日志中的 ts 关联，并报告覆盖率、有效率和反馈延迟（ts − call_ts）
在主机的 env 块中启用（不要将其放入默认注册片段中）：
"env": {
"OPENAI_API_KEY": "sk-...",
"MEM0_LITE_FEEDBACK_MODE": "1"
}如果启用，请在 AGENTS.md 中添加此内容。
After a retrieval call, if you used a hit, clearly missed a fact, or got noise, call rate_memory_call with that response's ts.reason 的值为：used | empty_ok | miss | noise | stale | bad_query。跳过预期为空的空结果。 n
| 文档 | n| 架构 | 进程模型、工具、数据布局 | n| 替代 Mem0 架构 | 平台、Docker REST、SDK 进程内、此仓库 | n| 替代存储 | 文件、SQLite、向量数据库、托管内存 | n| 决策 | 为什么选择 MCP，为什么infer=false，为什么不是 REST | n| 坑点 | 密钥在 git 中，/tmp Qdrant，CLI 作为工具，查询重写 | n
第二个 Mem0 服务器实现
与平台兼容的 HTTP API
mem0-cli 的替代品
图记忆（实际上仅限平台）
此仓库采用 MIT 许可证。mem0ai 仍为 Apache-2.0。此封装文件归你所有，可保持本地使用。
Store a memory. Prefer infer=false with a self-contained third-person fact.
memory_type: decision | convention | anti_pattern | user_preference | task_learning | environmental | identity | rule | project
infer=true lets mem0 extract facts from raw conversation; skip for explicit facts.
Never store secrets. Skip small talk, tool dumps, and one-shot commands.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| infer | No | ||
| user_id | No | ||
| agent_id | No | ||
| memory_type | No | ||
| metadata_json | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains how infer works (fact extraction vs. explicit input) and warns about content to avoid. However, it omits details like whether the tool is idempotent, what happens on duplicate text, or any authentication/permission requirements. The output schema exists but the description doesn't mention what is returned. This is adequate but not comprehensive.
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: three bullet-pointed sentences plus a list of memory types. Every sentence earns its place – first states purpose, second gives infer guidance, third lists what to avoid. The memory type list is efficiently presented. No filler or repetition.
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 6 parameters (1 required) and no schema descriptions, the description covers the core but not all. It explains text, infer, and memory_type well, but user_id, agent_id, and metadata_json are unaddressed. The output schema exists so return values need not be explained, but the missing parameter semantics reduce completeness. Adequate for basic use but not for full parameter understanding.
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 bears the full burden. It explains text (self-contained third-person fact), infer (extraction mode), and lists memory_type options. However, user_id, agent_id, and metadata_json are not described at all. The description adds value for three key parameters but leaves three others undocumented, which is a gap given the lack of schema descriptions.
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 opens with 'Store a memory' – a clear verb+resource pair that immediately identifies the tool's purpose. It distinguishes from sibling tools (update, search, etc.) by its creation focus, and adds context about preferred usage ('Prefer infer=false with a self-contained third-person fact'). This is specific and unambiguous.
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 explicit guidance: when to use infer=false vs infer=true, what memory types are available, and what not to store (secrets, small talk, tool dumps). It implies this tool is for new memories but does not explicitly contrast with update (e.g., 'use update_memory to modify'). Still, the guidance is actionable and reduces misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all memories in scope. Requires confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| user_id | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses destructive behavior and the confirm requirement, but does not explain what 'in scope' means, whether the operation is reversible, or how it interacts with user_id/agent_id parameters. This is insufficient for a destructive action.
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 two sentences and concise, but it sacrifices necessary detail. While no sentence is wasted, the brevity leaves significant gaps, making it inadequate for the tool's complexity.
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 has 3 parameters, 0% schema coverage, no annotations, and an output schema, the description is severely incomplete. It fails to explain scope, parameter usage, or behavior, making it nearly useless for an AI agent.
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%, and the description adds no meaning to the three parameters. It only mentions 'confirm=true' without linking it to the confirm parameter. The roles of user_id and agent_id are entirely unexplained.
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 verb 'Delete' and the resource 'all memories', which distinguishes it from the sibling 'delete_memory' that deletes a single memory. However, the phrase 'in scope' is vague and could be more precise.
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 mentions 'Requires confirm=true', which provides a necessary prerequisite but fails to advise when to use this tool versus alternatives like 'delete_memory' or 'search_memories'. No context on scope or user/agent filtering is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one memory by id.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without revealing whether the deletion is permanent, irreversible, or requires special permissions. The output schema exists but its content is not hinted at, leaving the agent uncertain about the tool's behavior.
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 sentence that is very concise and front-loaded. However, it is so brief that it sacrifices informational value. While it earns points for efficiency, it could be slightly longer to include critical details without losing conciseness.
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 simplicity (1 parameter, output schema exists), the description is incomplete. It does not explain what happens if the id is invalid, whether the operation is idempotent, or what the output contains. The agent lacks enough context to use the tool reliably without additional knowledge.
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% and the parameter 'memory_id' has no description in the schema. The description adds only 'by id', which does not clarify the expected format (e.g., UUID, integer) or provide any guidance beyond the parameter name. The description fails to compensate for the lack of schema documentation.
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 'Delete one memory by id.' clearly states the verb (delete), resource (memory), and method (by id). It distinguishes from sibling 'delete_all_memories' which deletes multiple memories, making the purpose specific and unambiguous.
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 'delete_all_memories' or 'update_memory'. There is no mention of prerequisites (e.g., memory must exist) or when not to use it. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one memory by id. When MEM0_LITE_FEEDBACK_MODE is enabled, rate via rate_memory_call(call_ts).
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds a behavioral note about feedback mode, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it disclose any other behavioral traits like permissions or side effects. The 'Fetch' verb implies read-only, but that's implicit.
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 two sentences with no extraneous content. The primary action is front-loaded. The second sentence adds relevant conditional information. It is concise and well-structured.
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 simplicity (one parameter, output schema present), the description covers the core functionality and adds a special condition. It does not explain error handling or return format, but the output schema covers return values. Overall, it is sufficiently complete for a fetch-by-id tool.
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 adds 'by id' which clarifies the parameter's role, but the parameter name 'memory_id' is already self-explanatory. The description does not provide format, constraints, or examples. For a single required parameter, this is minimally adequate.
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 'Fetch one memory by id' clearly states the verb and resource. It distinguishes from siblings like search_memories (which searches) and list_memories (which lists all). The purpose is specific and unambiguous.
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 does not provide guidance on when to use this tool vs alternatives. It only mentions a conditional action (rate via rate_memory_call) but does not explain when to choose get_memory_by_id over search_memories or list_memories. No explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories in scope. Not a substitute for search_memories. When MEM0_LITE_FEEDBACK_MODE is enabled, responses include ts; rate useful/miss/noise via rate_memory_call.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| user_id | No | ||
| agent_id | No | ||
| memory_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds one behavioral detail about response including 'ts' when feedback mode is enabled, but fails to explain core behavior such as scope determination (how 'in scope' is resolved), filtering logic, pagination, or side effects. The lack of any side-effect or safety mention is a gap.
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?
Two short sentences with the main action front-loaded. The second sentence adds a conditional behavioral note. No redundant or extraneous text. Every sentence earns its place.
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?
An output schema exists, so return values are not required in the description. However, the description does not clarify what 'in scope' means, how the optional filter parameters (user_id, agent_id, memory_type) influence the result, or what the default behavior is (e.g., returning all memories if no filters set). This leaves the tool partially under-described 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?
The input schema has 0% description coverage, and the description does not explain any of the four parameters (top_k, user_id, agent_id, memory_type). There is no compensation for the missing schema descriptions, leaving the agent without semantic understanding of how these parameters affect the tool's behavior.
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 states the verb 'List' and resource 'memories', but 'in scope' is vague and does not clearly differentiate from sibling tools like search_memories. The negative hint 'Not a substitute for search_memories' implies a distinction but does not specify what list_memories actually does differently.
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 only a single negative hint about not substituting search_memories, without any positive guidance on when to use this tool versus alternatives like get_memory_by_id or update_memory. No when-not or alternative descriptions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a prior retrieval by call_ts (from response ts when MEM0_LITE_FEEDBACK_MODE is enabled).
Call when you used a hit, clearly missed a fact, or got irrelevant noise. Skip empty-and-expected results.
reason: used | empty_ok | miss | noise | stale | bad_query
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| reason | Yes | ||
| call_ts | Yes | ||
| helpful | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the enabling mode condition and lists reason categories, but does not address idempotency, side effects, error handling, or permissions. This is acceptable but leaves significant gaps.
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 three sentences and gets to the point quickly. The first sentence states the action, the second gives usage scenarios, and the third lists reasons. It is efficient, though the list of reasons could be formatted more cleanly.
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 moderate complexity (4 parameters, 3 required, output schema exists), the description covers the core use case and reasons but omits explanations for the 'helpful' and 'note' parameters. It also lacks details on prerequisites or error conditions. The output schema reduces the need to describe return values, but the input semantics are incomplete.
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 adds meaning for 'call_ts' (timestamp from response) and 'reason' (enumerates values), but does not mention the 'helpful' boolean or the optional 'note' parameter. Since schema description coverage is 0%, the description partially compensates but leaves two parameters completely unexplained.
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 verb 'rate' and the resource 'prior retrieval by call_ts', distinguishing it from sibling CRUD/search tools. The phrase 'rate a prior retrieval' is specific enough to convey the feedback function, though the jargon about MEM0_LITE_FEEDBACK_MODE slightly reduces clarity.
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 concrete scenarios for when to call ('used a hit', 'missed a fact', 'irrelevant noise') and when to skip ('empty-and-expected results'). It does not explicitly name alternative tools, but siblings are clearly for memory management, not rating, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search. Rewrite the query to 3-6 keywords matching stored third-person facts.
Do not pass the user's raw message. Drop pronouns and question words.
When useful, run 2-4 parallel searches with memory_type: decision, convention, anti_pattern, or omit for catch-all.
When MEM0_LITE_FEEDBACK_MODE is enabled, responses include ts; rate useful/miss/noise via rate_memory_call.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| user_id | No | ||
| agent_id | No | ||
| memory_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses critical behaviors: query rewriting requirements, parallel search strategy, memory_type filtering, and post-search rating feedback loop. This surpasses what structured fields alone convey, making the tool's operation highly transparent.
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 5 sentences, each adding unique value: semantic search definition, query rewriting rule, parameter filtering advice, feedback mode instruction. No filler, front-loaded with the core action. Every sentence earns its place.
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 5 parameters (1 required), no annotations, and an output schema exists, the description fully addresses core usage, query preparation, parallel search strategy, and feedback integration. The presence of output schema reduces the need to explain return values, making it complete for a semantic search tool.
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 coverage is 0% (no description in input schema), so the description must compensate. It adds meaning to query (rewrite to 3-6 keywords) and memory_type (decision, convention, anti_pattern, or omit). It does not detail top_k, user_id, or agent_id parameters, leaving some ambiguity, but covers the most critical ones well.
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 explicitly states 'Semantic search' and instructs rewriting queries to 3-6 keywords matching stored third-person facts, distinguishing it from siblings like get_memory_by_id (retrieval by ID) or list_memories (listing without semantic search). It mentions memory_type categories for parallel searches, providing specific verb+resource clarity.
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 gives clear when-to-use guidance: rewrite query to remove pronouns/question words, run 2-4 parallel searches with specific memory_type values, and when MEM0_LITE_FEEDBACK_MODE is enabled, rate matches via rate_memory_call. This explicitly differentiates from siblings and provides actionable usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace memory text in place. Prefer this over delete+add when a fact changed.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 of behavioral disclosure. It states that the tool replaces memory text in place, implying a mutation. However, it does not mention whether the operation is idempotent, what happens to the old memory text, or if there are any side effects (e.g., updating timestamps). Given the lack of annotations, this is a minor gap, but the core behavior is clear enough to score a 3.
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 sentence with two distinct clauses, each earning its place: the first states the action, the second provides usage guidance. It is front-loaded and wastes no words.
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 low complexity (2 required params, no nested objects, no enums) and the presence of an output schema, the description is nearly complete. It covers the purpose, usage, and parameter semantics adequately. The only missing piece is a brief note on return behavior (e.g., 'returns the updated memory object'), which the output schema might cover, but since the description doesn't reference it, it's a minor gap.
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 0%, so the description must compensate. It adds meaning by explaining that 'text' is the new content and 'memory_id' identifies which memory to update, which is not explicitly stated in the schema. However, it does not provide format details (e.g., allowed characters, length limits) or explain the behavior of required fields beyond what can be inferred. The output schema exists but is not referenced, which is a minor omission.
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 uses a specific verb ('replace') and resource ('memory text'), and clearly distinguishes from siblings like 'add_memory' and 'delete_memory' by stating 'prefer this over delete+add when a fact changed.' This makes the purpose unambiguous and sets it apart from alternative tools.
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 explicitly tells the agent when to use this tool (when a fact changed) and when not to ('over delete+add'), directly comparing with sibling tools. This provides clear decision-making guidance with no ambiguity.
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.
v0.1.0add_memorydelete_all_memoriesdelete_memoryget_memory_by_idlist_memoriesrate_memory_callsearch_memoriesupdate_memoryScored across 8 tools
Each tool has a clearly distinct purpose: add, update, search, get by ID, list, delete single, delete all, and rate. Potential confusion between search_memories and list_memories is addressed in descriptions, ensuring no ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., update_memory, search_memories, delete_all_memories). The naming is predictable and uniform across the set.
With 8 tools, the server is well-scoped for a memory management system. The count covers essential operations without being excessive or insufficient.
The tool surface provides complete coverage for memory CRUD (add, get, update, delete) plus search, listing, bulk deletion, and a feedback rating mechanism. No obvious gaps for the declared purpose.
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Hosted agent memory: store, search, and recall facts across sessions from any MCP client.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.