完整文档 -- 指南、工具参考、架构和维护，请访问 cachorro.space
这是 Anthropic MCP Memory 服务器 的直接替代品 -- 具备 SQLite 持久化、向量嵌入、语义搜索以及用于动态排序的 Limbic Scoring（边缘系统评分）。
为什么选择它？ 原始服务器在每次操作时都会将整个知识图谱写入 JSONL 文件，且没有锁定或原子写入机制。在并发访问（多个 MCP 客户端）下，这会导致数据损坏。本服务器将其替换为标准的 SQLite 数据库。
直接兼容 Anthropic 的 8 个 MCP 工具（相同的 API，相同的行为）
SQLite + WAL -- 安全的并发访问，不再有损坏的 JSONL
语义搜索 -- 通过 sqlite-vec + ONNX 嵌入（支持 94+ 种语言）
混合搜索 (FTS5 + KNN) -- 通过倒数排名融合 (Reciprocal Rank Fusion) 结合全文 BM25 和语义向量搜索。可以通过精确术语或语义相似度查找实体，也可以两者同时使用。
Limbic Scoring -- 具有显著性、时间衰减、共现信号和混合搜索分数的动态重排序。对 API 透明。
语义去重 -- 当余弦相似度 >= 0.85 时，自动对新观察结果标记 similarity_flag（包含针对非对称文本长度的包含评分）
整合报告 -- 针对拆分候选、已标记观察、陈旧实体和大型实体的只读健康检查
改进的近因衰减 -- entity_access_log 跟踪，带有 ALPHA_CONS=0.2 的多日整合信号
包含修复 -- 在去重评分中正确处理非对称文本长度（比率 >= 2.0）
观察类型 -- 观察结果的语义分类（hallazgo, decision, estado, spec, metrica, metadata, generic）
观察覆盖 -- 显式的替换链：新的观察结果可以覆盖旧的，旧的会被标记为已覆盖的时间戳
实体状态 -- 生命周期跟踪：activo, pausado, completado, archivado（带有状态感知的搜索降权）
关系上下文 + 有效期 -- 关系带有可选的上下文、active/ended_at 字段，用于时间有效性
自动反向关系 -- 自动创建 contains/parte_de 对
反思 (Reflections) -- 独立的叙事层：附加到实体/会话/关系/全局的自由格式散文，带有作者和情绪元数据，可通过语义 + FTS5 混合搜索进行搜索
轻量级 -- 总计约 500 MB，而类似解决方案约为 1.4 GB
迁移 -- 一键导入 Anthropic 的 JSONL 格式
零配置 -- 开箱即用；嵌入模型在首次使用时自动下载
Related MCP server: Mind Keg MCP
{
"mcpServers": {
"memory": {
"command": ["uvx", "--from", "git+https://github.com/Yarlan1503/mcp-memory", "mcp-memory"]
}
}
}或者克隆并在本地运行：
{
"mcpServers": {
"memory": {
"command": ["uv", "run", "--directory", "/path/to/mcp-memory", "mcp-memory"]
}
}
}当调用任何语义工具时，嵌入模型（sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2，约 465 MB，ONNX CPU，384 维）会在首次使用时自动下载。无需手动设置。
如果您更喜欢预先下载它：
cd /path/to/mcp-memory
uv run python scripts/download_model.py这是一个轻量级包装器，将相同的文件下载到 ~/.cache/mcp-memory-v2/models/。如果没有该模型，所有非语义工具均可正常工作 -- 只有 search_semantic 不可用。
如果您有 Anthropic MCP Memory JSONL 文件，请使用 migrate 工具或直接调用它：
uv run python -c "
from mcp_memory.storage import MemoryStore
from mcp_memory.migrate import migrate_jsonl
store = MemoryStore()
store.init_db()
result = migrate_jsonl(store, '~/.config/opencode/mcp-memory.jsonl')
print(result)
"共 19 个工具，按功能分组：
工具 | 描述 |
| 创建或更新实体（冲突时合并观察结果）。接受 |
| 在实体之间创建类型化关系。接受 |
| 向现有实体添加观察结果。接受 |
| 删除实体及其所有关系/观察结果 |
| 从实体中删除特定的观察结果 |
| 删除实体之间的特定关系 |
工具 | 描述 |
| 按子字符串搜索（名称、类型、观察内容） |
| 按名称检索实体。接受 |
| 通过向量嵌入进行语义搜索，并使用 Limbic Scoring 重排序 |
工具 | 描述 |
| 分析实体是否需要拆分（语义聚类 + TF-IDF 回退） |
| 提出拆分建议，包含建议的实体名称和关系 |
| 执行已批准的拆分（原子事务） |
| 查找所有需要拆分的实体 |
| 查找实体内语义重复的观察结果（余弦 + 包含） |
| 生成只读整合报告（拆分候选、已标记观察、陈旧实体） |
工具 | 描述 |
| 从 Anthropic 的 JSONL 格式导入（幂等） |
| 通过设置 |
工具 | 描述 |
| 向任何实体、会话、关系或全局添加叙事反思。接受作者、内容和情绪。 |
| 通过语义 + FTS5 混合 (RRF) 搜索反思。可选过滤器：作者、情绪、target_type。 |
8 种规范类型：
类型 | 用途 |
| 长期项目 |
| 工作会话 |
| 系统和工具 |
| 架构/技术决策 |
| 有时间限制的事件 |
| 人员 |
| 外部资源 |
| 默认回退 |
观察结果的语义分类：
类型 | 用途 |
| 发现和结论 |
| 已做出的决策 |
| 状态快照 |
| 规范和要求 |
| 定量测量 |
| 系统生成的元数据 |
| 默认（无分类） |
关系类型是自由格式的（没有限制性枚举）。唯一硬编码的反向对是：
类型 | 反向 | 自动创建 |
|
| 是 |
|
| 是 |
知识图谱中使用的常见约定（未强制执行）：
结构性: contiene / parte_de
生产: producido_por, contribuye_a
依赖: depende_de, usa
时间性: continua (旧映射 → contribuye_a), sucedido_por
旧类型在创建时通过 _constants.py 进行规范化：continua → contribuye_a（上下文为“sesión continuación”），documentado_en → producido_por（上下文为“documentado en”）。
server.py (97 lines) — FastMCP init + tool registration
├── tools/
│ ├── core.py — 6 CRUD tools (Anthropic-compatible)
│ ├── search.py — 3 search tools + ranking helpers
│ ├── entity_mgmt.py — 6 entity management tools
│ ├── reflections.py — 2 reflection tools
│ └── relations.py — 2 tools (migrate, end_relation)
├── storage/ — 7 mixins + constants via multiple inheritance
│ ├── __init__.py — MemoryStore facade (134 lines)
│ ├── schema.py — SchemaMixin (migrations)
│ ├── core.py — CoreMixin (entity/obs CRUD)
│ ├── relations.py — RelationsMixin
│ ├── search.py — SearchMixin (FTS + embeddings)
│ ├── access.py — AccessMixin
│ ├── reflections.py — ReflectionsMixin
│ ├── consolidation.py — ConsolidationMixin
│ └── _constants.py — Inverse relation & validation constants
├── embeddings.py — EmbeddingEngine (ONNX, lazy load, auto-download)
├── scoring.py — Limbic Scoring + RRF
├── entity_splitter.py — Semantic clustering (Agglomerative + c-TF-IDF fallback)
├── retry.py — retry_on_locked (concurrency)
└── config.py — Input limits + A/B config存储: 带有 WAL 日志的 SQLite，5 秒忙碌超时，CASCADE 删除
嵌入: 单例 ONNX 模型在启动时加载一次，L2 归一化余弦搜索
Limbic Scoring: 使用重要性信号、时间衰减、共现模式和 RRF 分数对混合 (KNN + FTS5) 候选进行重排序 -- 对 API 透明
并发: 19 个写入方法上带有 retry_on_locked 装饰器，具有指数退避 + 抖动。安全的多客户端访问（已通过并发 opencode 会话测试）
反思: 用于叙事层的并行 FTS5 (reflection_fts) 和向量 (reflection_embeddings) 索引，通过相同的 RRF 混合管道进行搜索
每个实体都会获得一个从其文本生成的嵌入向量，使用 Head+Tail+Diversity 选择策略（预算：480 个 token）：
"{name} ({entity_type}) | {obs1} | {obs2} | ... | Rel: type -> target; ..."当您调用 search_semantic 时，管道并行运行：
语义 (KNN) -- 查询被编码并通过 sqlite-vec 与实体向量进行比较
全文 (FTS5) -- 查询在覆盖名称、类型和观察内容的 BM25 索引中进行搜索
合并 (RRF) -- 两个分支的结果使用倒数排名融合 (score(d) = Sum 1/(k + rank)) 进行合并
合并后的候选者随后由 Limbic Scoring 引擎进行重排序，该引擎考虑：
显著性 -- 频繁访问且连接良好的实体排名更高
时间衰减 -- 最近使用的实体保持新鲜；未触及的实体逐渐淡出
共现 -- 经常一起出现的实体会相互加强
输出包括 limbic_score、scoring（重要性/时间/共现分解），以及当 FTS5 提供结果时可选的 rrf_score。
有关完整技术细节，请参阅 DOCUMENTATION.md -- 包括评分公式、RRF 常量、模式 DDL 和架构图。
uv run pytest tests/ -v跨 23 个测试文件的 402 个测试，涵盖所有工具、嵌入、评分和边缘情况。零回归。
Python >= 3.12
uv (包管理器)
包 | 用途 |
| MCP 服务器框架 |
| 请求/响应验证 |
| SQLite 中的向量相似度搜索 |
| ONNX 模型推理 (CPU) |
| HuggingFace 快速分词器 |
| 向量运算 |
| 用于实体拆分的语义聚类 |
| 模型下载 |
MIT
Add observations to an existing entity.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| observations | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's an 'add' operation to an 'existing entity', implying mutation but not specifying permissions, side effects (e.g., appending vs. replacing), or response behavior. It lacks details on rate limits, idempotency, or error handling, leaving 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 a single, efficient sentence with no wasted words. It's front-loaded with the core action, but could be more structured (e.g., clarifying parameters). Overall, it's appropriately sized for a simple tool.
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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks parameter details, usage context, and behavioral traits. The output schema mitigates some gaps, but overall completeness is limited for a mutation 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 mentions 'observations' and 'entity' but doesn't explain parameters: 'name' (likely entity identifier) and 'observations' (array of strings). No details on format, constraints, or examples are given, failing to add meaningful semantics beyond the bare schema.
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 'Add observations to an existing entity' clearly states the action (add) and target (observations to entity), but it's vague about what 'observations' are (e.g., notes, data points) and doesn't distinguish from siblings like 'delete_observations' or 'create_entities'. It avoids tautology but lacks specificity.
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. It doesn't mention prerequisites (e.g., entity must exist), exclusions, or compare to siblings like 'create_entities' (for new entities) or 'delete_observations'. Usage is implied only by the action 'add' to 'existing entity'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update entities in the knowledge graph. If an entity already exists, merge observations (don't overwrite). Returns the created/updated entities.
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 adds value by explaining the merge behavior ('merge observations, don't overwrite') and the return action ('Returns the created/updated entities'), which are crucial for understanding the tool's effect. However, it lacks details on permissions, rate limits, error handling, or side effects, which are important 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 highly concise and well-structured, consisting of three sentences that each serve a clear purpose: stating the action, explaining the merge behavior, and describing the return. There is no wasted text, and key information is front-loaded, making it easy to scan and understand 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 tool's complexity as a mutation operation with no annotations, the description does a decent job by covering the core action, merge behavior, and return. The presence of an output schema reduces the need to detail return values, but additional context on error cases or usage scenarios would enhance completeness. It's adequate but could be more robust for a tool with potential side effects.
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, so the description must compensate. It mentions 'entities' as the parameter but doesn't explain the structure or required fields beyond 'merge observations.' This adds minimal semantic context, as the schema only indicates an array of objects. The description partially helps but doesn't fully clarify what constitutes a valid entity or how merging works in practice.
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 tool's purpose: 'Create or update entities in the knowledge graph.' It specifies the verb ('Create or update'), resource ('entities'), and location ('knowledge graph'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'add_observations' or 'create_relations,' which handle related but distinct operations.
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 implies usage through the phrase 'If an entity already exists, merge observations (don't overwrite),' suggesting this tool is for upsert operations rather than pure creation. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'add_observations' (for adding data to existing entities) or 'delete_entities' (for removal), nor does it mention prerequisites or exclusions, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create relations between entities. Both entities must exist. Returns created relations or errors for missing entities.
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions that it 'Returns created relations or errors for missing entities', which adds some context about outcomes and error conditions. However, it lacks details on permissions, rate limits, or other behavioral traits like whether the operation is idempotent or reversible.
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 with two sentences that are front-loaded and waste no words. Every sentence adds value: the first states the action and prerequisite, the second explains the return behavior.
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 (a creation tool with 1 parameter but 0% schema coverage) and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and outcome but lacks details on parameters and behavioral context, making it incomplete for safe and effective use without additional documentation.
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 doesn't explain the 'relations' parameter beyond implying it's an array of relations to create. No details are provided on what properties the relation objects should have, their structure, or validation rules, leaving significant gaps in parameter understanding.
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 ('Create relations') and the resource ('between entities'), making the purpose understandable. It distinguishes from siblings like 'delete_relations' by specifying creation, but doesn't explicitly differentiate from other tools like 'create_entities' beyond the resource type.
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 implies usage by stating 'Both entities must exist', suggesting a prerequisite for using this tool. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'create_entities' or 'delete_relations', leaving the context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete entities and all their relations/observations.
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 that deletion includes 'all their relations/observations', which adds useful context about cascading effects. However, it lacks details on permissions, irreversibility, rate limits, or response behavior, leaving significant gaps for a destructive operation.
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 directly states the action and scope without fluff. It's appropriately sized and front-loaded for quick understanding.
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 destructive nature, no annotations, and 0% schema coverage, the description is incomplete—it misses critical details like safety warnings or output expectations. However, the presence of an output schema mitigates some need to explain return values, keeping it from a lower score.
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 'entityNames' implicitly but provides no semantics—no explanation of what entities are, format requirements, or constraints. This fails to add meaningful value beyond the bare schema.
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 ('Delete') and the target ('entities and all their relations/observations'), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'delete_observations' or 'delete_relations', which handle partial deletions, so it's not a perfect 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 'delete_observations' or 'delete_relations', nor does it mention prerequisites or context. It implies a broad deletion scope but lacks explicit usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific observations from an entity.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| observations | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, authentication needs, rate limits, error conditions, or what happens to the entity after observations are removed. This is inadequate for a destructive 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 wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 destructive tool with 2 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It doesn't explain the mutation's impact, parameter usage, or relationship to siblings. The output schema might cover return values, but the description fails to provide necessary context for safe and correct 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. It mentions 'observations' and 'entity' but doesn't explain the 'name' and 'observations' parameters beyond what's implied. No details on parameter formats, constraints, or examples are provided. The description adds minimal semantic value over the bare schema.
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 specific observations from an entity' clearly states the action (delete) and target (observations from an entity), but it's somewhat vague about what 'observations' and 'entity' mean in this context. It distinguishes from siblings like 'delete_entities' by focusing on observations rather than entire entities, but lacks specificity about the domain or system.
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. It doesn't mention prerequisites (e.g., needing an existing entity), exclusions, or compare to siblings like 'add_observations' for when deletion is appropriate versus addition. The agent must 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 relations between entities.
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. 'Delete' implies a destructive mutation, but the description doesn't specify permissions required, whether deletions are permanent/reversible, rate limits, or what happens to related data. It mentions nothing about the output format despite having an 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 extremely concise at just four words, with no wasted language. However, this brevity comes at the cost of completeness - it's arguably too terse for a destructive operation with undocumented parameters.
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 destructive mutation tool with zero annotation coverage, 0% schema description coverage, and one completely undocumented parameter, the description is inadequate. While an output schema exists (reducing need to describe returns), the description fails to address critical behavioral aspects like safety, permissions, or parameter requirements that would help an agent use this tool correctly.
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%, meaning the single parameter 'relations' is completely undocumented in the schema. The description adds no information about what 'relations' should contain, its structure, or examples. For a parameter with zero schema documentation, the description fails to compensate.
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 relations between entities' clearly states the action (delete) and target (relations between entities), avoiding tautology. However, it lacks specificity about what 'relations' and 'entities' mean in this context, and doesn't distinguish this tool from sibling tools like 'delete_entities' or 'delete_observations'.
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. There are multiple sibling deletion tools (delete_entities, delete_observations) with no indication of when this specific relation-deletion tool is appropriate. No prerequisites, constraints, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Migrate data from Anthropic MCP Memory JSONL format to SQLite. This is idempotent — running it multiple times won't duplicate data.
| Name | Required | Description | Default |
|---|---|---|---|
| source_path | No | /home/cachorro/.config/opencode/mcp-memory.jsonl |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses idempotency ('running it multiple times won't duplicate data'), which is crucial for understanding safe repeated use. However, it does not mention potential side effects like data overwriting, error handling, or performance characteristics.
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 zero waste: the first states the purpose clearly, and the second adds critical behavioral information (idempotency). It is appropriately sized and front-loaded, with every sentence earning 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 the tool's complexity (data migration with 1 parameter) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose and idempotency, but lacks details on error conditions, prerequisites, or output implications, leaving minor gaps.
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 has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter's purpose by mentioning 'source_path' in context ('Anthropic MCP Memory JSONL format'), but does not explicitly explain the parameter's role or format requirements. The description adds some meaning beyond the bare schema, though not fully detailed.
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 specific action ('Migrate data') with precise source and target formats ('from Anthropic MCP Memory JSONL format to SQLite'), distinguishing it from sibling tools that handle CRUD operations on entities, relations, and observations rather than format conversion.
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 implies usage for data migration between specific formats, but does not explicitly state when to use this tool versus alternatives (e.g., for initial setup vs. ongoing updates) or mention prerequisites like file existence. It provides some context but lacks explicit guidance on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open specific nodes by name. Returns full entity data with observations.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions that the tool 'Returns full entity data with observations', which is useful, but doesn't cover critical aspects like whether this is a read-only operation, if it requires specific permissions, error handling, or performance characteristics. The description is too sparse for a tool that presumably accesses node 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 two sentences, with no wasted words. However, this brevity comes at the cost of completeness - it's arguably too terse given the tool's likely complexity and lack of annotations/schema documentation.
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 an output schema (which should document return values), the description doesn't need to explain return format details. However, with no annotations, 0% schema description coverage, and multiple sibling tools with similar purposes, the description should provide more context about when and how to use this specific tool versus alternatives.
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 1 parameter with 0% description coverage, so the schema provides no semantic information. The description only vaguely references 'by name' without explaining what 'names' represents (e.g., node IDs, labels, or something else), acceptable formats, or constraints. This leaves the parameter meaning ambiguous.
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 ('Open specific nodes by name') and resource ('nodes'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'search_nodes' or 'read_graph', which appear to have overlapping functionality with nodes/entities.
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_nodes' or 'read_graph'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the entire knowledge graph. Returns all entities with observations and all relations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions the return content but lacks details on behavioral traits such as potential performance impact, rate limits, authentication requirements, or whether this operation is safe for large graphs. The description is minimal and doesn't compensate for the absence of annotations.
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 front-loads the action ('Read the entire knowledge graph') and specifies the return value. There is no wasted language, making it highly concise and well-structured for quick understanding.
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 no parameters, an output schema exists, and annotations are absent, the description is minimally complete. It states what the tool does and what it returns, but for a graph-reading operation, it lacks context on scalability, error handling, or comparison to siblings, leaving gaps in overall understanding despite the structured fields.
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 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required, aligning with the schema. Baseline is 4 for zero parameters, as the description doesn't contradict or add unnecessary information.
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 tool's purpose with the verb 'Read' and resource 'entire knowledge graph', specifying it returns 'all entities with observations and all relations'. However, it doesn't explicitly differentiate from sibling tools like 'search_nodes' or 'search_semantic', which might offer filtered or partial graph access.
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. It doesn't mention scenarios like retrieving the full graph for analysis versus using search tools for specific queries, nor does it discuss prerequisites or performance considerations for reading the entire graph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nodes in the knowledge graph by name, type, or observation content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the search functionality but doesn't cover important traits like whether it's read-only (implied but not explicit), pagination, rate limits, authentication needs, or what happens on no matches. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence with zero waste. It's front-loaded with the core purpose and includes all necessary search criteria without redundancy. Every word earns its place, making it highly 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 moderate complexity (search with one parameter), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose and search fields but lacks usage guidelines and behavioral details that would make it more complete for agent selection.
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 1 parameter with 0% description coverage, so the schema provides no semantic context. The description adds value by implying the 'query' parameter can search by 'name, type, or observation content', giving some meaning beyond the bare schema. However, it doesn't detail query syntax, format, or examples, leaving room for improvement.
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 ('Search for nodes') and the target resource ('knowledge graph'), with specific search criteria ('by name, type, or observation content'). It distinguishes from some siblings like 'create_entities' or 'delete_observations' by being a search operation, but doesn't explicitly differentiate from 'search_semantic' or 'open_nodes' which might also involve node retrieval.
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_semantic' or 'open_nodes'. It mentions search criteria but doesn't specify scenarios, prerequisites, or exclusions. Without this context, an agent might struggle to choose between similar search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search using vector embeddings. Finds entities most similar to the query. Requires the embedding model to be downloaded (run download_model.py first).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the prerequisite model download requirement, which is useful behavioral context. However, it doesn't mention performance characteristics, rate limits, error conditions, or what 'entities' refers to specifically, leaving gaps for a search operation.
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—two sentences with zero waste. The first sentence states the purpose, and the second provides critical prerequisite information. Every word earns its place, and it's front-loaded with the core functionality.
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 an output schema (which handles return values), no annotations, and low schema coverage, the description is moderately complete. It covers the core purpose and a key prerequisite but lacks details on parameters, error handling, and differentiation from siblings like 'search_nodes', which is needed for full contextual 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 schema provides no parameter documentation. The description mentions 'query' implicitly but doesn't explain what constitutes a valid query or the meaning of 'limit' (e.g., maximum results). It adds minimal semantic value beyond what's inferable from parameter names.
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 tool performs 'semantic search using vector embeddings' and 'finds entities most similar to the query', which specifies the verb (search/find) and resource (entities). However, it doesn't explicitly differentiate from sibling 'search_nodes', leaving some ambiguity about when to use one versus the other.
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 clear context about prerequisites ('Requires the embedding model to be downloaded') and implies usage for similarity-based searches. It doesn't explicitly state when NOT to use it or name alternatives like 'search_nodes', but the semantic focus offers reasonable guidance.
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_observationscreate_entitiescreate_relationsdelete_entitiesdelete_observationsdelete_relationsmigrateopen_nodesread_graphsearch_nodessearch_semanticScored across 11 tools
Each tool has a clearly distinct purpose with no significant overlap: entity/relation/observation operations are separated, search functions target different methods, and administrative tools like migrate are unique. The descriptions reinforce distinct boundaries, making misselection unlikely.
All tools follow a consistent verb_noun naming pattern (e.g., add_observations, create_entities, delete_relations), with no deviations in style or convention. This predictability aids agent understanding and tool selection.
With 11 tools, the set is well-scoped for a knowledge graph memory system, covering core operations (CRUD for entities, relations, observations), search capabilities, and administrative functions. Each tool earns its place without bloat.
The tool surface provides complete coverage for the knowledge graph domain: full CRUD for entities, relations, and observations; multiple search methods (by attribute, semantic); graph reading; and data migration. No obvious gaps exist for typical agent workflows.
Hosted persistent memory with semantic search, importance and TTL for AI agents.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Mem0-compatible persistent memory for AI agents: write facts once, recall them semantically.
Persistent AI memory with semantic search, conflict detection, and ticketing.
