Масштабируемая, высокопроизводительная система памяти графа знаний с семантическим поиском, контекстным вызовом и временной осведомленностью. Предоставляет любому клиенту LLM, который поддерживает протокол контекста модели (например, Claude Desktop, Cursor, Github Copilot), устойчивую, адаптивную и постоянную долгосрочную онтологическую память.
Сущности являются основными узлами в графе знаний. Каждая сущность имеет:
Уникальное имя (идентификатор)
Тип сущности (например, «лицо», «организация», «событие»)
Список наблюдений
Векторные вложения (для семантического поиска)
Полная история версий
Пример:
{
"name": "John_Smith",
"entityType": "person",
"observations": ["Speaks fluent Spanish"]
}Отношения определяют направленные связи между сущностями с расширенными свойствами:
Показатели силы (0,0-1,0)
Уровни достоверности (0,0-1,0)
Богатые метаданные (источник, временные метки, теги)
Временная осведомленность с историей версий
Снижение уверенности с течением времени
Пример:
{
"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 использует Neo4j в качестве внутреннего хранилища, предоставляя единое решение как для хранения графов, так и для векторного поиска.
Унифицированное хранилище : объединяет графическое и векторное хранилище в единую базу данных.
Собственные графовые операции : созданы специально для обхода графа и запросов.
Интегрированный поиск векторов : поиск векторного сходства для вложений, встроенный непосредственно в Neo4j
Масштабируемость : более высокая производительность с большими графами знаний
Упрощенная архитектура : чистый дизайн с единой базой данных для всех операций
Neo4j 5.13+ (требуется для возможностей векторного поиска)
Самый простой способ начать работу с Neo4j — использовать Neo4j Desktop :
Загрузите и установите Neo4j Desktop с https://neo4j.com/download/
Создать новый проект
Добавить новую базу данных
Установите пароль memento_password (или другой пароль по вашему выбору)
Запустить базу данных
База данных Neo4j будет доступна по адресу:
URI Bolt : bolt://127.0.0.1:7687 (для подключений драйверов)
HTTP : http://127.0.0.1:7474 (для пользовательского интерфейса браузера Neo4j)
Учетные данные по умолчанию : имя пользователя: neo4j , пароль: memento_password (или любой другой, который вы настроили)
В качестве альтернативы вы можете использовать Docker Compose для запуска Neo4j:
# Start Neo4j container
docker-compose up -d neo4j
# Stop Neo4j container
docker-compose stop neo4j
# Remove Neo4j container (preserves data)
docker-compose rm neo4jПри использовании Docker база данных Neo4j будет доступна по адресу:
URI Bolt : bolt://127.0.0.1:7687 (для подключений драйверов)
HTTP : http://127.0.0.1:7474 (для пользовательского интерфейса браузера Neo4j)
Учетные данные по умолчанию : имя пользователя: neo4j , пароль: memento_password
Данные Neo4j сохраняются при перезапуске контейнера и даже при обновлении версии благодаря конфигурации тома Docker в файле docker-compose.yml :
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/importЭти сопоставления гарантируют, что:
Каталог /data (содержит все файлы базы данных) сохраняется на вашем хосте по адресу ./neo4j-data
Каталог /logs сохраняется на вашем хосте по адресу ./neo4j-logs
Каталог /import (для импорта файлов данных) сохраняется в ./neo4j-import
При необходимости вы можете изменить эти пути в файле docker-compose.yml чтобы хранить данные в разных местах.
Вы можете менять редакции и версии Neo4j без потери данных:
Обновите версию образа Neo4j в docker-compose.yml
Перезапустите контейнер с помощью docker-compose down && docker-compose up -d neo4j
Повторно инициализируйте схему с помощью npm run neo4j:init
Данные будут сохраняться в ходе этого процесса до тех пор, пока сопоставления объемов остаются прежними.
Если вам необходимо полностью сбросить базу данных 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:initЧтобы создать резервную копию данных Neo4j, вы можете просто скопировать каталог данных:
# Make a backup of the Neo4j data
cp -r ./neo4j-data ./neo4j-data-backup-$(date +%Y%m%d)Memento MCP включает утилиты командной строки для управления операциями Neo4j:
Проверьте подключение к вашей базе данных 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 neo4jДля нормальной работы инициализация схемы Neo4j происходит автоматически, когда Memento MCP подключается к базе данных. Вам не нужно запускать какие-либо ручные команды для обычного использования.
Следующие команды необходимы только для сценариев разработки, тестирования или расширенной настройки:
# 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 --recreateНайдите семантически связанные сущности, основываясь на значении, а не только на ключевых словах:
Векторные вложения : сущности автоматически кодируются в многомерное векторное пространство с использованием моделей встраивания OpenAI.
Косинусное сходство : находите связанные понятия, даже если они используют разную терминологию.
Настраиваемые пороговые значения : установите минимальные оценки сходства для контроля релевантности результатов.
Кросс-модальный поиск : запрос с текстом для поиска соответствующих сущностей независимо от того, как они были описаны.
Поддержка нескольких моделей : совместимость с несколькими моделями встраивания (OpenAI text-embedding-3-small/large)
Контекстный поиск : поиск информации на основе семантического значения, а не точного соответствия ключевым словам.
Оптимизированные параметры по умолчанию : настроенные параметры для баланса между точностью и полнотой (порог сходства 0,6, включен гибридный поиск)
Гибридный поиск : объединяет семантический поиск и поиск по ключевым словам для получения более полных результатов.
Адаптивный поиск : система разумно выбирает между векторным поиском, поиском только по ключевым словам или гибридным поиском на основе характеристик запроса и доступных данных.
Оптимизация производительности : приоритет векторного поиска для семантического понимания при сохранении резервных механизмов для обеспечения устойчивости
Обработка с учетом запросов : настраивает стратегию поиска на основе сложности запроса и доступных внедрений сущностей.
Отслеживайте полную историю сущностей и отношений с помощью поиска графика на определенный момент времени:
Полная история версий : каждое изменение сущности или отношения сохраняется с метками времени.
Запросы на определенный момент времени : получение точного состояния графа знаний в любой момент в прошлом.
Отслеживание изменений : автоматически записывает временные метки createdAt, updatedAt, validFrom и validTo.
Временная последовательность : сохранение исторически точного представления о том, как развивались знания.
Неразрушающие обновления : обновления создают новые версии, а не перезаписывают существующие данные.
Фильтрация по времени : фильтрация элементов графика на основе временных критериев.
Исследование истории : изучение того, как конкретная информация менялась с течением времени.
Отношения автоматически теряют свою достоверность с течением времени на основе настраиваемого периода полураспада:
Снижение со временем : доверие в отношениях естественным образом снижается со временем, если его не укреплять.
Настраиваемый период полураспада : определите, как быстро информация становится менее определенной (по умолчанию: 30 дней)
Минимальные уровни достоверности : установите пороговые значения, чтобы предотвратить чрезмерную потерю важной информации.
Метаданные распада : каждое отношение включает подробную информацию о расчетах распада.
Неразрушающий : исходные значения достоверности сохраняются вместе с измененными значениями
Обучение с подкреплением : отношения обретают уверенность, когда подкрепляются новыми наблюдениями.
Гибкость в отношении времени отсчета : расчет затухания на основе произвольных времен отсчета для исторического анализа.
Богатая поддержка метаданных как для сущностей, так и для отношений с настраиваемыми полями:
Отслеживание источника : запись источника информации (пользовательский ввод, анализ, внешние источники)
Уровни уверенности : присвойте баллы уверенности (0,0–1,0) отношениям на основе уверенности.
Сила отношений : укажите важность или силу отношений (0,0–1,0).
Временные метаданные : отслеживайте, когда информация была добавлена, изменена или проверена.
Пользовательские теги : добавление произвольных тегов для классификации и фильтрации.
Структурированные данные : хранение сложных структурированных данных в полях метаданных.
Поддержка запросов : поиск и фильтрация на основе свойств метаданных
Расширяемая схема : добавляйте пользовательские поля по мере необходимости, не изменяя основную модель данных.
Следующие инструменты доступны хостам клиентов LLM через протокол контекста модели:
создать_сущности
Создайте несколько новых сущностей в графе знаний
Входные данные: entities (массив объектов)
Каждый объект содержит:
name (строка): Идентификатор сущности
entityType (строка): Классификация типов
observations (string[]): Связанные наблюдения
добавить_наблюдения
Добавить новые наблюдения к существующим сущностям
Вход: observations (массив объектов)
Каждый объект содержит:
entityName (строка): Целевая сущность
contents (string[]): Новые наблюдения для добавления
удалить_сущности
Удалить сущности и их связи
Ввод: entityNames (string[])
удалить_наблюдения
Удалить определенные наблюдения из сущностей
Вход: deletions (массив объектов)
Каждый объект содержит:
entityName (строка): Целевая сущность
observations (string[]): Наблюдения для удаления
создать_отношения
Создание нескольких новых отношений между сущностями с улучшенными свойствами
Вход: relations (массив объектов)
Каждый объект содержит:
from (string): Имя исходной сущности
to (строка): Имя целевого объекта
relationType (строка): Тип отношения
strength (число, необязательно): Сила связи (0,0-1,0)
confidence (число, необязательно): Уровень достоверности (0,0-1,0)
metadata (объект, необязательно): пользовательские поля метаданных
получить_отношение
Получите определенное отношение с его улучшенными свойствами
Вход:
from (string): Имя исходной сущности
to (строка): Имя целевого объекта
relationType (строка): Тип отношения
обновление_отношения
Обновить существующее отношение с улучшенными свойствами
Вход: relation (объект):
Содержит:
from (string): Имя исходной сущности
to (строка): Имя целевого объекта
relationType (строка): Тип отношения
strength (число, необязательно): Сила связи (0,0-1,0)
confidence (число, необязательно): Уровень достоверности (0,0-1,0)
metadata (объект, необязательно): пользовательские поля метаданных
удалить_отношения
Удалить определенные отношения из графика
Вход: relations (массив объектов)
Каждый объект содержит:
from (string): Имя исходной сущности
to (строка): Имя целевого объекта
relationType (строка): Тип отношения
читать_граф
Прочитать всю схему знаний
Ввод не требуется
поисковые_узлы
Поиск узлов на основе запроса
Ввод: query (строка)
открытые_узлы
Извлечь определенные узлы по имени
Ввод: names (string[])
семантический_поиск
Семантический поиск сущностей с использованием векторных вложений и сходства
Вход:
query (строка): Текстовый запрос для семантического поиска
limit (число, необязательно): Максимальное количество возвращаемых результатов (по умолчанию: 10)
min_similarity (число, необязательно): минимальный порог сходства (0,0–1,0, по умолчанию: 0,6)
entity_types (string[], необязательно): Фильтрация результатов по типам сущностей
hybrid_search (логическое значение, необязательно): Объединить ключевое слово и семантический поиск (по умолчанию: true)
semantic_weight (число, необязательно): Вес семантических результатов в гибридном поиске (0,0-1,0, по умолчанию: 0,6)
Функции:
Интеллектуальный выбор оптимального метода поиска (векторный, по ключевым словам или гибридный) на основе контекста запроса
Изящно обрабатывает запросы без семантических совпадений с помощью резервных механизмов
Поддерживает высокую производительность благодаря автоматическим решениям по оптимизации
получить_сущность_внедрение
Получить векторное вложение для определенной сущности
Вход:
entity_name (string): Имя сущности, для которой необходимо получить вложение
получить_историю_сущности
Получить полную историю версий объекта
Ввод: entityName (строка)
получить_историю_отношений
Получить полную историю версий отношения
Вход:
from (string): Имя исходной сущности
to (строка): Имя целевого объекта
relationType (строка): Тип отношения
получить_граф_в_время
Получить состояние графика на определенную временную метку
Ввод: timestamp (число): временная метка Unix (миллисекунды с начала эпохи)
получить_распавшийся_график
Получить график с уменьшающимися во времени значениями достоверности
Входные данные: options (объект, необязательно):
reference_time (число): временная метка для расчета распада (миллисекунды с начала эпохи)
decay_factor (число): Необязательное переопределение фактора распада
Настройте Memento MCP с помощью следующих переменных среды:
# 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=trueИнструменты Neo4j CLI поддерживают следующие параметры:
--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)Доступные модели встраивания OpenAI:
text-embedding-3-small : Эффективный, экономичный (1536 измерений)
text-embedding-3-large : Более высокая точность, более высокая стоимость (3072 измерения)
text-embedding-ada-002 : Устаревшая модель (1536 измерений)
Для использования семантического поиска вам необходимо настроить учетные данные API OpenAI:
Получите ключ API от OpenAI
Настройте свою среду с помощью:
# OpenAI API Key for embeddings
OPENAI_API_KEY=your-openai-api-key
# Default embedding model
OPENAI_EMBEDDING_MODEL=text-embedding-3-smallПримечание : Для тестовых сред система будет имитировать генерацию встраивания, если не предоставлен ключ API. Однако для интеграционного тестирования рекомендуется использовать реальные встраивания.
Добавьте это в ваш 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"
}
}
}
}В качестве альтернативы для локального развития вы можете использовать:
{
"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"
}
}
}
}Важно : всегда явно указывайте модель внедрения в конфигурации Claude Desktop, чтобы обеспечить единообразное поведение.
Для оптимальной интеграции с Клодом добавьте следующие операторы в системную строку:
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.После настройки Клод может получить доступ к возможностям семантического поиска через естественный язык:
Чтобы создать сущности с семантическими вложениями:
User: "Remember that Python is a high-level programming language known for its readability and JavaScript is primarily used for web development."Для семантического поиска:
User: "What programming languages do you know about that are good for web development?"Чтобы получить конкретную информацию:
User: "Tell me everything you know about Python."Преимущество этого подхода в том, что пользователи могут взаимодействовать естественным образом, в то время как LLM берет на себя всю сложность выбора и использования соответствующих инструментов запоминания.
Возможности адаптивного поиска Memento обеспечивают практические преимущества:
Универсальность запросов : пользователям не нужно беспокоиться о том, как формулировать вопросы — система автоматически адаптируется к различным типам запросов.
Устойчивость к сбоям : даже если семантические соответствия недоступны, система может вернуться к альтернативным методам без вмешательства пользователя.
Эффективность работы : разумно выбирая оптимальный метод поиска, система обеспечивает баланс производительности и релевантности для каждого запроса.
Улучшенный поиск контекста : беседы LLM выигрывают от лучшего поиска контекста, поскольку система может находить релевантную информацию в сложных графах знаний.
Например, когда пользователь спрашивает: «Что вы знаете о машинном обучении?», система может извлечь концептуально связанные сущности, даже если они явно не упоминают «машинное обучение» — возможно, сущности о нейронных сетях, науке о данных или конкретных алгоритмах. Но если семантический поиск дает недостаточные результаты, система автоматически корректирует свой подход, чтобы гарантировать, что полезная информация все еще возвращается.
Memento MCP включает в себя встроенные диагностические возможности, помогающие устранять неполадки векторного поиска:
Проверка встраивания : система проверяет, имеют ли сущности допустимые встраивания, и автоматически генерирует их, если они отсутствуют.
Статус векторного индекса : проверяет, что векторный индекс существует и находится в состоянии ONLINE.
Резервный поиск : если векторный поиск не удается, система возвращается к текстовому поиску.
Подробное ведение журнала : комплексное ведение журнала операций поиска векторов для устранения неполадок.
При включении режима отладки становятся доступны дополнительные инструменты диагностики:
diagnostic_vector_search : Информация о векторном индексе Neo4j, количестве внедрений и функциональности поиска
force_generate_embedding : принудительно генерирует внедрение для определенной сущности
debug_embedding_config : Информация о текущей конфигурации службы встраивания
Чтобы полностью сбросить базу данных Neo4j во время разработки:
# 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:coverageЧтобы автоматически установить memento-mcp для Claude Desktop через Smithery :
npx -y @smithery/cli install @gannonh/memento-mcp --client claudeВы можете запустить Memento MCP напрямую с помощью npx, не устанавливая его глобально:
npx -y @gannonh/memento-mcpЭтот метод рекомендуется использовать с Claude Desktop и другими MCP-совместимыми клиентами.
Для разработки или участия в проекте:
# Install locally
npm install @gannonh/memento-mcp
# Or clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
npm installМассачусетский технологический институт
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
