Sistema de memoria de grafos de conocimiento escalable y de alto rendimiento con recuperación semántica, recuerdo contextual y reconocimiento temporal. Proporciona a cualquier cliente LLM compatible con el protocolo de contexto de modelo (p. ej., Claude Desktop, Cursor, Github Copilot) una memoria ontológica a largo plazo resiliente, adaptativa y persistente.
Las entidades son los nodos principales del grafo de conocimiento. Cada entidad tiene:
Un nombre único (identificador)
Un tipo de entidad (por ejemplo, "persona", "organización", "evento")
Una lista de observaciones
Incrustaciones vectoriales (para búsqueda semántica)
Historial completo de versiones
Ejemplo:
{
"name": "John_Smith",
"entityType": "person",
"observations": ["Speaks fluent Spanish"]
}Las relaciones definen conexiones dirigidas entre entidades con propiedades mejoradas:
Indicadores de fuerza (0,0-1,0)
Niveles de confianza (0,0-1,0)
Metadatos enriquecidos (fuente, marcas de tiempo, etiquetas)
Conciencia temporal con historial de versiones
Decadencia de la confianza basada en el tiempo
Ejemplo:
{
"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 utiliza Neo4j como su backend de almacenamiento, proporcionando una solución unificada tanto para el almacenamiento de gráficos como para las capacidades de búsqueda de vectores.
Almacenamiento unificado : consolida el almacenamiento de gráficos y vectores en una única base de datos
Operaciones gráficas nativas : diseñadas específicamente para recorridos y consultas de gráficos
Búsqueda de vectores integrada : búsqueda de similitud de vectores para incrustaciones integradas directamente en Neo4j
Escalabilidad : mejor rendimiento con grandes gráficos de conocimiento
Arquitectura simplificada : diseño limpio con una única base de datos para todas las operaciones
Neo4j 5.13+ (necesario para las capacidades de búsqueda vectorial)
La forma más fácil de comenzar a utilizar Neo4j es utilizar Neo4j Desktop :
Descargue e instale Neo4j Desktop desde https://neo4j.com/download/
Crear un nuevo proyecto
Agregar una nueva base de datos
Establezca la contraseña en memento_password (o su contraseña preferida)
Iniciar la base de datos
La base de datos Neo4j estará disponible en:
URI de Bolt : bolt://127.0.0.1:7687 (para conexiones de controlador)
HTTP : http://127.0.0.1:7474 (para la interfaz de usuario del navegador Neo4j)
Credenciales predeterminadas : nombre de usuario: neo4j , contraseña: memento_password (o la que haya configurado)
Alternativamente, puedes usar Docker Compose para ejecutar Neo4j:
# Start Neo4j container
docker-compose up -d neo4j
# Stop Neo4j container
docker-compose stop neo4j
# Remove Neo4j container (preserves data)
docker-compose rm neo4jAl utilizar Docker, la base de datos Neo4j estará disponible en:
URI de Bolt : bolt://127.0.0.1:7687 (para conexiones de controlador)
HTTP : http://127.0.0.1:7474 (para la interfaz de usuario del navegador Neo4j)
Credenciales predeterminadas : nombre de usuario: neo4j , contraseña: memento_password
Los datos de Neo4j persisten después de reiniciar el contenedor e incluso de actualizar la versión debido a la configuración del volumen de Docker en el archivo docker-compose.yml :
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/importEstas asignaciones garantizan que:
El directorio /data (contiene todos los archivos de base de datos) persiste en su host en ./neo4j-data
El directorio /logs persiste en su host en ./neo4j-logs
El directorio /import (para importar archivos de datos) persiste en ./neo4j-import
Puede modificar estas rutas en su archivo docker-compose.yml para almacenar datos en diferentes ubicaciones si es necesario.
Puedes cambiar ediciones y versiones de Neo4j sin perder datos:
Actualice la versión de la imagen de Neo4j en docker-compose.yml
Reinicie el contenedor con docker-compose down && docker-compose up -d neo4j
Reinicialice el esquema con npm run neo4j:init
Los datos persistirán durante este proceso mientras las asignaciones de volumen sigan siendo las mismas.
Si necesita restablecer completamente su base de datos Neo4j:
# 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:initPara hacer una copia de seguridad de sus datos de Neo4j, simplemente puede copiar el directorio de datos:
# Make a backup of the Neo4j data
cp -r ./neo4j-data ./neo4j-data-backup-$(date +%Y%m%d)Memento MCP incluye utilidades de línea de comandos para administrar operaciones de Neo4j:
Pruebe la conexión a su base de datos Neo4j:
# 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 neo4jPara un funcionamiento normal, la inicialización del esquema de Neo4j se realiza automáticamente cuando Memento MCP se conecta a la base de datos. No es necesario ejecutar ningún comando manual para su uso habitual.
Los siguientes comandos solo son necesarios para escenarios de desarrollo, pruebas o personalización avanzada:
# 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 --recreateEncuentre entidades semánticamente relacionadas basándose en el significado en lugar de solo palabras clave:
Incrustaciones vectoriales : las entidades se codifican automáticamente en un espacio vectorial de alta dimensión utilizando los modelos de incrustación de OpenAI
Similitud de coseno : encuentre conceptos relacionados incluso cuando utilicen terminología diferente
Umbrales configurables : establezca puntuaciones mínimas de similitud para controlar la relevancia de los resultados
Búsqueda intermodal : consulta con texto para encontrar entidades relevantes independientemente de cómo se describieron
Compatibilidad con múltiples modelos : compatible con múltiples modelos de incrustación (OpenAI text-embedding-3-small/large)
Recuperación contextual : recupere información basándose en el significado semántico en lugar de coincidencias exactas de palabras clave
Valores predeterminados optimizados : parámetros ajustados para lograr un equilibrio entre precisión y recuperación (umbral de similitud de 0,6, búsqueda híbrida habilitada)
Búsqueda híbrida : combina búsqueda semántica y por palabras clave para obtener resultados más completos.
Búsqueda adaptativa : el sistema elige de forma inteligente entre búsqueda de solo vectores, solo palabras clave o híbrida según las características de la consulta y los datos disponibles.
Optimización del rendimiento : prioriza la búsqueda de vectores para la comprensión semántica mientras mantiene mecanismos de respaldo para la resiliencia.
Procesamiento consciente de consultas : ajusta la estrategia de búsqueda en función de la complejidad de la consulta y las incrustaciones de entidades disponibles
Realice un seguimiento del historial completo de entidades y relaciones con la recuperación de gráficos de puntos en el tiempo:
Historial de versiones completo : cada cambio en una entidad o relación se conserva con marcas de tiempo
Consultas de punto en el tiempo : recupera el estado exacto del gráfico de conocimiento en cualquier momento del pasado
Seguimiento de cambios : registra automáticamente las marcas de tiempo createdAt, updatedAt, validFrom y validTo
Coherencia temporal : mantener una visión históricamente precisa de cómo evolucionó el conocimiento
Actualizaciones no destructivas : las actualizaciones crean nuevas versiones en lugar de sobrescribir los datos existentes
Filtrado basado en el tiempo : filtra elementos del gráfico según criterios temporales
Exploración de la historia : investigar cómo cambió información específica a lo largo del tiempo
Las relaciones pierden confianza automáticamente con el tiempo según una vida media configurable:
Decadencia basada en el tiempo : la confianza en las relaciones disminuye naturalmente con el tiempo si no se refuerza.
Vida media configurable : define con qué rapidez la información se vuelve menos segura (valor predeterminado: 30 días)
Pisos de confianza mínimos : establezca umbrales para evitar el deterioro excesivo de información importante
Metadatos de desintegración : cada relación incluye información detallada del cálculo de desintegración
No destructivo : los valores de confianza originales se conservan junto con los valores decaídos
Aprendizaje por refuerzo : Las relaciones recuperan la confianza cuando se refuerzan con nuevas observaciones
Flexibilidad de tiempo de referencia : calcule la descomposición basándose en tiempos de referencia arbitrarios para el análisis histórico
Compatibilidad completa con metadatos tanto para entidades como para relaciones con campos personalizados:
Seguimiento de fuentes : registre dónde se originó la información (entrada del usuario, análisis, fuentes externas)
Niveles de confianza : Asigne puntuaciones de confianza (0,0-1,0) a las relaciones en función de la certeza.
Fuerza de la relación : Indica la importancia o fuerza de las relaciones (0,0-1,0)
Metadatos temporales : rastrea cuándo se agregó, modificó o verificó la información
Etiquetas personalizadas : agregue etiquetas arbitrarias para clasificación y filtrado
Datos estructurados : almacene datos estructurados complejos dentro de campos de metadatos
Soporte de consultas : búsqueda y filtrado según las propiedades de metadatos
Esquema extensible : agregue campos personalizados según sea necesario sin modificar el modelo de datos principal
Las siguientes herramientas están disponibles para los hosts de clientes LLM a través del Protocolo de contexto de modelo:
crear_entidades
Crear múltiples entidades nuevas en el gráfico de conocimiento
Entrada: entities (matriz de objetos)
Cada objeto contiene:
name (cadena): identificador de entidad
entityType (cadena): clasificación de tipos
observations (string[]): Observaciones asociadas
añadir_observaciones
Agregar nuevas observaciones a entidades existentes
Entrada: observations (matriz de objetos)
Cada objeto contiene:
entityName (cadena): entidad de destino
contents (string[]): Nuevas observaciones para agregar
eliminar_entidades
Eliminar entidades y sus relaciones
Entrada: entityNames (cadena[])
eliminar_observaciones
Eliminar observaciones específicas de las entidades
Entrada: deletions (matriz de objetos)
Cada objeto contiene:
entityName (cadena): entidad de destino
observations (string[]): Observaciones para eliminar
crear_relaciones
Crear múltiples relaciones nuevas entre entidades con propiedades mejoradas
Entrada: relations (matriz de objetos)
Cada objeto contiene:
from (string): Nombre de la entidad de origen
to (cadena): nombre de la entidad de destino
relationType (cadena): tipo de relación
strength (número, opcional): Fuerza de la relación (0,0-1,0)
confidence (número, opcional): Nivel de confianza (0,0-1,0)
metadata (objeto, opcional): campos de metadatos personalizados
obtener_relación
Obtenga una relación específica con sus propiedades mejoradas
Aporte:
from (string): Nombre de la entidad de origen
to (cadena): nombre de la entidad de destino
relationType (cadena): tipo de relación
actualizar_relación
Actualizar una relación existente con propiedades mejoradas
Entrada: relation (objeto):
Contiene:
from (string): Nombre de la entidad de origen
to (cadena): nombre de la entidad de destino
relationType (cadena): tipo de relación
strength (número, opcional): Fuerza de la relación (0,0-1,0)
confidence (número, opcional): Nivel de confianza (0,0-1,0)
metadata (objeto, opcional): campos de metadatos personalizados
eliminar_relaciones
Eliminar relaciones específicas del gráfico
Entrada: relations (matriz de objetos)
Cada objeto contiene:
from (string): Nombre de la entidad de origen
to (cadena): nombre de la entidad de destino
relationType (cadena): tipo de relación
leer_gráfico
Lea el gráfico de conocimiento completo
No se requiere entrada
nodos de búsqueda
Búsqueda de nodos según la consulta
Entrada: query (cadena)
nodos abiertos
Recuperar nodos específicos por nombre
Entrada: names (cadena[])
búsqueda semántica
Búsqueda de entidades semánticamente utilizando incrustaciones vectoriales y similitud
Aporte:
query (cadena): La consulta de texto que se buscará semánticamente
limit (número, opcional): Máximo de resultados a devolver (predeterminado: 10)
min_similarity (número, opcional): umbral mínimo de similitud (0,0-1,0, predeterminado: 0,6)
entity_types (string[], opcional): Filtrar resultados por tipos de entidad
hybrid_search (booleano, opcional): combina búsqueda por palabras clave y semántica (valor predeterminado: verdadero)
semantic_weight (número, opcional): peso de los resultados semánticos en la búsqueda híbrida (0,0-1,0, valor predeterminado: 0,6)
Características:
Selecciona de forma inteligente el método de búsqueda óptimo (vector, palabra clave o híbrido) según el contexto de la consulta.
Maneja con elegancia las consultas sin coincidencias semánticas a través de mecanismos de respaldo
Mantiene un alto rendimiento con decisiones de optimización automáticas
obtener_entidad_incrustada
Obtener la incrustación vectorial para una entidad específica
Aporte:
entity_name (cadena): El nombre de la entidad para la que se obtendrá la incrustación
obtener_historial_de_entidades
Obtener el historial de versiones completo de una entidad
Entrada: entityName (cadena)
obtener_historial_de_relaciones
Obtener el historial de versiones completo de una relación
Aporte:
from (string): Nombre de la entidad de origen
to (cadena): nombre de la entidad de destino
relationType (cadena): tipo de relación
obtener_gráfico_en_tiempo
Obtener el estado del gráfico en una marca de tiempo específica
Entrada: timestamp (número): marca de tiempo de Unix (milisegundos desde la época)
obtener_gráfico_decaído
Obtener un gráfico con valores de confianza decaídos en el tiempo
Entrada: options (objeto, opcional):
reference_time (número): marca de tiempo de referencia para el cálculo de la decadencia (milisegundos desde la época)
decay_factor (número): anulación del factor de decaimiento opcional
Configure Memento MCP con estas variables de entorno:
# 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=trueLas herramientas CLI de Neo4j admiten las siguientes opciones:
--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)Modelos de integración de OpenAI disponibles:
text-embedding-3-small : Eficiente y rentable (1536 dimensiones)
text-embedding-3-large : Mayor precisión, mayor coste (3072 dimensiones)
text-embedding-ada-002 : Modelo heredado (1536 dimensiones)
Para utilizar la búsqueda semántica, deberá configurar las credenciales de la API de OpenAI:
Obtenga una clave API de OpenAI
Configure su entorno con:
# OpenAI API Key for embeddings
OPENAI_API_KEY=your-openai-api-key
# Default embedding model
OPENAI_EMBEDDING_MODEL=text-embedding-3-smallNota : En entornos de prueba, el sistema simulará la generación de incrustaciones si no se proporciona una clave API. Sin embargo, se recomienda usar incrustaciones reales para las pruebas de integración.
Agregue esto a su claude_desktop_config.json :
{
"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"
}
}
}
}Alternativamente, para el desarrollo local, puede utilizar:
{
"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"
}
}
}
}Importante : Siempre especifique explícitamente el modelo de inserción en su configuración de Claude Desktop para garantizar un comportamiento consistente.
Para una integración óptima con Claude, agregue estas declaraciones al aviso de su sistema:
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.Una vez configurado, Claude puede acceder a las capacidades de búsqueda semántica a través del lenguaje natural:
Para crear entidades con incrustaciones semánticas:
User: "Remember that Python is a high-level programming language known for its readability and JavaScript is primarily used for web development."Para buscar semánticamente:
User: "What programming languages do you know about that are good for web development?"Para recuperar información específica:
User: "Tell me everything you know about Python."El poder de este enfoque es que los usuarios pueden interactuar de forma natural, mientras que el LLM maneja la complejidad de seleccionar y utilizar las herramientas de memoria adecuadas.
Las capacidades de búsqueda adaptativa de Memento brindan beneficios prácticos:
Versatilidad de consultas : los usuarios no necesitan preocuparse por cómo formular las preguntas: el sistema se adapta automáticamente a diferentes tipos de consultas.
Resiliencia ante fallos : incluso cuando no hay coincidencias semánticas disponibles, el sistema puede recurrir a métodos alternativos sin intervención del usuario.
Eficiencia de rendimiento : al seleccionar de forma inteligente el método de búsqueda óptimo, el sistema equilibra el rendimiento y la relevancia para cada consulta.
Recuperación de contexto mejorada : las conversaciones LLM se benefician de una mejor recuperación de contexto, ya que el sistema puede encontrar información relevante en gráficos de conocimiento complejos.
Por ejemplo, cuando un usuario pregunta "¿Qué sabes sobre aprendizaje automático?", el sistema puede recuperar entidades conceptualmente relacionadas, incluso si no mencionan explícitamente el "aprendizaje automático", como por ejemplo entidades sobre redes neuronales, ciencia de datos o algoritmos específicos. Sin embargo, si la búsqueda semántica no arroja suficientes resultados, el sistema ajusta automáticamente su enfoque para garantizar que se devuelva información útil.
Memento MCP incluye capacidades de diagnóstico integradas para ayudar a solucionar problemas de búsqueda de vectores:
Verificación de incrustación : el sistema verifica si las entidades tienen incrustaciones válidas y las genera automáticamente si faltan.
Estado del índice del vector : verifica que el índice del vector exista y esté en estado EN LÍNEA
Búsqueda de respaldo : si la búsqueda vectorial falla, el sistema recurre a la búsqueda basada en texto.
Registro detallado : registro completo de operaciones de búsqueda de vectores para la resolución de problemas
Cuando se habilita el modo de depuración, aparecen herramientas de diagnóstico adicionales:
diagnosis_vector_search : información sobre el índice de vectores de Neo4j, los recuentos de incrustaciones y la funcionalidad de búsqueda
force_generate_embedding : Fuerza la generación de una incrustación para una entidad específica
debug_embedding_config : información sobre la configuración actual del servicio de incrustación
Para restablecer completamente su base de datos Neo4j durante el desarrollo:
# 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:coveragePara instalar memento-mcp para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @gannonh/memento-mcp --client claudePuedes ejecutar Memento MCP directamente usando npx sin instalarlo globalmente:
npx -y @gannonh/memento-mcpEste método se recomienda para utilizar con Claude Desktop y otros clientes compatibles con MCP.
Para desarrollar o contribuir al proyecto:
# Install locally
npm install @gannonh/memento-mcp
# Or clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
npm installInstituto Tecnológico de Massachusetts (MIT)
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
