Documentación completa -- guías, referencia de herramientas, arquitectura y mantenimiento en cachorro.space
Un reemplazo directo para el servidor MCP Memory de Anthropic -- con persistencia en SQLite, incrustaciones vectoriales, búsqueda semántica y Puntuación Límbica para una clasificación dinámica.
¿Por qué? El servidor original escribe todo el grafo de conocimiento en un archivo JSONL en cada operación, sin bloqueos ni escrituras atómicas. Bajo acceso concurrente (múltiples clientes MCP), esto provoca corrupción de datos. Este servidor reemplaza eso con una base de datos SQLite adecuada.
Compatible directamente con las 8 herramientas MCP de Anthropic (misma API, mismo comportamiento)
SQLite + WAL -- acceso concurrente seguro, no más JSONL corruptos
Búsqueda semántica mediante sqlite-vec + incrustaciones ONNX (más de 94 idiomas)
Búsqueda híbrida (FTS5 + KNN) -- combina búsqueda de texto completo BM25 y búsqueda vectorial semántica mediante Reciprocal Rank Fusion. Encuentra entidades por términos exactos o similitud semántica -- o ambos a la vez.
Puntuación Límbica -- re-clasificación dinámica con relevancia, decaimiento temporal, señales de co-ocurrencia y puntuaciones de búsqueda híbrida. Transparente para la API.
Deduplicación semántica -- similarity_flag automático en nuevas observaciones cuando la similitud de coseno >= 0.85 (con puntuación de contención para longitudes de texto asimétricas)
Informes de consolidación -- comprobaciones de estado de solo lectura para candidatos a división, observaciones marcadas, entidades obsoletas y entidades grandes
Decaimiento de recencia mejorado -- seguimiento de entity_access_log con señal de consolidación multidía ALPHA_CONS=0.2
Corrección de contención -- manejo adecuado de longitudes de texto asimétricas (relación >= 2.0) en la puntuación de deduplicación
Tipos de observación -- clasificación semántica de observaciones (hallazgo, decision, estado, spec, metrica, metadata, generic)
Supersedición de observaciones -- cadena de reemplazo explícita: las nuevas observaciones pueden reemplazar a las antiguas, las cuales se marcan con fecha como reemplazadas
Estado de entidad -- seguimiento del ciclo de vida: activo, pausado, completado, archivado (con des-priorización en búsquedas según el estado)
Contexto de relación + vigencia -- las relaciones llevan contexto opcional, campos active/ended_at para validez temporal
Relaciones inversas automáticas -- pares contains/parte_de creados automáticamente
Reflexiones -- capa narrativa independiente: prosa de forma libre adjunta a entidades/sesiones/relaciones/global, con metadatos de autor y estado de ánimo, buscable mediante búsqueda híbrida semántica + FTS5
Ligero -- ~500 MB en total frente a ~1.4 GB de soluciones similares
Migración -- importación con un clic desde el formato JSONL de Anthropic
Configuración cero -- funciona desde el primer momento; el modelo de incrustación se descarga automáticamente en el primer uso
Related MCP server: Mind Keg MCP
{
"mcpServers": {
"memory": {
"command": ["uvx", "--from", "git+https://github.com/Yarlan1503/mcp-memory", "mcp-memory"]
}
}
}O clona y ejecuta localmente:
{
"mcpServers": {
"memory": {
"command": ["uv", "run", "--directory", "/path/to/mcp-memory", "mcp-memory"]
}
}
}El modelo de incrustación (sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2, ~465 MB, ONNX CPU, 384-dim) se descarga automáticamente en el primer uso cuando se llama a cualquier herramienta semántica. No se requiere configuración manual.
Si prefieres descargarlo previamente:
cd /path/to/mcp-memory
uv run python scripts/download_model.pyEste es un envoltorio ligero que descarga los mismos archivos a ~/.cache/mcp-memory-v2/models/. Sin el modelo, todas las herramientas no semánticas funcionan bien -- solo search_semantic no estará disponible.
Si tienes un archivo JSONL de MCP Memory de Anthropic, usa la herramienta migrate o llámala directamente:
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 herramientas en total, agrupadas por función:
Herramienta | Descripción |
| Crea o actualiza entidades (fusiona observaciones en caso de conflicto). Acepta el campo |
| Crea relaciones tipadas entre entidades. Acepta |
| Añade observaciones a una entidad existente. Acepta parámetros |
| Elimina entidades y todas sus relaciones/observaciones |
| Elimina observaciones específicas de una entidad |
| Elimina relaciones específicas entre entidades |
Herramienta | Descripción |
| Busca por subcadena (nombre, tipo, contenido de observación) |
| Recupera entidades por nombre. Acepta filtro |
| Búsqueda semántica mediante incrustaciones vectoriales con re-clasificación de Puntuación Límbica |
Herramienta | Descripción |
| Analiza si una entidad necesita ser dividida (agrupación semántica + respaldo TF-IDF) |
| Propone una división con nombres de entidad y relaciones sugeridas |
| Ejecuta una división aprobada (transacción atómica) |
| Encuentra todas las entidades que necesitan ser divididas |
| Encuentra observaciones duplicadas semánticamente dentro de una entidad (coseno + contención) |
| Genera un informe de consolidación de solo lectura (candidatos a división, obs marcadas, entidades obsoletas) |
Herramienta | Descripción |
| Importa desde el formato JSONL de Anthropic (idempotente) |
| Expira una relación activa estableciendo |
Herramienta | Descripción |
| Añade una reflexión narrativa a cualquier entidad, sesión, relación o global. Acepta autor, contenido y estado de ánimo. |
| Busca reflexiones mediante híbrido semántico + FTS5 (RRF). Filtros opcionales: autor, mood, target_type. |
8 tipos canónicos:
Tipo | Propósito |
| Proyectos de larga duración |
| Sesiones de trabajo |
| Sistemas y herramientas |
| Decisiones arquitectónicas/técnicas |
| Eventos con límite de tiempo |
| Personas |
| Recursos externos |
| Respaldo predeterminado |
Clasificación semántica para observaciones:
Tipo | Propósito |
| Hallazgos y descubrimientos |
| Decisiones tomadas |
| Instantáneas de estado |
| Especificaciones y requisitos |
| Mediciones cuantitativas |
| Metadatos generados por el sistema |
| Predeterminado (sin clasificación) |
Los tipos de relación son de forma libre (sin enumeración restrictiva). El único par inverso codificado es:
Tipo | Inverso | Creado automáticamente |
|
| Sí |
|
| Sí |
Convenciones comunes utilizadas en el grafo de conocimiento (no forzadas):
Estructural: contiene / parte_de
Producción: producido_por, contribuye_a
Dependencia: depende_de, usa
Temporal: continua (mapeo heredado → contribuye_a), sucedido_por
Los tipos heredados se normalizan en el momento de la creación mediante _constants.py: continua → contribuye_a (con contexto "sesión continuación"), documentado_en → producido_por (con contexto "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 configAlmacenamiento: SQLite con registro WAL, tiempo de espera de ocupado de 5 segundos, eliminaciones CASCADE
Incrustaciones: Modelo ONNX singleton cargado una vez al inicio, búsqueda de coseno normalizada L2
Puntuación Límbica: Re-clasifica candidatos híbridos (KNN + FTS5) usando señales de importancia, decaimiento temporal, patrones de co-ocurrencia y puntuaciones RRF -- transparente para la API
Concurrencia: Decorador retry_on_locked con retroceso exponencial + jitter en 19 métodos de escritura. Acceso seguro multi-cliente (probado con sesiones opencode concurrentes)
Reflexiones: Índices paralelos FTS5 (reflection_fts) y vectoriales (reflection_embeddings) para la capa narrativa, buscados a través del mismo pipeline híbrido RRF
Cada entidad obtiene un vector de incrustación generado a partir de su texto utilizando una estrategia de selección Head+Tail+Diversity (presupuesto: 480 tokens):
"{name} ({entity_type}) | {obs1} | {obs2} | ... | Rel: type -> target; ..."Cuando llamas a search_semantic, el pipeline se ejecuta en paralelo:
Semántico (KNN) -- la consulta se codifica y se compara con los vectores de entidad mediante sqlite-vec
Texto completo (FTS5) -- la consulta se busca contra un índice BM25 que cubre nombres, tipos y contenido de observación
Fusión (RRF) -- los resultados de ambas ramas se combinan usando Reciprocal Rank Fusion (score(d) = Sum 1/(k + rank))
Los candidatos fusionados son luego re-clasificados por el motor de Puntuación Límbica, que considera:
Relevancia -- las entidades accedidas frecuentemente y bien conectadas se clasifican más alto
Decaimiento temporal -- las entidades usadas recientemente se mantienen frescas; las entidades no tocadas se desvanecen
Co-ocurrencia -- las entidades que aparecen juntas a menudo se refuerzan entre sí
La salida incluye limbic_score, scoring (desglose de importancia/temporal/cooc) y opcionalmente rrf_score cuando FTS5 aporta resultados.
Para detalles técnicos completos, consulta DOCUMENTATION.md -- incluye la fórmula de puntuación, constantes RRF, DDL de esquema y diagramas de arquitectura.
uv run pytest tests/ -v402 pruebas en 23 archivos de prueba que cubren todas las herramientas, incrustaciones, puntuación y casos extremos. Cero regresiones.
Python >= 3.12
uv (gestor de paquetes)
Paquete | Propósito |
| Framework de servidor MCP |
| Validación de solicitud/respuesta |
| Búsqueda de similitud vectorial en SQLite |
| Inferencia de modelo ONNX (CPU) |
| Tokenizador rápido de HuggingFace |
| Operaciones vectoriales |
| Agrupación semántica para división de entidades |
| Descarga de modelos |
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.
