可扩展、高性能的知识图谱记忆系统，具有语义检索、上下文回忆和时间感知功能。为任何支持模型上下文协议的 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 ：
从https://neo4j.com/download/下载并安装 Neo4j Desktop
创建新项目
添加新数据库
将密码设置为memento_password （或您喜欢的密码）
启动数据库
Neo4j 数据库可在以下位置获取：
Bolt URI ： bolt://127.0.0.1:7687 （用于驱动程序连接）
HTTP ： http://127.0.0.1:7474 7474（用于 Neo4j 浏览器 UI）
默认凭证：用户名： 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 数据库将在以下位置可用：
Bolt URI ： bolt://127.0.0.1:7687 （用于驱动程序连接）
HTTP ： http://127.0.0.1:7474 7474（用于 Neo4j 浏览器 UI）
默认凭据：用户名： neo4j ，密码： memento_password
由于docker-compose.yml文件中的 Docker 卷配置，Neo4j 数据在容器重启甚至版本升级后依然有效：
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/import这些映射确保：
/data目录（包含所有数据库文件）在您的主机上保留在./neo4j-data
/logs目录在您的主机上保留在./neo4j-logs
/import目录（用于导入数据文件）保留在./neo4j-import
如果需要，您可以在docker-compose.yml文件中修改这些路径以将数据存储在不同的位置。
您可以更改 Neo4j 版本而不会丢失数据：
在docker-compose.yml中更新 Neo4j 镜像版本
使用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在正常运行情况下，当 Memento MCP 连接到数据库时，Neo4j 模式初始化会自动进行。您无需在常规使用中运行任何手动命令。
以下命令仅对于开发、测试或高级定制场景才是必需的：
# 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 （字符串）：源实体名称
to （字符串）：目标实体名称
relationType （字符串）：关系类型
strength （数字，可选）：关系强度（0.0-1.0）
confidence （数字，可选）：置信度（0.0-1.0）
metadata （对象，可选）：自定义元数据字段
获取关系
获取具有增强属性的特定关系
输入：
from （字符串）：源实体名称
to （字符串）：目标实体名称
relationType （字符串）：关系类型
更新关系
使用增强属性更新现有关系
输入： relation （对象）：
包含：
from （字符串）：源实体名称
to （字符串）：目标实体名称
relationType （字符串）：关系类型
strength （数字，可选）：关系强度（0.0-1.0）
confidence （数字，可选）：置信度（0.0-1.0）
metadata （对象，可选）：自定义元数据字段
删除关系
从图中删除特定关系
输入： relations （对象数组）
每个对象包含：
from （字符串）：源实体名称
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 （字符串）：要获取嵌入的实体的名称
获取实体历史记录
获取实体的完整版本历史记录
输入： entityName （字符串）
获取关系历史记录
获取关系的完整版本历史记录
输入：
from （字符串）：源实体名称
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=trueNeo4j 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 维）
要使用语义搜索，您需要配置 OpenAI API 凭据：
从OpenAI获取 API 密钥
使用以下配置来配置您的环境：
# 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 配置中明确指定嵌入模型，以确保一致的行为。
为了与 Claude 进行最佳集成，请将这些语句添加到系统提示符中：
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.配置完成后，Claude 可以通过自然语言访问语义搜索功能：
要创建具有语义嵌入的实体：
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 状态
回退搜索：如果向量搜索失败，系统将返回基于文本的搜索
详细日志记录：全面记录矢量搜索操作，以便排除故障
启用调试模式后，可以使用其他诊断工具：
诊断_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通过Smithery自动为 Claude Desktop 安装 memento-mcp：
npx -y @smithery/cli install @gannonh/memento-mcp --client claude您可以使用 npx 直接运行 Memento MCP，而无需全局安装：
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
