Skalierbares, leistungsstarkes Wissensgraphen-Speichersystem mit semantischem Abruf, kontextuellem Abruf und zeitlicher Wahrnehmung. Bietet jedem LLM-Client, der das Modellkontextprotokoll unterstützt (z. B. Claude Desktop, Cursor, Github Copilot), einen robusten, adaptiven und persistenten ontologischen Langzeitspeicher.
Entitäten sind die primären Knoten im Wissensgraphen. Jede Entität verfügt über:
Ein eindeutiger Name (Kennung)
Ein Entitätstyp (z. B. „Person“, „Organisation“, „Ereignis“)
Eine Liste von Beobachtungen
Vektoreinbettungen (für die semantische Suche)
Vollständiger Versionsverlauf
Beispiel:
{
"name": "John_Smith",
"entityType": "person",
"observations": ["Speaks fluent Spanish"]
}Relationen definieren gerichtete Verbindungen zwischen Entitäten mit erweiterten Eigenschaften:
Stärkeindikatoren (0,0-1,0)
Konfidenzniveaus (0,0–1,0)
Umfangreiche Metadaten (Quelle, Zeitstempel, Tags)
Zeitliches Bewusstsein mit Versionsverlauf
Zeitbasierter Vertrauensverlust
Beispiel:
{
"from": "John_Smith",
"to": "Anthropic",
"relationType": "works_at",
"strength": 0.9,
"confidence": 0.95,
"metadata": {
"source": "linkedin_profile",
"last_verified": "2025-03-21"
}
}Related MCP server: Graph Memory MCP
Memento MCP verwendet Neo4j als Speicher-Backend und bietet eine einheitliche Lösung sowohl für die Graphspeicherung als auch für die Vektorsuchfunktionen.
Unified Storage : Konsolidiert sowohl den Grafik- als auch den Vektorspeicher in einer einzigen Datenbank
Native Graph-Operationen : Speziell für Graph-Traversierung und Abfragen entwickelt
Integrierte Vektorsuche : Vektorähnlichkeitssuche für Einbettungen direkt in Neo4j integriert
Skalierbarkeit : Bessere Leistung mit großen Wissensgraphen
Vereinfachte Architektur : Klares Design mit einer einzigen Datenbank für alle Vorgänge
Neo4j 5.13+ (erforderlich für Vektorsuchfunktionen)
Der einfachste Weg, mit Neo4j zu beginnen, ist die Verwendung von Neo4j Desktop :
Laden Sie Neo4j Desktop von https://neo4j.com/download/ herunter und installieren Sie es
Erstellen eines neuen Projekts
Hinzufügen einer neuen Datenbank
Setzen Sie das Passwort auf memento_password (oder Ihr bevorzugtes Passwort).
Starten der Datenbank
Die Neo4j-Datenbank wird verfügbar sein unter:
Bolt-URI : bolt://127.0.0.1:7687 (für Treiberverbindungen)
HTTP : http://127.0.0.1:7474 (für Neo4j-Browser-UI)
Standardanmeldeinformationen : Benutzername: neo4j , Passwort: memento_password (oder was auch immer Sie konfiguriert haben)
Alternativ können Sie Docker Compose verwenden, um Neo4j auszuführen:
# Start Neo4j container
docker-compose up -d neo4j
# Stop Neo4j container
docker-compose stop neo4j
# Remove Neo4j container (preserves data)
docker-compose rm neo4jBei Verwendung von Docker ist die Neo4j-Datenbank verfügbar unter:
Bolt-URI : bolt://127.0.0.1:7687 (für Treiberverbindungen)
HTTP : http://127.0.0.1:7474 (für Neo4j-Browser-UI)
Standardanmeldeinformationen : Benutzername: neo4j , Passwort: memento_password
Neo4j-Daten bleiben aufgrund der Docker-Volume-Konfiguration in der Datei docker-compose.yml über Containerneustarts und sogar Versionsupgrades hinweg erhalten:
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/importDiese Zuordnungen stellen Folgendes sicher:
Das Verzeichnis /data (enthält alle Datenbankdateien) bleibt auf Ihrem Host unter ./neo4j-data bestehen.
Das Verzeichnis /logs bleibt auf Ihrem Host unter ./neo4j-logs bestehen
Das Verzeichnis /import (zum Importieren von Datendateien) bleibt unter ./neo4j-import bestehen.
Sie können diese Pfade in Ihrer Datei docker-compose.yml ändern, um Daten bei Bedarf an anderen Orten zu speichern.
Sie können Neo4j-Editionen und -Versionen ohne Datenverlust ändern:
Aktualisieren Sie die Neo4j-Image-Version in docker-compose.yml
Starten Sie den Container mit docker-compose down && docker-compose up -d neo4j
Initialisieren Sie das Schema mit npm run neo4j:init
Die Daten bleiben während dieses Vorgangs erhalten, solange die Volume-Zuordnungen gleich bleiben.
Wenn Sie Ihre Neo4j-Datenbank vollständig zurücksetzen müssen:
# Stop the container
docker-compose stop neo4j
# Remove the container
docker-compose rm -f neo4j
# Delete the data directory contents
rm -rf ./neo4j-data/*
# Restart the container
docker-compose up -d neo4j
# Reinitialize the schema
npm run neo4j:initUm Ihre Neo4j-Daten zu sichern, können Sie einfach das Datenverzeichnis kopieren:
# Make a backup of the Neo4j data
cp -r ./neo4j-data ./neo4j-data-backup-$(date +%Y%m%d)Memento MCP enthält Befehlszeilenprogramme zur Verwaltung von Neo4j-Vorgängen:
Testen Sie die Verbindung zu Ihrer Neo4j-Datenbank:
# Test with default settings
npm run neo4j:test
# Test with custom settings
npm run neo4j:test -- --uri bolt://127.0.0.1:7687 --username myuser --password mypass --database neo4jIm Normalbetrieb erfolgt die Initialisierung des Neo4j-Schemas automatisch, wenn Memento MCP eine Verbindung zur Datenbank herstellt. Für den regulären Gebrauch müssen Sie keine manuellen Befehle ausführen.
Die folgenden Befehle sind nur für Entwicklungs-, Test- oder erweiterte Anpassungsszenarien erforderlich:
# Initialize with default settings (only needed for development or troubleshooting)
npm run neo4j:init
# Initialize with custom vector dimensions
npm run neo4j:init -- --dimensions 768 --similarity euclidean
# Force recreation of all constraints and indexes
npm run neo4j:init -- --recreate
# Combine multiple options
npm run neo4j:init -- --vector-index custom_index --dimensions 384 --recreateSuchen Sie semantisch verwandte Entitäten auf der Grundlage ihrer Bedeutung und nicht nur anhand von Schlüsselwörtern:
Vektoreinbettungen : Entitäten werden mithilfe der Einbettungsmodelle von OpenAI automatisch in einen hochdimensionalen Vektorraum kodiert
Kosinus-Ähnlichkeit : Finden Sie verwandte Konzepte, auch wenn sie unterschiedliche Terminologie verwenden
Konfigurierbare Schwellenwerte : Legen Sie Mindestähnlichkeitswerte fest, um die Ergebnisrelevanz zu steuern
Cross-Modal-Suche : Abfrage mit Text, um relevante Entitäten zu finden, unabhängig davon, wie sie beschrieben wurden
Unterstützung mehrerer Modelle : Kompatibel mit mehreren Einbettungsmodellen (OpenAI text-embedding-3-small/large)
Kontextbezogene Abfrage : Rufen Sie Informationen basierend auf der semantischen Bedeutung und nicht auf genauen Schlüsselwortübereinstimmungen ab
Optimierte Standardeinstellungen : Angepasste Parameter für das Gleichgewicht zwischen Präzision und Rückruf (Ähnlichkeitsschwelle 0,6, Hybridsuche aktiviert)
Hybridsuche : Kombiniert semantische und Stichwortsuche für umfassendere Ergebnisse
Adaptive Suche : Das System wählt intelligent zwischen reiner Vektor-, reiner Stichwort- oder Hybridsuche basierend auf Abfragemerkmalen und verfügbaren Daten
Leistungsoptimierung : Priorisiert die Vektorsuche für semantisches Verständnis und behält gleichzeitig Fallback-Mechanismen für mehr Ausfallsicherheit bei
Abfragebasierte Verarbeitung : Passt die Suchstrategie basierend auf der Abfragekomplexität und den verfügbaren Entitätseinbettungen an
Verfolgen Sie den vollständigen Verlauf von Entitäten und Beziehungen mit der zeitpunktbezogenen Graphenabfrage:
Vollständiger Versionsverlauf : Jede Änderung an einer Entität oder Beziehung wird mit Zeitstempeln gespeichert
Point-in-Time-Abfragen : Rufen Sie den genauen Status des Wissensgraphen zu jedem beliebigen Zeitpunkt in der Vergangenheit ab
Änderungsverfolgung : Zeichnet automatisch die Zeitstempel „createdAt“, „updatedAt“, „validFrom“ und „validTo“ auf
Zeitliche Konsistenz : Behalten Sie eine historisch genaue Sicht auf die Entwicklung des Wissens bei
Zerstörungsfreie Updates : Updates erstellen neue Versionen, anstatt vorhandene Daten zu überschreiben
Zeitbasiertes Filtern : Filtern Sie Diagrammelemente basierend auf zeitlichen Kriterien
Historische Erkundung : Untersuchen Sie, wie sich bestimmte Informationen im Laufe der Zeit verändert haben
Die Vertrauenswürdigkeit von Beziehungen nimmt mit der Zeit automatisch ab, basierend auf einer konfigurierbaren Halbwertszeit:
Zeitbasierter Verfall : Das Vertrauen in Beziehungen nimmt natürlich mit der Zeit ab, wenn es nicht gestärkt wird
Konfigurierbare Halbwertszeit : Definieren Sie, wie schnell Informationen unsicherer werden (Standard: 30 Tage)
Mindestvertrauensgrenzen : Legen Sie Schwellenwerte fest, um einen übermäßigen Verfall wichtiger Informationen zu verhindern
Zerfallsmetadaten : Jede Beziehung enthält detaillierte Informationen zur Zerfallsberechnung
Zerstörungsfrei : Die ursprünglichen Vertrauenswerte bleiben neben den verfallenen Werten erhalten
Reinforcement Learning : Beziehungen gewinnen an Vertrauen, wenn sie durch neue Beobachtungen verstärkt werden
Flexibilität der Referenzzeit : Berechnen Sie den Zerfall basierend auf beliebigen Referenzzeiten für die historische Analyse
Umfangreiche Metadatenunterstützung für Entitäten und Beziehungen mit benutzerdefinierten Feldern:
Quellenverfolgung : Aufzeichnen, woher die Informationen stammen (Benutzereingaben, Analysen, externe Quellen)
Konfidenzniveaus : Weisen Sie Beziehungen basierend auf der Gewissheit Konfidenzwerte (0,0-1,0) zu
Beziehungsstärke : Geben Sie die Wichtigkeit oder Stärke von Beziehungen an (0,0–1,0).
Zeitliche Metadaten : Verfolgen Sie, wann Informationen hinzugefügt, geändert oder überprüft wurden
Benutzerdefinierte Tags : Fügen Sie beliebige Tags zur Klassifizierung und Filterung hinzu
Strukturierte Daten : Speichern Sie komplexe strukturierte Daten in Metadatenfeldern
Abfrageunterstützung : Suchen und Filtern basierend auf Metadateneigenschaften
Erweiterbares Schema : Fügen Sie nach Bedarf benutzerdefinierte Felder hinzu, ohne das Kerndatenmodell zu ändern
Die folgenden Tools stehen LLM-Client-Hosts über das Model Context Protocol zur Verfügung:
Entitäten erstellen
Erstellen Sie mehrere neue Entitäten im Wissensgraphen
Eingabe: entities (Array von Objekten)
Jedes Objekt enthält:
name (Zeichenfolge): Entitätskennung
entityType (Zeichenfolge): Typklassifizierung
observations (Zeichenfolge[]): Zugehörige Beobachtungen
Beobachtungen hinzufügen
Hinzufügen neuer Beobachtungen zu vorhandenen Entitäten
Eingabe: observations (Array von Objekten)
Jedes Objekt enthält:
entityName (Zeichenfolge): Zielentität
contents (Zeichenfolge[]): Neue hinzuzufügende Beobachtungen
delete_entities
Entfernen von Entitäten und ihren Beziehungen
Eingabe: entityNames (string[])
Beobachtungen löschen
Entfernen Sie bestimmte Beobachtungen von Entitäten
Eingabe: deletions (Array von Objekten)
Jedes Objekt enthält:
entityName (Zeichenfolge): Zielentität
observations (Zeichenfolge[]): Zu entfernende Beobachtungen
Beziehungen erstellen
Erstellen Sie mehrere neue Beziehungen zwischen Entitäten mit erweiterten Eigenschaften
Eingabe: relations (Array von Objekten)
Jedes Objekt enthält:
from (Zeichenfolge): Name der Quell-Entität
to (Zeichenfolge): Name der Zielentität
relationType (Zeichenfolge): Beziehungstyp
strength (Zahl, optional): Beziehungsstärke (0,0-1,0)
confidence (Zahl, optional): Konfidenzniveau (0,0-1,0)
metadata (Objekt, optional): Benutzerdefinierte Metadatenfelder
get_relation
Erhalten Sie eine bestimmte Beziehung mit ihren erweiterten Eigenschaften
Eingang:
from (Zeichenfolge): Name der Quell-Entität
to (Zeichenfolge): Name der Zielentität
relationType (Zeichenfolge): Beziehungstyp
Update-Relation
Aktualisieren einer vorhandenen Beziehung mit erweiterten Eigenschaften
Eingabe: relation (Objekt):
Enthält:
from (Zeichenfolge): Name der Quell-Entität
to (Zeichenfolge): Name der Zielentität
relationType (Zeichenfolge): Beziehungstyp
strength (Zahl, optional): Beziehungsstärke (0,0-1,0)
confidence (Zahl, optional): Konfidenzniveau (0,0-1,0)
metadata (Objekt, optional): Benutzerdefinierte Metadatenfelder
delete_relations
Entfernen Sie bestimmte Beziehungen aus dem Diagramm
Eingabe: relations (Array von Objekten)
Jedes Objekt enthält:
from (Zeichenfolge): Name der Quell-Entität
to (Zeichenfolge): Name der Zielentität
relationType (Zeichenfolge): Beziehungstyp
Diagramm lesen
Lesen Sie den gesamten Wissensgraphen
Keine Eingabe erforderlich
Suchknoten
Suche nach Knoten basierend auf der Abfrage
Eingabe: query (Zeichenfolge)
offene_Knoten
Abrufen bestimmter Knoten nach Namen
Eingabe: names (Zeichenfolge[])
semantische_suche
Semantische Suche nach Entitäten mithilfe von Vektoreinbettungen und Ähnlichkeit
Eingang:
query (Zeichenfolge): Die Textabfrage, nach der semantisch gesucht werden soll
limit (Zahl, optional): Maximale Anzahl der zurückzugebenden Ergebnisse (Standard: 10)
min_similarity (Zahl, optional): Minimaler Ähnlichkeitsschwellenwert (0,0–1,0, Standard: 0,6)
entity_types (string[], optional): Ergebnisse nach Entitätstypen filtern
hybrid_search (boolesch, optional): Kombinieren Sie Schlüsselwort- und semantische Suche (Standard: true)
semantic_weight (Zahl, optional): Gewichtung der semantischen Ergebnisse bei der Hybridsuche (0,0–1,0, Standard: 0,6)
Merkmale:
Wählt intelligent die optimale Suchmethode (Vektor, Schlüsselwort oder Hybrid) basierend auf dem Abfragekontext aus
Behandelt Abfragen ohne semantische Übereinstimmungen mithilfe von Fallback-Mechanismen
Sorgt für eine hohe Leistung durch automatische Optimierungsentscheidungen
get_entity_embedding
Holen Sie sich die Vektoreinbettung für eine bestimmte Entität
Eingang:
entity_name (Zeichenfolge): Der Name der Entität, für die die Einbettung abgerufen werden soll
Entitätsverlauf abrufen
Vollständigen Versionsverlauf einer Entität abrufen
Eingabe: entityName (Zeichenfolge)
Beziehungsverlauf abrufen
Vollständigen Versionsverlauf einer Beziehung abrufen
Eingang:
from (Zeichenfolge): Name der Quell-Entität
to (Zeichenfolge): Name der Zielentität
relationType (Zeichenfolge): Beziehungstyp
get_graph_at_time
Holen Sie sich den Zustand des Graphen zu einem bestimmten Zeitstempel
Eingabe: timestamp (Zahl): Unix-Zeitstempel (Millisekunden seit Epoche)
get_decayed_graph
Erhalten Sie ein Diagramm mit zeitverzögerten Konfidenzwerten
Eingabe: options (Objekt, optional):
reference_time (Zahl): Referenzzeitstempel für die Zerfallsberechnung (Millisekunden seit Epoche)
decay_factor (Zahl): Optionale Überschreibung des Zerfallsfaktors
Konfigurieren Sie Memento MCP mit diesen Umgebungsvariablen:
# Neo4j Connection Settings
NEO4J_URI=bolt://127.0.0.1:7687
NEO4J_USERNAME=neo4j
NEO4J_PASSWORD=memento_password
NEO4J_DATABASE=neo4j
# Vector Search Configuration
NEO4J_VECTOR_INDEX=entity_embeddings
NEO4J_VECTOR_DIMENSIONS=1536
NEO4J_SIMILARITY_FUNCTION=cosine
# Embedding Service Configuration
MEMORY_STORAGE_TYPE=neo4j
OPENAI_API_KEY=your-openai-api-key
OPENAI_EMBEDDING_MODEL=text-embedding-3-small
# Debug Settings
DEBUG=trueDie Neo4j CLI-Tools unterstützen die folgenden Optionen:
--uri <uri> Neo4j server URI (default: bolt://127.0.0.1:7687)
--username <username> Neo4j username (default: neo4j)
--password <password> Neo4j password (default: memento_password)
--database <n> Neo4j database name (default: neo4j)
--vector-index <n> Vector index name (default: entity_embeddings)
--dimensions <number> Vector dimensions (default: 1536)
--similarity <function> Similarity function (cosine|euclidean) (default: cosine)
--recreate Force recreation of constraints and indexes
--no-debug Disable detailed output (debug is ON by default)Verfügbare OpenAI-Einbettungsmodelle:
text-embedding-3-small : Effizient, kostengünstig (1536 Dimensionen)
text-embedding-3-large : Höhere Genauigkeit, teurer (3072 Dimensionen)
text-embedding-ada-002 : Legacy-Modell (1536 Dimensionen)
Um die semantische Suche zu verwenden, müssen Sie die Anmeldeinformationen für die OpenAI-API konfigurieren:
Erhalten Sie einen API-Schlüssel von OpenAI
Konfigurieren Sie Ihre Umgebung mit:
# OpenAI API Key for embeddings
OPENAI_API_KEY=your-openai-api-key
# Default embedding model
OPENAI_EMBEDDING_MODEL=text-embedding-3-smallHinweis : In Testumgebungen simuliert das System die Embedding-Generierung, wenn kein API-Schlüssel angegeben wird. Für Integrationstests wird jedoch die Verwendung echter Embeddings empfohlen.
Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu:
{
"mcpServers": {
"memento": {
"command": "npx",
"args": ["-y", "@gannonh/memento-mcp"],
"env": {
"MEMORY_STORAGE_TYPE": "neo4j",
"NEO4J_URI": "bolt://127.0.0.1:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "memento_password",
"NEO4J_DATABASE": "neo4j",
"NEO4J_VECTOR_INDEX": "entity_embeddings",
"NEO4J_VECTOR_DIMENSIONS": "1536",
"NEO4J_SIMILARITY_FUNCTION": "cosine",
"OPENAI_API_KEY": "your-openai-api-key",
"OPENAI_EMBEDDING_MODEL": "text-embedding-3-small",
"DEBUG": "true"
}
}
}
}Alternativ können Sie für die lokale Entwicklung Folgendes verwenden:
{
"mcpServers": {
"memento": {
"command": "/path/to/node",
"args": ["/path/to/memento-mcp/dist/index.js"],
"env": {
"MEMORY_STORAGE_TYPE": "neo4j",
"NEO4J_URI": "bolt://127.0.0.1:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "memento_password",
"NEO4J_DATABASE": "neo4j",
"NEO4J_VECTOR_INDEX": "entity_embeddings",
"NEO4J_VECTOR_DIMENSIONS": "1536",
"NEO4J_SIMILARITY_FUNCTION": "cosine",
"OPENAI_API_KEY": "your-openai-api-key",
"OPENAI_EMBEDDING_MODEL": "text-embedding-3-small",
"DEBUG": "true"
}
}
}
}Wichtig : Geben Sie das Einbettungsmodell in Ihrer Claude Desktop-Konfiguration immer explizit an, um ein konsistentes Verhalten sicherzustellen.
Für eine optimale Integration mit Claude fügen Sie Ihrer Systemeingabeaufforderung diese Anweisungen hinzu:
You have access to the Memento MCP knowledge graph memory system, which provides you with persistent memory capabilities.
Your memory tools are provided by Memento MCP, a sophisticated knowledge graph implementation.
When asked about past conversations or user information, always check the Memento MCP knowledge graph first.
You should use semantic_search to find relevant information in your memory when answering questions.Nach der Konfiguration kann Claude über natürliche Sprache auf die semantischen Suchfunktionen zugreifen:
So erstellen Sie Entitäten mit semantischen Einbettungen:
User: "Remember that Python is a high-level programming language known for its readability and JavaScript is primarily used for web development."So führen Sie eine semantische Suche durch:
User: "What programming languages do you know about that are good for web development?"So rufen Sie bestimmte Informationen ab:
User: "Tell me everything you know about Python."Der Vorteil dieses Ansatzes liegt darin, dass die Benutzer auf natürliche Weise interagieren können, während das LLM die Komplexität der Auswahl und Verwendung der geeigneten Gedächtnistools übernimmt.
Die adaptiven Suchfunktionen von Memento bieten praktische Vorteile:
Vielseitigkeit der Abfragen : Benutzer müssen sich keine Gedanken über die Formulierung von Fragen machen – das System passt sich automatisch an verschiedene Abfragetypen an
Ausfallsicherheit : Selbst wenn keine semantischen Übereinstimmungen verfügbar sind, kann das System ohne Benutzereingriff auf alternative Methoden zurückgreifen
Leistungseffizienz : Durch die intelligente Auswahl der optimalen Suchmethode gleicht das System Leistung und Relevanz für jede Abfrage aus
Verbesserte Kontextsuche : LLM-Konversationen profitieren von einer besseren Kontextsuche, da das System relevante Informationen in komplexen Wissensgraphen finden kann
Wenn ein Nutzer beispielsweise fragt: „Was wissen Sie über maschinelles Lernen?“, kann das System konzeptionell verwandte Entitäten abrufen, auch wenn diese nicht explizit „maschinelles Lernen“ erwähnen – etwa Entitäten zu neuronalen Netzwerken, Data Science oder bestimmten Algorithmen. Sollte die semantische Suche jedoch nicht genügend Ergebnisse liefern, passt das System seinen Ansatz automatisch an, um sicherzustellen, dass dennoch nützliche Informationen zurückgegeben werden.
Memento MCP verfügt über integrierte Diagnosefunktionen zur Behebung von Problemen bei der Vektorsuche:
Einbettungsüberprüfung : Das System prüft, ob Entitäten gültige Einbettungen haben und generiert diese automatisch, wenn sie fehlen
Vektorindexstatus : Überprüft, ob der Vektorindex vorhanden ist und sich im ONLINE-Status befindet
Fallback-Suche : Wenn die Vektorsuche fehlschlägt, greift das System auf die textbasierte Suche zurück
Detaillierte Protokollierung : Umfassende Protokollierung von Vektorsuchvorgängen zur Fehlerbehebung
Wenn der Debug-Modus aktiviert ist, stehen zusätzliche Diagnosetools zur Verfügung:
diagnose_vector_search : Informationen zum Neo4j-Vektorindex, Einbettungszählungen und Suchfunktion
force_generate_embedding : Erzwingt die Generierung einer Einbettung für eine bestimmte Entität
debug_embedding_config : Informationen zur aktuellen Konfiguration des Einbettungsdienstes
So setzen Sie Ihre Neo4j-Datenbank während der Entwicklung vollständig zurück:
# Stop the container (if using Docker)
docker-compose stop neo4j
# Remove the container (if using Docker)
docker-compose rm -f neo4j
# Delete the data directory (if using Docker)
rm -rf ./neo4j-data/*
# For Neo4j Desktop, right-click your database and select "Drop database"
# Restart the database
# For Docker:
docker-compose up -d neo4j
# For Neo4j Desktop:
# Click the "Start" button for your database
# Reinitialize the schema
npm run neo4j:init# Clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
# Install dependencies
npm install
# Build the project
npm run build
# Run tests
npm test
# Check test coverage
npm run test:coverageSo installieren Sie memento-mcp für Claude Desktop automatisch über Smithery :
npx -y @smithery/cli install @gannonh/memento-mcp --client claudeSie können Memento MCP direkt mit npx ausführen, ohne es global zu installieren:
npx -y @gannonh/memento-mcpDiese Methode wird für die Verwendung mit Claude Desktop und anderen MCP-kompatiblen Clients empfohlen.
Zur Entwicklung oder Mitarbeit am Projekt:
# Install locally
npm install @gannonh/memento-mcp
# Or clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
npm installMIT
Add new observations to existing entities in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| observations | Yes | ||
| strength | No | Default strength value (0.0 to 1.0) for all observations | |
| confidence | No | Default confidence level (0.0 to 1.0) for all observations | |
| metadata | No | Default metadata for all observations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states 'add new observations'. It does not specify what happens if the entity does not exist, whether observations are appended or overwritten, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it omits important context. It is concise but not optimally structured with key usage info.
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 nested object structure and multiple parameters, the description is too sparse. It lacks explanation of relationships between observations and entities, and no output schema is provided to compensate.
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 75%, so the schema already explains most parameters. The description adds no further semantic value beyond the tool name, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Add new observations to existing entities') and clearly distinguishes from sibling tools like 'create_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?
No information is provided about when to use this tool versus alternatives (e.g., updating entities directly). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new entities in your Memento MCP knowledge graph memory system
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states that the tool 'creates' entities, implying mutation, but provides no details on side effects, constraints, error conditions, or whether it is destructive. The description lacks sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core action. It contains no unnecessary words or fluff.
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 (batch creation with many optional fields), the absence of annotations and output schema, the description is minimal. It does not explain return values, error handling, batch limits, or how it relates to sibling tools like 'delete_entities' or 'read_graph'. The context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters, so the baseline is 3. The description does not add meaningful information beyond what the schema already states; it simply mentions 'multiple new entities' without detailing parameter usage.
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', the resource 'multiple new entities', and the context 'Memento MCP knowledge graph memory system'. It effectively distinguishes from sibling tools like 'create_relations' and 'add_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?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use create_entities vs add_observations). There is no mention of prerequisites, exclusions, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new relations between entities in your Memento MCP knowledge graph memory. Relations should be in active voice
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as idempotency, side effects, permissions, or error conditions. The only extra information is 'active voice' style.
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 short (2 sentences) but lacks substance. It is concise but not effectively structured for quick comprehension of tool usage.
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 complex nested schema (multiple relation properties), no output schema, and many sibling tools, the description is too sparse. It does not address error handling, success behavior, or relationships to other tools.
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 reported as 0%, meaning the input schema's own descriptions are not counted. The tool description adds minimal parameter insight beyond the schema: 'Relations should be in active voice' does not clarify parameters.
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 specifies the action 'create multiple new relations' and the target resource 'entities in your Memento MCP knowledge graph memory'. It distinguishes from sibling tools like delete_relations and update_relation.
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 explicit guidance on when to use this tool versus alternatives (e.g., update_relation). The 'active voice' note is a stylistic hint but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple entities and their associated relations from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes | An array of entity names to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It notes cascading deletion of relations, a key trait, but does not mention prerequisites, reversibility, or limits.
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 single-sentence description is concise (12 words), front-loaded with the verb and object, and includes all essential information without fluff.
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 simple delete tool with one parameter and no output schema, the description covers the main action and scope. It could mention permanence but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is clear. The tool description adds no extra semantic meaning beyond what the schema provides.
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 deletes multiple entities and their associated relations, distinguishing it from sibling tools like delete_observations or delete_relations that handle different resources.
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 for when to use the tool (when deleting entities and their relations), but lacks explicit when-not or alternative tool mentions.
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 entities in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| deletions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'delete', implying mutation, but lacks details on side effects, irreversibility, permissions, or what happens if observations don't exist.
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?
Single sentence, front-loaded with the verb 'Delete', no extraneous information. Every word contributes to understanding the tool's core purpose.
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 lack of annotations and output schema, the description is too brief. It does not explain the deletions parameter format, behavior on missing entities or observations, or any return value. Leaves too many gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (per signal), so description should compensate. It does not mention the nested structure with entityName and observations. The schema provides definitions, but the description adds no value beyond it.
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?
Description clearly states the action (delete), resource (observations), and context (Memento MCP knowledge graph memory). Distinguishes from sibling tools like delete_entities and delete_relations.
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 on when to use this tool versus alternatives. Does not mention that delete_entities or delete_relations are for other resource types, or any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple relations from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | An array of relations to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any side effects, error states, or constraints beyond the action of deletion. For a delete operation, more detail on idempotency or cascade effects would be expected.
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 very concise (11 words), but it sacrifices necessary context. It is minimally adequate but not an example of efficient depth.
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?
With no output schema and no annotations, the description lacks details on return values, error handling, or behavioral context. It is incomplete for a tool with a single, complex parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond the schema, earning a baseline score of 3.
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 deletes multiple relations, with a specific verb and resource. It distinguishes from siblings like create_relations and get_relation, though the scope is implied rather than explicit.
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 on when to use this tool vs alternatives (e.g., no mention of deleting single relations vs batch, or when to prefer this over update_relation). The context is missing entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Memento MCP knowledge graph memory with confidence values decayed based on time
| Name | Required | Description | Default |
|---|---|---|---|
| reference_time | No | Optional reference timestamp (in milliseconds since epoch) for decay calculation | |
| decay_factor | No | Optional decay factor override (normally calculated from half-life) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose whether the tool is read-only, destructive, or requires special permissions. It does not explain the decay mechanism or side effects.
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?
Single sentence with no wasted words, but slightly vague. Could be more informative while remaining concise.
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?
Missing return value description (no output schema) and behavioral details. Adequate for a simple retrieval, but incomplete given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds context by linking parameters (reference_time, decay_factor) to the decay behavior, but does not elaborate further.
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 retrieves a knowledge graph with decayed confidence values, distinguishing it from siblings like get_graph_at_time and read_graph.
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 on when to use this tool versus alternatives (e.g., get_graph_at_time, semantic_search), nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the vector embedding for a specific entity from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes | The name of the entity to get the embedding for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states the action without disclosing side effects, read-only nature, performance characteristics, or any constraints. The agent cannot deduce that this is a safe read operation without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. However, it is somewhat terse and could benefit from slight expansion without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally complete. However, it lacks mention of the return type (vector embedding) and does not clarify that it is a read-only operation, which would be helpful for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter 'entity_name'. The description adds only the phrase 'from your Memento MCP knowledge graph memory', which provides context but no additional semantic detail about the parameter itself.
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 it retrieves a vector embedding for a specific entity, using a specific verb ('Get') and resource. It mentions the knowledge graph context, but does not explicitly differentiate from siblings like 'get_entity_history' or 'semantic_search', which are distinct but also involve entities/embeddings.
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. For example, it does not explain how this differs from 'semantic_search' which also uses embeddings, or when to prefer 'get_entity_embedding' over 'get_entity_history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history of an entity from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | The name of the entity to retrieve history for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It only states retrieval of history but does not mention whether it is read-only, any rate limits, or side effects like data mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, efficiently conveying the purpose. However, it could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description is adequate but lacks mention of what the version history format includes or any temporal context, which is relevant given siblings like get_graph_at_time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter 'entityName'. The description adds no additional meaning beyond what the schema already provides, earning a baseline score of 3.
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 (get), the resource (version history of an entity), and the context (from Memento MCP knowledge graph memory). It distinguishes itself from siblings like get_relation_history by specifying 'entity'.
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 such as get_entity_embedding or get_graph_at_time. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Memento MCP knowledge graph memory as it existed at a specific point in time
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes | The timestamp (in milliseconds since epoch) to query the graph at |
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 only states a read operation without mentioning performance implications, return format, or any potential side effects. Essential context is missing.
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, well-structured sentence with no wasted words. It conveys the core functionality efficiently and is easily scannable.
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 lack of output schema and annotations, the description is minimal. It does not explain the output format, limitations on time range or precision, or how this tool relates to other time-based tools. An agent would need additional information to use it effectively.
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 already describes the timestamp parameter with high coverage (100%), including its unit (milliseconds since epoch). The description adds no additional semantic value beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Memento MCP knowledge graph memory' with a specific temporal scope 'as it existed at a specific point in time'. This effectively differentiates it from siblings like read_graph (current state) and get_decayed_graph (decayed state).
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 historical queries but provides no explicit guidance on when to use this tool versus alternatives like get_entity_history or get_decayed_graph. No exclusion criteria or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific relation with its enhanced properties from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The name of the entity where the relation starts | |
| to | Yes | The name of the entity where the relation ends | |
| relationType | Yes | The type of the relation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'enhanced properties' without explaining behavior (e.g., side effects, permissions). It does not reveal what enhanced properties are.
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?
One concise sentence, front-loaded with purpose, though 'from your Memento MCP knowledge graph memory' is slightly verbose.
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?
No output schema and no annotations; the description lacks details about return format, pagination, or error conditions, leaving the agent under-informed for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is described. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'a specific relation', including 'enhanced properties', which distinguishes it from sibling tools like create_relations or delete_relations.
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 on when to use this tool vs alternatives like get_relation_history or read_graph. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history of a relation from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The name of the entity where the relation starts | |
| to | Yes | The name of the entity where the relation ends | |
| relationType | Yes | The type of the relation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. However, it only states 'get version history', omitting traits like read-only nature, authorization requirements, or whether history includes changes to properties or just the relation's existence. Minimal behavioral context provided.
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?
Single sentence, no redundancy or filler. Front-loaded with the core action and resource. Every word serves a purpose.
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?
No output schema exists, so the description should explain what is returned (e.g., list of versions, timestamps, field changes). It does not, leaving the agent uncertain about the response format. Also lacks details on ordering, pagination, or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each parameter (from, to, relationType) has a clear description. The description does not add meaning beyond the schema, meeting the baseline expectation. No additional parameter details like format or constraints are offered.
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 action: 'Get the version history of a relation'. It specifies the verb (get), resource (relation), and scope (version history), distinguishing it from sibling tools like 'get_relation' (current state) and 'get_entity_history' (entity version history).
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 on when to use this tool versus alternatives (e.g., 'get_relation' for current state, 'get_graph_at_time' for historical snapshots). No prerequisites or context provided, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open specific nodes in your Memento MCP knowledge graph memory by their names
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | An array of entity names to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. The description only states it 'opens' nodes, but does not clarify whether the operation is read-only, what side effects exist, or what happens if a node is not found. This is insufficient for safe tool invocation.
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, concise sentence with no filler. It is front-loaded with the action. However, it is borderline too terse, missing important details that could be included without significant length.
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?
The tool has no output schema and no annotations, yet the description does not explain what the tool returns (e.g., full node data, status messages). Given the complexity of the knowledge graph context and many sibling tools, this lack of completeness hinders effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents the parameter 'names' as an array of strings. The description adds minimal extra meaning ('by their names') that aligns with the schema. No additional details like name format, case sensitivity, or behavior for missing names are provided, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('nodes'), and adds the qualifier 'by their names', which clarifies the tool's action. However, it does not explicitly differentiate this from other retrieval tools like 'read_graph' or 'search_nodes', leaving some ambiguity.
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 (e.g., search_nodes, read_graph). There are no exclusions or context hints, forcing the agent to infer usage from the description 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 Memento MCP knowledge graph memory system
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | No | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes a read operation (non-destructive) but omits details about size constraints, timeouts, or permissions. Adequate but minimal.
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?
Single sentence with no redundancy. All words are necessary and front-loaded.
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?
No output schema, no annotations. Reading the entire graph could be heavy; description lacks warnings or suggestions for partial reads via sibling tools. Incomplete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one dummy parameter explained. Description adds no new meaning beyond schema; baseline 3 applies as schema suffices.
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?
Clearly states the verb 'Read' and the resource 'entire Memento MCP knowledge graph memory system'. It distinguishes from siblings like 'get_graph_at_time' or 'get_decayed_graph' which offer subsets.
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?
Implies usage for retrieving the full graph, but no explicit guidance on when to use versus alternatives like 'search_nodes' or 'semantic_search'. No when-not-to-use or prerequisite info.
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 your Memento MCP knowledge graph memory based on a query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to match against entity names, types, and observation content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'based on a query' but omits return format, pagination, or read-only nature, 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 one concise sentence, front-loaded with the action and resource, containing no superfluous 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?
For a simple tool with one parameter and no output schema, the description is adequate but lacks information on what the search returns or how it differs from similar tools like semantic_search.
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 covers 100% of parameters, and the description adds value by specifying that the query matches 'entity names, types, and observation content', which clarifies the parameter's usage.
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 resource 'Memento MCP knowledge graph memory', but does not differentiate from sibling tools like semantic_search.
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 vs alternatives (e.g., semantic_search). The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for entities semantically using vector embeddings and similarity in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The text query to search for semantically | |
| limit | No | Maximum number of results to return (default: 10) | |
| min_similarity | No | Minimum similarity threshold from 0.0 to 1.0 (default: 0.6) | |
| entity_types | No | Filter results by entity types | |
| hybrid_search | No | Whether to combine keyword and semantic search (default: true) | |
| semantic_weight | No | Weight of semantic results in hybrid search from 0.0 to 1.0 (default: 0.6) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not mention return format, result interpretation, performance implications, or safety traits. Only states the action without side-effect details.
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?
Single sentence that efficiently communicates the tool's purpose with no redundancy. All words contribute to clarity.
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?
Despite having 6 parameters, no output schema, and no annotations, the description provides only a high-level overview. Missing details on return values, pagination, and specific behaviors for parameters like hybrid_search or entity_types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented in the schema. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
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 searches for entities semantically using vector embeddings and similarity, specifying the resource (Memento MCP knowledge graph memory) and methodology. It distinguishes from sibling tools like search_nodes which likely use keyword search.
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 on when to use this tool versus alternatives (e.g., search_nodes, open_nodes). Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing relation with enhanced properties in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| relation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates mutation but does not mention idempotency, error cases (e.g., relation not found), or side effects. The description is too brief to provide transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a complex nested parameter structure and no output schema, the description omits return values, error handling, and behavioral specifics. It does not fully enable an agent to use the 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?
The description text does not describe any parameters; all parameter meaning comes from the schema itself. Since schema description coverage is 0% from the description's perspective, it fails to add value beyond the structured 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 verb 'Update', the resource 'existing relation', and the context 'in your Memento MCP knowledge graph memory'. It distinguishes from siblings like create_relations (create vs update) and delete_relations.
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 explicit guidance on when to use this tool vs alternatives (e.g., when to update vs create, or prerequisites like relation existence). Usage is implied but not stated.
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. Dates show when Glama detected each change.
add_observationscreate_entitiescreate_relationsdelete_entitiesdelete_observationsdelete_relationsget_decayed_graphget_entity_embeddingget_entity_historyget_graph_at_timeget_relationget_relation_historyopen_nodesread_graphsearch_nodessemantic_searchupdate_relationEach tool has a clearly distinct purpose: CRUD operations for entities, relations, and observations are separated, and specialized tools for history, embeddings, and time-specific queries do not overlap. No ambiguity between tool functions.
All tool names follow a consistent verb_noun pattern (e.g., create_entities, delete_observations, get_entity_history). The naming is uniform and predictable, aiding agent selection.
With 17 tools, the count is slightly above the ideal 3-15 range but still well-scoped for a knowledge graph system. Each tool addresses a specific need, though a few could potentially be consolidated.
The tool surface covers most CRUD operations but lacks an update_entity tool and a dedicated get_entity (though open_nodes and read_graph partially fill this). Missing update for observations. These gaps may cause some workflow interruptions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Persistent AI memory with semantic search, conflict detection, and ticketing.
Memory system for AI agents with semantic search. Store and recall memories with ease.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gannonh/memento-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
