Vollständige Dokumentation -- Anleitungen, Tool-Referenz, Architektur und Wartung unter cachorro.space
Ein Drop-in-Ersatz für Anthropics MCP Memory Server -- mit SQLite-Persistenz, Vektor-Embeddings, semantischer Suche und Limbic Scoring für dynamisches Ranking.
Warum? Der ursprüngliche Server schreibt bei jedem Vorgang den gesamten Wissensgraphen in eine JSONL-Datei, ohne Sperren oder atomare Schreibvorgänge. Bei gleichzeitigem Zugriff (mehrere MCP-Clients) führt dies zu Datenbeschädigungen. Dieser Server ersetzt dies durch eine ordnungsgemäße SQLite-Datenbank.
Drop-in-kompatibel mit Anthropics 8 MCP-Tools (gleiche API, gleiches Verhalten)
SQLite + WAL -- sicherer gleichzeitiger Zugriff, keine beschädigten JSONL-Dateien mehr
Semantische Suche via sqlite-vec + ONNX-Embeddings (94+ Sprachen)
Hybride Suche (FTS5 + KNN) -- kombiniert Volltext-BM25 und semantische Vektorsuche mittels Reciprocal Rank Fusion. Findet Entitäten durch exakte Begriffe oder semantische Ähnlichkeit -- oder beides gleichzeitig.
Limbic Scoring -- dynamisches Re-Ranking mit Salienz, zeitlichem Zerfall, Ko-Auftretenssignalen und hybriden Such-Scores. Transparent für die API.
Semantische Deduplizierung -- automatischer similarity_flag bei neuen Beobachtungen, wenn die Kosinus-Ähnlichkeit >= 0,85 ist (mit Containment-Scoring für asymmetrische Textlängen)
Konsolidierungsberichte -- schreibgeschützte Gesundheitschecks für Split-Kandidaten, markierte Beobachtungen, veraltete Entitäten und große Entitäten
Verbesserter Aktualitätszerfall -- entity_access_log-Tracking mit ALPHA_CONS=0.2 Mehrtages-Konsolidierungssignal
Containment-Fix -- korrekte Handhabung asymmetrischer Textlängen (Verhältnis >= 2.0) beim Deduplizierungs-Scoring
Beobachtungsarten -- semantische Klassifizierung von Beobachtungen (hallazgo, decision, estado, spec, metrica, metadata, generic)
Beobachtungs-Ablösung -- explizite Ersetzungskette: neue Beobachtungen können alte ablösen, die dann als abgelöst markiert werden
Entitätsstatus -- Lebenszyklus-Tracking: activo, pausado, completado, archivado (mit statusbewusster Such-De-Boostung)
Relationskontext + Gültigkeit -- Relationen tragen optionalen Kontext, active/ended_at-Felder für zeitliche Gültigkeit
Automatische inverse Relationen -- contains/parte_de-Paare werden automatisch erstellt
Reflektionen -- unabhängige narrative Ebene: freier Text, der an Entitäten/Sitzungen/Relationen/Globales angehängt wird, mit Autor- und Stimmungsmetadaten, durchsuchbar via semantischer + FTS5-Hybridsuche
Leichtgewichtig -- ~500 MB insgesamt gegenüber ~1,4 GB bei ähnlichen Lösungen
Migration -- Import mit einem Klick aus Anthropics JSONL-Format
Zero-Config -- funktioniert sofort; das Embedding-Modell wird bei der ersten Verwendung automatisch heruntergeladen
Related MCP server: Mind Keg MCP
{
"mcpServers": {
"memory": {
"command": ["uvx", "--from", "git+https://github.com/Yarlan1503/mcp-memory", "mcp-memory"]
}
}
}Oder lokal klonen und ausführen:
{
"mcpServers": {
"memory": {
"command": ["uv", "run", "--directory", "/path/to/mcp-memory", "mcp-memory"]
}
}
}Das Embedding-Modell (sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2, ~465 MB, ONNX CPU, 384-dim) wird bei der ersten Verwendung eines semantischen Tools automatisch heruntergeladen. Es ist keine manuelle Einrichtung erforderlich.
Falls Sie es vorab herunterladen möchten:
cd /path/to/mcp-memory
uv run python scripts/download_model.pyDies ist ein dünner Wrapper, der dieselben Dateien nach ~/.cache/mcp-memory-v2/models/ herunterlädt. Ohne das Modell funktionieren alle nicht-semantischen Tools einwandfrei -- nur search_semantic ist nicht verfügbar.
Wenn Sie eine Anthropic MCP Memory JSONL-Datei haben, verwenden Sie das migrate-Tool oder rufen Sie es direkt auf:
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 Tools insgesamt, gruppiert nach Funktion:
Tool | Beschreibung |
| Erstellt oder aktualisiert Entitäten (führt Beobachtungen bei Konflikten zusammen). Akzeptiert das Feld |
| Erstellt typisierte Relationen zwischen Entitäten. Akzeptiert |
| Fügt Beobachtungen zu einer bestehenden Entität hinzu. Akzeptiert |
| Löscht Entitäten und alle ihre Relationen/Beobachtungen |
| Löscht spezifische Beobachtungen von einer Entität |
| Löscht spezifische Relationen zwischen Entitäten |
Tool | Beschreibung |
| Suche nach Teilzeichenfolge (Name, Typ, Beobachtungsinhalt) |
| Ruft Entitäten nach Namen ab. Akzeptiert |
| Semantische Suche via Vektor-Embeddings mit Limbic Scoring Re-Ranking |
Tool | Beschreibung |
| Analysiert, ob eine Entität aufgeteilt werden muss (semantisches Clustering + TF-IDF-Fallback) |
| Schlägt eine Aufteilung mit vorgeschlagenen Entitätsnamen und Relationen vor |
| Führt eine genehmigte Aufteilung aus (atomare Transaktion) |
| Findet alle Entitäten, die aufgeteilt werden müssen |
| Findet semantisch duplizierte Beobachtungen innerhalb einer Entität (Kosinus + Containment) |
| Generiert einen schreibgeschützten Konsolidierungsbericht (Split-Kandidaten, markierte Obs, veraltete Entitäten) |
Tool | Beschreibung |
| Import aus Anthropics JSONL-Format (idempotent) |
| Lässt eine aktive Relation auslaufen, indem |
Tool | Beschreibung |
| Fügt eine narrative Reflektion zu einer Entität, Sitzung, Relation oder global hinzu. Akzeptiert Autor, Inhalt und Stimmung. |
| Durchsucht Reflektionen via semantischer + FTS5-Hybrid-Suche (RRF). Optionale Filter: Autor, Stimmung, target_type. |
8 kanonische Typen:
Typ | Zweck |
| Langfristige Projekte |
| Arbeitssitzungen |
| Systeme und Tools |
| Architektonische/technische Entscheidungen |
| Zeitgebundene Ereignisse |
| Personen |
| Externe Ressourcen |
| Standard-Fallback |
Semantische Klassifizierung für Beobachtungen:
Art | Zweck |
| Erkenntnisse und Entdeckungen |
| Getroffene Entscheidungen |
| Status-Snapshots |
| Spezifikationen und Anforderungen |
| Quantitative Messungen |
| Systemgenerierte Metadaten |
| Standard (keine Klassifizierung) |
Relationstypen sind frei wählbar (kein restriktives Enum). Das einzige fest kodierte inverse Paar ist:
Typ | Invers | Automatisch erstellt |
|
| Ja |
|
| Ja |
Übliche Konventionen im Wissensgraphen (nicht erzwungen):
Strukturell: contiene / parte_de
Produktion: producido_por, contribuye_a
Abhängigkeit: depende_de, usa
Zeitlich: continua (Legacy-Mapping → contribuye_a), sucedido_por
Legacy-Typen werden bei der Erstellung via _constants.py normalisiert: continua → contribuye_a (mit Kontext "Sitzung Fortsetzung"), documentado_en → producido_por (mit Kontext "dokumentiert in").
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 configSpeicher: SQLite mit WAL-Journaling, 5-Sekunden Busy-Timeout, CASCADE-Löschungen
Embeddings: Singleton ONNX-Modell, das beim Start einmal geladen wird, L2-normalisierte Kosinus-Suche
Limbic Scoring: Re-Rankt hybride (KNN + FTS5) Kandidaten unter Verwendung von Wichtigkeitssignalen, zeitlichem Zerfall, Ko-Auftretensmustern und RRF-Scores -- transparent für die API
Nebenläufigkeit: retry_on_locked-Dekorator mit exponentiellem Backoff + Jitter bei 19 Schreibmethoden. Sicherer Multi-Client-Zugriff (getestet mit gleichzeitigen Opencode-Sitzungen)
Reflektionen: Parallele FTS5 (reflection_fts) und Vektor (reflection_embeddings) Indizes für die narrative Ebene, durchsucht über dieselbe RRF-Hybrid-Pipeline
Jede Entität erhält einen Embedding-Vektor, der aus ihrem Text mittels einer Head+Tail+Diversity-Auswahlstrategie generiert wird (Budget: 480 Token):
"{name} ({entity_type}) | {obs1} | {obs2} | ... | Rel: type -> target; ..."Wenn Sie search_semantic aufrufen, läuft die Pipeline parallel:
Semantisch (KNN) -- die Abfrage wird kodiert und mittels sqlite-vec mit Entitätsvektoren verglichen
Volltext (FTS5) -- die Abfrage wird gegen einen BM25-Index durchsucht, der Namen, Typen und Beobachtungsinhalte abdeckt
Zusammenführung (RRF) -- Ergebnisse aus beiden Zweigen werden mittels Reciprocal Rank Fusion kombiniert (score(d) = Sum 1/(k + rank))
Die zusammengeführten Kandidaten werden dann von der Limbic Scoring-Engine neu bewertet, die Folgendes berücksichtigt:
Salienz -- häufig aufgerufene und gut vernetzte Entitäten werden höher bewertet
Zeitlicher Zerfall -- kürzlich verwendete Entitäten bleiben aktuell; unberührte Entitäten verblassen
Ko-Auftreten -- Entitäten, die oft zusammen erscheinen, verstärken sich gegenseitig
Die Ausgabe enthält limbic_score, scoring (Aufschlüsselung nach Wichtigkeit/Zeit/Ko-Auftreten) und optional rrf_score, wenn FTS5 Ergebnisse beisteuert.
Für vollständige technische Details, siehe DOCUMENTATION.md -- enthält die Scoring-Formel, RRF-Konstanten, Schema-DDL und Architekturdiagramme.
uv run pytest tests/ -v402 Tests in 23 Testdateien, die alle Tools, Embeddings, Scoring und Grenzfälle abdecken. Null Regressionen.
Python >= 3.12
uv (Paketmanager)
Paket | Zweck |
| MCP-Server-Framework |
| Anforderungs-/Antwortvalidierung |
| Vektor-Ähnlichkeitssuche in SQLite |
| ONNX-Modell-Inferenz (CPU) |
| HuggingFace Fast-Tokenizer |
| Vektoroperationen |
| Semantisches Clustering für Entitätsaufteilung |
| Modell-Download |
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.
