使用模型上下文协议 (MCP) 的 Cursor 综合内存系统。
在GitHub上探索完整的自主开发生态系统，其特点包括：
📋 任务管理系统- 通过分步任务引导实施**🔄 自主记忆**- 可记住整个项目的上下文感知 AI📊项目蓝图- 根据您的规范创建的完整技术架构**📁 文件/文件夹架构**- 使用最佳实践优化的项目结构**📘 实施指南**- 所有文件和组件的综合文档**📝 详细任务**- 从项目启动到完成的完整工作流程**🔍 基于向量的搜索**- 跨代码库和对话进行语义搜索**🧩 代码索引**- 自动检测和索引代码结构**🔎 语义代码检索**- 按含义而不是精确匹配查找相关代码**🤖 自动代码分析**- 使用上下文提取函数、类和变量
生成完整的项目蓝图，包括文件架构、实施指南和完整的任务序列以及已实施的整个 Cursor10x 系统！
Cursor10x 记忆系统为人工智能助手（特别是 Claude）创建了一个持久记忆层，使它们能够保留和回忆：
最近的消息和对话历史记录
当前正在处理的活动文件
重要的项目里程碑和决策
技术要求和规范
按时间顺序排列的动作和事件（情节）
代码库中的代码片段和结构
基于向量嵌入的语义相似内容
通过语义相似性来关联代码片段
具有函数和变量关系的文件结构
该记忆系统弥合了无状态人工智能交互和持续开发工作流程之间的差距，从而提供了更高效、更具情境感知的帮助。
Related MCP server: Mnemoverse Memory
记忆系统建立在四个核心组件之上：
MCP 服务器：实现模型上下文协议来注册工具和处理请求
内存数据库：使用 Turso 数据库进行跨会话的持久存储
内存子系统：将内存组织成具有不同用途的专用系统
向量嵌入：将文本和代码转换为用于语义搜索的数字表示
该系统实现了四种互补的内存类型：
短期记忆（STM）
存储最新消息和活动文件
为当前交互提供即时背景
根据新近度和重要性自动确定优先级
长期记忆（LTM）
存储永久项目信息，如里程碑和决策
保持建筑和设计背景
无限期地保存重要信息
情景记忆
按时间顺序记录事件
维持动作之间的因果关系
提供项目历史的时间背景
语义记忆
存储消息、文件和代码片段的向量嵌入
支持基于语义相似性的内容检索
自动索引代码结构以进行上下文检索
跟踪代码组件之间的关系
提供基于相似度的代码库搜索
持久上下文：在多个会话中维护对话和项目上下文
基于重要性的存储：根据可配置的重要性级别对信息进行优先排序
多维记忆：结合短期、长期、情景和语义记忆系统
综合检索：提供来自所有内存子系统的统一上下文
健康监测：包括内置诊断和状态报告
横幅生成：创建用于对话开始的信息上下文横幅
数据库持久性：将所有内存数据存储在 Turso 数据库中，并自动创建模式
向量嵌入：创建文本和代码的数值表示，用于相似性搜索
高级矢量存储：利用 Turso 的 F32_BLOB 和矢量函数实现高效的嵌入存储
ANN 搜索：支持近似最近邻搜索，实现快速相似性匹配
代码索引：自动检测和索引代码结构（函数、类、变量）
语义搜索：根据含义而不是精确的文本匹配来查找相关内容
相关性评分：根据与当前查询的相关性对上下文项进行排名
代码结构检测：识别并提取跨多种语言的代码组件
自动嵌入生成：自动为索引内容创建向量嵌入
交叉引用检索：查找不同文件和组件之间的相关代码
Node.js 18 或更高版本
npm 或 yarn 包管理器
Turso 数据库帐户
配置Turso数据库：
# Install Turso CLI
curl -sSfL https://get.turso.tech/install.sh | bash
# Login to Turso
turso auth login
# Create a database
turso db create cursor10x-mcp
# Get database URL and token
turso db show cursor10x-mcp --url
turso db tokens create cursor10x-mcp或者您可以访问Turso并注册，然后创建数据库并获取相应的凭证。免费计划足以满足您的项目内存需求。
配置光标 MCP：
使用数据库 URL 和 turso 身份验证令牌更新项目目录中的.cursor/mcp.json ：
{
"mcpServers": {
"cursor10x-mcp": {
"command": "npx",
"args": ["cursor10x-mcp"],
"enabled": true,
"env": {
"TURSO_DATABASE_URL": "your-turso-database-url",
"TURSO_AUTH_TOKEN": "your-turso-auth-token"
}
}
}
}mcp_cursor10x_initConversation通过一次性操作存储用户消息、生成横幅并检索上下文来初始化对话。此统一工具无需在每个对话开始时分别调用 generateBanner、getComprehensiveContext 和 storeUserMessage。
参数：
content （字符串，必需）：用户消息的内容
importance （字符串，可选）：重要性级别（“低”，“中”，“高”，“关键”），默认为“低”
metadata （对象，可选）：消息的附加元数据
返回：
具有两个部分的对象：
display ：包含要向用户显示的横幅
internal ：包含代理使用的综合上下文
例子：
// Initialize a conversation
const result = await mcp_cursor10x_initConversation({
content: "I need to implement a login system for my app",
importance: "medium"
});
// Result: {
// "status": "ok",
// "display": {
// "banner": {
// "status": "ok",
// "memory_system": "active",
// "mode": "turso",
// "message_count": 42,
// "active_files_count": 3,
// "last_accessed": "4/15/2023, 2:30:45 PM"
// }
// },
// "internal": {
// "context": { ... comprehensive context data ... },
// "messageStored": true,
// "timestamp": 1681567845123
// }
// }mcp_cursor10x_endConversation通过在一次调用中组合多个操作来结束对话：存储助手的最终消息、记录已完成任务的里程碑，以及在情景记忆中记录一个情节。此统一工具取代了每次对话结束时分别调用 storeAssistantMessage、storeMilestone 和 recordEpisode 的需要。
参数：
content （字符串，必需）：助手的最终消息的内容
milestone_title （字符串，必需）：要记录的里程碑的标题
milestone_description (字符串，必需)：对已完成事项的描述
importance （字符串，可选）：重要性级别（“低”，“中”，“高”，“关键”），默认为“中”
metadata （对象，可选）：所有记录的附加元数据
返回：
具有每个操作的状态和结果的对象
例子：
// End a conversation with finalization steps
const result = await mcp_cursor10x_endConversation({
content: "I've implemented the authentication system with JWT tokens as requested",
milestone_title: "Authentication Implementation",
milestone_description: "Implemented secure JWT-based authentication with refresh tokens",
importance: "high"
});
// Result: {
// "status": "ok",
// "results": {
// "assistantMessage": {
// "stored": true,
// "timestamp": 1681568500123
// },
// "milestone": {
// "title": "Authentication Implementation",
// "stored": true,
// "timestamp": 1681568500123
// },
// "episode": {
// "action": "completion",
// "stored": true,
// "timestamp": 1681568500123
// }
// }
// }mcp_cursor10x_checkHealth检查内存系统及其数据库连接的健康状况。
参数：
无需
返回：
具有健康状态和诊断的对象
例子：
// Check memory system health
const health = await mcp_cursor10x_checkHealth({});
// Result: {
// "status": "ok",
// "mode": "turso",
// "message_count": 42,
// "active_files_count": 3,
// "current_directory": "/users/project",
// "timestamp": "2023-04-15T14:30:45.123Z"
// }mcp_cursor10x_getMemoryStats检索有关内存系统的详细统计信息。
参数：
无需
返回：
具有全面内存统计信息的对象
例子：
// Get memory statistics
const stats = await mcp_cursor10x_getMemoryStats({});
// Result: {
// "status": "ok",
// "stats": {
// "message_count": 42,
// "active_file_count": 3,
// "milestone_count": 7,
// "decision_count": 12,
// "requirement_count": 15,
// "episode_count": 87,
// "oldest_memory": "2023-03-10T09:15:30.284Z",
// "newest_memory": "2023-04-15T14:30:45.123Z"
// }
// }mcp_cursor10x_getComprehensiveContext从所有记忆子系统中检索统一的上下文，结合短期、长期和情景记忆。
参数：
无需
返回：
来自所有记忆系统的具有合并上下文的对象
例子：
// Get comprehensive context
const context = await mcp_cursor10x_getComprehensiveContext({});
// Result: {
// "status": "ok",
// "context": {
// "shortTerm": {
// "recentMessages": [...],
// "activeFiles": [...]
// },
// "longTerm": {
// "milestones": [...],
// "decisions": [...],
// "requirements": [...]
// },
// "episodic": {
// "recentEpisodes": [...]
// },
// "system": {
// "healthy": true,
// "timestamp": "2023-04-15T14:30:45.123Z"
// }
// }
// }mcp_cursor10x_storeUserMessage将用户消息存储在短期记忆系统中。
参数：
content （字符串，必需）：消息的内容
importance （字符串，可选）：重要性级别（“低”，“中”，“高”，“关键”），默认为“低”
metadata （对象，可选）：消息的附加元数据
返回：
具有状态和时间戳的对象
例子：
// Store a user message
const result = await mcp_cursor10x_storeUserMessage({
content: "We need to implement authentication for our API",
importance: "high",
metadata: {
topic: "authentication",
priority: 1
}
});
// Result: {
// "status": "ok",
// "timestamp": 1681567845123
// }mcp_cursor10x_storeAssistantMessage将辅助信息存储在短期记忆系统中。
参数：
content （字符串，必需）：消息的内容
importance （字符串，可选）：重要性级别（“低”，“中”，“高”，“关键”），默认为“低”
metadata （对象，可选）：消息的附加元数据
返回：
具有状态和时间戳的对象
例子：
// Store an assistant message
const result = await mcp_cursor10x_storeAssistantMessage({
content: "I recommend implementing JWT authentication with refresh tokens",
importance: "medium",
metadata: {
topic: "authentication",
contains_recommendation: true
}
});
// Result: {
// "status": "ok",
// "timestamp": 1681567870456
// }mcp_cursor10x_trackActiveFile跟踪用户正在访问或修改的活动文件。
参数：
filename （字符串，必需）：被跟踪的文件的路径
action （字符串，必需）：对文件执行的操作（打开、编辑、关闭等）
metadata （对象，可选）：跟踪事件的附加元数据
返回：
具有状态、文件名、操作和时间戳的对象
例子：
// Track an active file
const result = await mcp_cursor10x_trackActiveFile({
filename: "src/auth/jwt.js",
action: "edit",
metadata: {
changes: "Added refresh token functionality"
}
});
// Result: {
// "status": "ok",
// "filename": "src/auth/jwt.js",
// "action": "edit",
// "timestamp": 1681567900789
// }mcp_cursor10x_getRecentMessages从短期记忆中检索最新消息。
参数：
limit （数字，可选）：要检索的最大消息数，默认为 10
importance （字符串，可选）：按重要性级别过滤
返回：
具有状态和消息数组的对象
例子：
// Get recent high importance messages
const messages = await mcp_cursor10x_getRecentMessages({
limit: 5,
importance: "high"
});
// Result: {
// "status": "ok",
// "messages": [
// {
// "id": 42,
// "role": "user",
// "content": "We need to implement authentication for our API",
// "created_at": "2023-04-15T14:30:45.123Z",
// "importance": "high",
// "metadata": {"topic": "authentication", "priority": 1}
// },
// ...
// ]
// }mcp_cursor10x_getActiveFiles从短期记忆中检索活动文件。
参数：
limit （数字，可选）：要检索的最大文件数，默认为 10
返回：
具有状态和活动文件数组的对象
例子：
// Get recent active files
const files = await mcp_cursor10x_getActiveFiles({
limit: 3
});
// Result: {
// "status": "ok",
// "files": [
// {
// "id": 15,
// "filename": "src/auth/jwt.js",
// "last_accessed": "2023-04-15T14:30:45.123Z",
// "metadata": {"changes": "Added refresh token functionality"}
// },
// ...
// ]
// }mcp_cursor10x_storeMilestone将项目里程碑存储在长期记忆中。
参数：
title （字符串，必需）：里程碑的标题
description （字符串，必需）：里程碑的描述
importance （字符串，可选）：重要性级别，默认为“medium”
metadata （对象，可选）：里程碑的附加元数据
返回：
具有状态、标题和时间戳的对象
例子：
// Store a project milestone
const result = await mcp_cursor10x_storeMilestone({
title: "Authentication System Implementation",
description: "Implemented JWT authentication with refresh tokens and proper error handling",
importance: "high",
metadata: {
version: "1.0.0",
files_affected: ["src/auth/jwt.js", "src/middleware/auth.js"]
}
});
// Result: {
// "status": "ok",
// "title": "Authentication System Implementation",
// "timestamp": 1681568000123
// }mcp_cursor10x_storeDecision将项目决策存储在长期记忆中。
参数：
title （字符串，必需）：决策的标题
content （字符串，必需）：决策的内容
reasoning （字符串，可选）：决策背后的推理
importance （字符串，可选）：重要性级别，默认为“medium”
metadata （对象，可选）：决策的附加元数据
返回：
具有状态、标题和时间戳的对象
例子：
// Store a project decision
const result = await mcp_cursor10x_storeDecision({
title: "JWT for Authentication",
content: "Use JWT tokens for API authentication with refresh token rotation",
reasoning: "JWTs provide stateless authentication with good security and performance characteristics",
importance: "high",
metadata: {
alternatives_considered: ["Session-based auth", "OAuth2"],
decision_date: "2023-04-15"
}
});
// Result: {
// "status": "ok",
// "title": "JWT for Authentication",
// "timestamp": 1681568100456
// }mcp_cursor10x_storeRequirement将项目需求存储在长期记忆中。
参数：
title （字符串，必需）：需求的标题
content （字符串，必需）：需求的内容
importance （字符串，可选）：重要性级别，默认为“medium”
metadata （对象，可选）：需求的附加元数据
返回：
具有状态、标题和时间戳的对象
例子：
// Store a project requirement
const result = await mcp_cursor10x_storeRequirement({
title: "Secure Authentication",
content: "System must implement secure authentication with password hashing, rate limiting, and token rotation",
importance: "critical",
metadata: {
source: "security audit",
compliance: ["OWASP Top 10", "GDPR"]
}
});
// Result: {
// "status": "ok",
// "title": "Secure Authentication",
// "timestamp": 1681568200789
// }mcp_cursor10x_recordEpisode在情景记忆中记录一个情节（动作）。
参数：
actor （字符串，必需）：执行动作的演员（用户、助手、系统）
action （字符串，必需）：执行的操作类型
content （字符串，必需）：操作的内容或详细信息
importance （字符串，可选）：重要性级别，默认为“低”
context （字符串，可选）：该剧集的背景
返回：
具有状态、参与者、动作和时间戳的对象
例子：
// Record an episode
const result = await mcp_cursor10x_recordEpisode({
actor: "assistant",
action: "implementation",
content: "Created JWT authentication middleware with token verification",
importance: "medium",
context: "authentication"
});
// Result: {
// "status": "ok",
// "actor": "assistant",
// "action": "implementation",
// "timestamp": 1681568300123
// }mcp_cursor10x_getRecentEpisodes从情景记忆中检索最近的情景。
参数：
limit （数字，可选）：要检索的最大剧集数量，默认为 10
context （字符串，可选）：按上下文过滤
返回：
具有状态和剧集数组的对象
例子：
// Get recent episodes in the authentication context
const episodes = await mcp_cursor10x_getRecentEpisodes({
limit: 5,
context: "authentication"
});
// Result: {
// "status": "ok",
// "episodes": [
// {
// "id": 87,
// "actor": "assistant",
// "action": "implementation",
// "content": "Created JWT authentication middleware with token verification",
// "timestamp": "2023-04-15T14:45:00.123Z",
// "importance": "medium",
// "context": "authentication"
// },
// ...
// ]
// }mcp_cursor10x_manageVector用于管理向量嵌入的统一工具，具有存储、搜索、更新和删除操作。
参数：
operation （字符串，必需）：要执行的操作（“存储”，“搜索”，“更新”，“删除”）
contentId （数字，可选）：此向量代表的内容的 ID（用于存储、更新、删除）
contentType （字符串，可选）：内容类型（“消息”，“文件”，“片段”等）
vector （数组，可选）：作为数字数组的向量数据（用于存储、更新）或查询向量（用于搜索）
vectorId （数字，可选）：要更新或删除的矢量的ID
limit （数字，可选）：搜索操作的最大结果数，默认为 10
threshold （数字，可选）：搜索操作的相似度阈值，默认为 0.7
metadata （对象，可选）：关于向量的附加信息
返回：
具有状态和操作结果的对象
例子：
// Store a vector embedding
const result = await mcp_cursor10x_manageVector({
operation: "store",
contentId: 42,
contentType: "message",
vector: [0.1, 0.2, 0.3, ...], // 128-dimensional vector
metadata: {
topic: "authentication",
language: "en"
}
});
// Result: {
// "status": "ok",
// "operation": "store",
// "vectorId": 15,
// "timestamp": 1681570000123
// }
// Search for similar vectors
const searchResult = await mcp_cursor10x_manageVector({
operation: "search",
vector: [0.1, 0.2, 0.3, ...], // query vector
contentType: "snippet", // optional filter
limit: 5,
threshold: 0.8
});
// Result: {
// "status": "ok",
// "operation": "search",
// "results": [
// {
// "vectorId": 10,
// "contentId": 30,
// "contentType": "snippet",
// "similarity": 0.92,
// "metadata": { ... }
// },
// ...
// ]
// }内存系统自动创建并维护以下数据库表：
messages ：存储用户和助手消息
id ：唯一标识符
timestamp ：创建时间戳
role ：消息角色（用户/助手）
content ：消息内容
importance ：重要性级别
archived ：邮件是否已存档
active_files ：跟踪文件活动
id ：唯一标识符
filename ：文件路径
action ：最后执行的操作
last_accessed ：上次访问的时间戳
milestones ：记录项目里程碑
id ：唯一标识符
title ：里程碑标题
description ：详细描述
timestamp ：创建时间戳
importance ：重要性级别
decisions ：存储项目决策
id ：唯一标识符
title ：决策标题
content ：决策内容
reasoning ：决策推理
timestamp ：创建时间戳
importance ：重要性级别
requirements ：维护项目要求
id ：唯一标识符
title ：需求标题
content ：需求内容
timestamp ：创建时间戳
importance ：重要性级别
episodes ：记录行动和事件
id ：唯一标识符
timestamp ：创建时间戳
actor ：表演动作的演员
action ：动作类型
content ：动作细节
importance ：重要性级别
context ：动作上下文
vectors ：存储用于语义搜索的向量嵌入
id ：唯一标识符
content_id ：引用内容的 ID
content_type ：内容类型（消息、文件、片段）
vector ：嵌入向量的二进制表示
metadata ：向量的附加元数据
code_files ：跟踪索引的代码文件
id ：唯一标识符
file_path ：文件路径
language ：编程语言
last_indexed ：上次索引的时间戳
metadata ：附加文件元数据
code_snippets ：存储提取的代码结构
id ：唯一标识符
file_id ：对父文件的引用
start_line ：起始行号
end_line ：结束行号
symbol_type ：代码结构的类型（函数、类、变量）
content ：代码片段内容
// Initialize conversation with a single tool call
// This replaces the need for three separate calls at the start of the conversation
const result = await mcp_cursor10x_initConversation({
content: "I need help implementing authentication in my React app",
importance: "high"
});
// Display the banner to the user
console.log("Memory System Status:", result.display.banner);
// Use the context internally (do not show to user)
const context = result.internal.context;
// Use context for more informed assistance// Generate a memory banner at the start
mcp_cursor10x_generateBanner({})
// Get comprehensive context
mcp_cursor10x_getComprehensiveContext({})
// Store the user message
mcp_cursor10x_storeUserMessage({
content: "I need help with authentication",
importance: "high"
})// Track an active file
await mcp_cursor10x_trackActiveFile({
filename: "src/auth/jwt.js",
action: "edit"
});数据库连接问题
验证您的 Turso 数据库 URL 和身份验证令牌是否正确
检查 Turso 服务的网络连接
验证防火墙设置是否允许连接
缺失数据
检查数据是否按适当的重要性级别存储
验证检索查询参数（限制、过滤器）
使用mcp_cursor10x_checkHealth()检查数据库健康状况
性能问题
使用mcp_cursor10x_getMemoryStats()监控内存统计信息
如果数据库变得太大，请考虑归档旧数据
使用更具体的过滤器优化检索
检查系统健康状况：
const health = await mcp_cursor10x_checkHealth({});
console.log("System Health:", health);验证内存统计信息：
const stats = await mcp_cursor10x_getMemoryStats({});
console.log("Memory Stats:", stats);生成状态横幅：
const banner = await mcp_cursor10x_generateBanner({});
console.log("Memory Banner:", banner);在内存中存储项目时，请使用适当的重要性级别：
低：一般信息、日常操作、日常对话
中等：有用的上下文、标准工作项目、常规功能
高：关键决策、主要特征、重要架构元素
关键：核心架构、安全问题、数据完整性问题
麻省理工学院
Checks the health of the memory system and its database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about what 'health' means, what metrics are checked, whether it performs any operations, what the output format might be, or any error conditions. For a diagnostic tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple diagnostic tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and the description provides minimal behavioral context, this is incomplete for a diagnostic tool. The agent knows what to call but not what to expect in return or how the tool behaves. For a health check that could return various status indicators, more context about output format or meaning would be helpful.
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 tool has zero parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it correctly doesn't mention any. The baseline for zero parameters with full schema coverage is 4, as there's no parameter information to add beyond what's already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('checks') and resource ('health of the memory system and its database'). It distinguishes from most siblings like 'getMemoryStats' or 'diagnoseVectors' by focusing on overall system health rather than specific metrics or diagnostics. However, it doesn't explicitly differentiate from all potential health-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to siblings like 'getMemoryStats' or 'diagnoseVectors' that might provide related information. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run diagnostics on the vector storage system to identify issues
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Run diagnostics' implies a read-only analysis operation, it doesn't specify whether this is a lightweight check or intensive scan, what permissions are required, whether it affects system performance, what format the results take, or if it has rate limits. The description is too vague about the actual behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's front-loaded with the main action and target, making it immediately clear what the tool does. Every element of the sentence contributes meaningfully to understanding the tool's function.
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 diagnostic tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of issues are identified, what the diagnostic output looks like, whether it returns structured data or logs, or how results should be interpreted. Given the complexity of vector storage systems and the lack of structured output information, the description leaves too many open questions about what the tool actually produces.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. This meets the baseline expectation for a parameterless tool, though it doesn't add any additional context about why no parameters are needed.
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 ('Run diagnostics') and target ('on the vector storage system'), with the specific goal 'to identify issues'. It distinguishes from generic health checks like 'checkHealth' by focusing specifically on vector storage. However, it doesn't fully differentiate from 'manageVector' which might also involve vector system operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'checkHealth' (general health) or 'manageVector' (vector management). There's no mention of prerequisites, triggers, or scenarios where this diagnostic should be preferred over other tools. The agent must infer usage context 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.
Ends a conversation by storing the assistant message, recording a milestone, and logging an episode in one operation
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the assistant's final message | |
| importance | No | Importance level (low, medium, high) | medium |
| metadata | No | Optional metadata | |
| milestone_description | Yes | Description of what was accomplished | |
| milestone_title | Yes | Title of the milestone to record |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. While it mentions three operations performed, it doesn't describe what 'logging an episode' entails, whether this operation is reversible, what permissions might be required, or how errors are handled. For a tool that appears to perform multiple write operations, this is insufficient 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, efficient sentence that front-loads the main purpose and then lists the three operations performed. Every word earns its place with no redundancy or unnecessary elaboration.
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 tool with 5 parameters (3 required), no annotations, and no output schema, the description provides adequate purpose clarity but lacks sufficient behavioral context. It doesn't explain what happens after the conversation ends, what 'logging an episode' means, or what the tool returns. The combination of multiple operations without behavioral details creates gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Ends a conversation') and lists the three operations performed (storing assistant message, recording milestone, logging episode). It distinguishes this tool from siblings like storeAssistantMessage, storeMilestone, and recordEpisode by combining these functions into one operation.
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 this tool should be used at the conclusion of a conversation to wrap up multiple tasks simultaneously. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context suggests it's for finalizing conversations rather than intermediate steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a banner containing memory system statistics and status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool generates a banner but doesn't disclose behavioral traits such as whether it's read-only or mutative, what format the banner is in, if there are rate limits, or any side effects. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 incomplete. It doesn't explain what the generated banner looks like, its format, or how it differs from raw data provided by sibling tools. For a tool that outputs information, more context on the output is needed.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter information, but that's appropriate here, as there are no parameters to explain.
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 'generates' and the resource 'banner containing memory system statistics and status', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getMemoryStats' or 'getComprehensiveContext', which might provide similar information in different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this banner generation is appropriate compared to other tools that retrieve memory statistics or context, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves active files from the short-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of files to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Retrieves' implying a read operation, but doesn't disclose behavioral traits like permissions needed, rate limits, or what 'active files' entails (e.g., format, freshness). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core purpose without unnecessary elaboration.
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 incomplete. It doesn't explain what 'active files' are, their format, or return values, leaving gaps in understanding for a tool that retrieves data from memory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the 'limit' parameter fully. The description adds no additional meaning beyond what the schema provides, such as context on how 'active files' are determined or filtered, resulting in the baseline score.
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 ('Retrieves') and resource ('active files from the short-term memory'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'trackActiveFile' or 'getRecentEpisodes', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getComprehensiveContext' and 'getRecentMessages', there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves comprehensive context from all memory systems
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional query for semantic search to find relevant context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves context but doesn't clarify whether this is a read-only operation, what permissions might be needed, how results are formatted, or any performance implications (e.g., latency, rate limits). This leaves significant gaps for a tool that presumably accesses multiple systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action, though it could be slightly more specific to improve clarity without sacrificing brevity.
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 incomplete for a tool that retrieves 'comprehensive context.' It doesn't explain what 'comprehensive' means, what systems are involved, the format of returned data, or any limitations, making it inadequate for an agent to understand the full scope and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'query' documented as optional and for semantic search. The description adds no additional meaning beyond this, such as examples of queries or how they influence retrieval. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 states the action ('Retrieves') and target ('comprehensive context from all memory systems'), which is clear but vague. It doesn't specify what 'comprehensive context' entails or how it differs from sibling tools like getRecentEpisodes or getRecentMessages, leaving room for ambiguity about scope and content.
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. With siblings like getRecentEpisodes and getRecentMessages that might retrieve specific subsets of context, the description lacks any indication of appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on 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.
Retrieves statistics about the memory system
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but doesn't specify what statistics are included, format, or any constraints like rate limits or permissions needed. This leaves significant gaps in understanding how the tool behaves.
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, clear sentence that directly states the tool's function without any unnecessary words. It's front-loaded and efficient, making it easy to parse quickly, which is ideal for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what statistics are retrieved or the return format, which could be important for an agent to use the tool effectively. With no annotations and simple schema, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned if any implicit parameters exist (e.g., time range). Since there are no parameters, a baseline of 4 is applied, as the description doesn't need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('statistics about the memory system'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getActiveFiles' or 'getRecentEpisodes', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'checkHealth' or 'diagnoseVectors' that might relate to system monitoring, there's no indication of when 'getMemoryStats' is the appropriate choice, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves recent episodes from the episodic memory
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Filter by context | |
| limit | No | Maximum number of episodes to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data but lacks details on permissions, rate limits, error handling, or what 'recent' means (e.g., time-based vs. count-based). This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and easy to parse, though it could be slightly more informative without sacrificing brevity.
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 no annotations and no output schema, the description is minimal but covers the basic purpose. It lacks details on behavioral traits and output format, which are important for a retrieval tool. However, the schema provides good parameter coverage, making it adequate but with clear gaps in completeness.
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%, with clear parameter documentation in the input schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain 'context' filtering further or 'recent' criteria). Baseline 3 is appropriate as the schema handles parameter semantics adequately.
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 ('Retrieves') and resource ('recent episodes from the episodic memory'), making the tool's purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getRecentMessages' or 'getComprehensiveContext', which might also retrieve memory-related data, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getRecentMessages' and 'getComprehensiveContext' that likely handle similar memory retrieval, the agent has no explicit direction on selection criteria, such as based on recency, context filtering, or data type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves recent messages from the short-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| importance | No | Filter by importance level (low, medium, high) | |
| limit | No | Maximum number of messages to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving from 'short-term memory', which implies a read-only operation, but doesn't specify permissions, rate limits, or what 'recent' means (e.g., time frame). This leaves gaps in understanding the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or output format, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (importance filter and limit). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for adequate coverage without extra value.
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 ('retrieves') and resource ('recent messages from the short-term memory'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools like 'getRecentEpisodes' or 'getComprehensiveContext', which might also retrieve memory-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getRecentEpisodes' or 'getComprehensiveContext', nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initializes a conversation by storing the user message, generating a banner, and retrieving context in one operation
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the user message | |
| importance | No | Importance level (low, medium, high) | low |
| metadata | No | Optional metadata for the message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions behavioral outcomes (storing, generating, retrieving) but lacks critical details: whether this is a write operation (implied by 'storing'), permission requirements, rate limits, or what 'retrieving context' entails. The multi-operation nature suggests complexity that isn't fully disclosed.
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 efficiently conveys the core functionality with zero wasted words. It's front-loaded with the main action ('initializes a conversation') followed by key operations.
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 tool with no annotations, no output schema, and performing multiple operations (store, generate, retrieve), the description is insufficient. It doesn't explain the banner format, what context is retrieved, how results are returned, or error handling. The complexity warrants more disclosure.
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%, so the schema fully documents all 3 parameters. The description adds no parameter-specific information beyond implying 'content' is the user message. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('initializes', 'storing', 'generating', 'retrieving') and identifies the resource ('conversation'). It distinguishes from siblings like 'storeUserMessage' or 'generateBanner' by combining multiple operations, but doesn't explicitly contrast them.
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 like 'storeUserMessage' + 'generateBanner' + 'getComprehensiveContext'. The description implies it's for starting conversations, but lacks context on prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified tool for managing vector embeddings with operations for store, search, update, and delete
| Name | Required | Description | Default |
|---|---|---|---|
| contentId | No | ID of the content this vector represents (for store, update, delete) | |
| contentType | No | Type of content (message, file, snippet, etc.) | |
| limit | No | Maximum number of results for search operation | |
| metadata | No | Additional info about the vector (optional) | |
| operation | Yes | Operation to perform (store, search, update, delete) | |
| threshold | No | Similarity threshold for search operation | |
| vector | No | Vector data as array of numbers (for store, update) or query vector (for search) | |
| vectorId | No | ID of the vector to update or delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it lists operations, it doesn't describe what 'manage' entails - whether operations are atomic, have side effects, require specific permissions, have rate limits, or what happens on failure. For a multi-operation tool with 8 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose. It's appropriately sized for a multi-operation tool, though it could be slightly more structured by separating operation types or adding brief context.
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 complex tool with 8 parameters, multiple operations, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, operation interdependencies, or how this fits within the broader vector management system alongside tools like 'diagnoseVectors'.
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%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions operations but doesn't clarify parameter dependencies or operation-specific requirements. Baseline 3 is appropriate when the schema does the heavy lifting.
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 this is a 'unified tool for managing vector embeddings' with specific operations listed (store, search, update, delete), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'diagnoseVectors' or explain how this differs from other vector-related operations that might exist in the context.
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 mentions the four operations but provides no guidance on when to use this tool versus alternatives like 'diagnoseVectors' or other sibling tools. There's no indication of prerequisites, constraints, or typical use cases for each operation type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records an episode (action) in the episodic memory
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Type of action performed | |
| actor | Yes | Actor performing the action (user, assistant, system) | |
| content | Yes | Content or details of the action | |
| context | No | Context for the episode | |
| importance | No | Importance level (low, medium, high) | low |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Records an episode', implying a write operation, but doesn't cover critical aspects like permissions needed, whether it's idempotent, error handling, or what happens upon success (e.g., confirmation). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Records an episode (action) in the episodic memory'. It's front-loaded with the core action and resource, with no wasted words, though it could be slightly more specific to enhance clarity 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 complexity as a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'episodic memory' entails, how episodes are used, or what the tool returns, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all 5 parameters (action, actor, content, context, importance) with their types and purposes. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 states the tool 'Records an episode (action) in the episodic memory', which provides a clear verb ('Records') and resource ('episode in episodic memory'). However, it doesn't distinguish this tool from its siblings like 'storeUserMessage' or 'storeAssistantMessage', which might also record memory-related actions, making the purpose somewhat vague in context.
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 offers no guidance on when to use this tool versus alternatives. With siblings like 'storeUserMessage', 'storeAssistantMessage', and 'storeDecision' that might handle similar memory storage, there's no indication of specific use cases, prerequisites, or exclusions for 'recordEpisode'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores an assistant message in the short-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the message | |
| importance | No | Importance level (low, medium, high) | low |
| metadata | No | Optional metadata for the message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Stores' data, implying a write operation, but doesn't clarify persistence characteristics (e.g., how long messages are retained, storage limits), whether this requires specific permissions, or what happens on success/failure. For a write operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple storage operation and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (write operation with 3 parameters including nested objects) and no annotations or output schema, the description is minimally adequate but incomplete. It identifies what the tool does but lacks crucial context about behavioral traits, usage scenarios, and return values. The 100% schema coverage helps, but for a write operation with no output schema, more behavioral context would be beneficial.
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%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 ('Stores') and the resource ('an assistant message in the short-term memory'), making the purpose immediately understandable. It distinguishes from siblings like 'storeUserMessage' by specifying 'assistant' message type. However, it doesn't fully differentiate from other storage tools like 'storeDecision' or 'storeMilestone' in terms of what kind of content is appropriate for each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'storeUserMessage', 'storeDecision', or 'storeMilestone'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a project decision in the long-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the decision | |
| importance | No | Importance level (low, medium, high) | medium |
| metadata | No | Optional metadata for the decision | |
| reasoning | No | Reasoning behind the decision | |
| title | Yes | Title of the decision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but lacks details on permissions, idempotency, error handling, or what constitutes a 'project decision'. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'long-term memory' entails, how decisions are retrieved or updated, or the implications of storage. Given the complexity and lack of structured data, more context is needed.
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%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond implying storage of 'project decision' data, which aligns with parameters like 'title' and 'content'. This meets the baseline for high schema coverage.
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 ('Stores') and the resource ('a project decision in the long-term memory'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'storeMilestone' or 'storeRequirement', which appear to be similar storage operations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'storeMilestone' and 'storeRequirement' that might serve similar purposes, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a project milestone in the long-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Description of the milestone | |
| importance | No | Importance level (low, medium, high) | medium |
| metadata | No | Optional metadata for the milestone | |
| title | Yes | Title of the milestone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but doesn't clarify what 'long-term' entails (e.g., durability, retrieval mechanisms), whether it's a write operation with potential side effects, or any error conditions. For a storage tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a storage operation with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after storage (e.g., success/failure indicators, return values, or how to retrieve the milestone later). For a tool that modifies state, more behavioral context is needed to guide the agent 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 input schema has 100% description coverage, with clear documentation for all 4 parameters (title, description, importance, metadata). The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or their impact on storage. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Stores') and resource ('a project milestone in the long-term memory'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'storeAssistantMessage', 'storeDecision', or 'storeRequirement', which also store different types of data in memory, so it doesn't fully distinguish its purpose from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'storeMilestone' over other storage tools like 'storeDecision' or 'storeRequirement', nor does it specify any prerequisites or exclusions for usage. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a project requirement in the long-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the requirement | |
| importance | No | Importance level (low, medium, high) | medium |
| metadata | No | Optional metadata for the requirement | |
| title | Yes | Title of the requirement |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool stores data in 'long-term memory', implying persistence, but doesn't cover critical aspects like whether this requires specific permissions, how data is retrieved or updated, potential rate limits, or error handling. For a storage tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its function, with no wasted content.
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 (storage operation with 4 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what 'long-term memory' entails, how to retrieve stored requirements, or potential side effects, making it inadequate for an agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters (title, content, importance, metadata). The description adds no additional meaning beyond what the schema provides, such as examples or context for parameter use. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Stores') and the resource ('a project requirement in the long-term memory'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'storeAssistantMessage', 'storeUserMessage', 'storeDecision', or 'storeMilestone', which all store different types of data in memory, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for storing requirements, or how it differs from other storage tools like 'storeDecision' or 'storeMilestone', leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a user message in the short-term memory
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Content of the message | |
| importance | No | Importance level (low, medium, high) | low |
| metadata | No | Optional metadata for the message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Stores' implies a write operation, it doesn't specify whether this is persistent, reversible, or has side effects. It mentions 'short-term memory' but doesn't explain retention policies, capacity limits, or how this interacts with other memory tools like 'getRecentMessages'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward storage tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after storage (e.g., confirmation, error handling), how to retrieve stored messages, or integration with related tools. The mention of 'short-term memory' is vague without operational details.
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%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score for high schema coverage.
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 ('Stores') and resource ('a user message in the short-term memory'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'storeAssistantMessage' or 'storeDecision', but the specificity of 'user message' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'storeAssistantMessage' or 'storeDecision', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracks an active file being accessed by the user
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action performed on the file (open, edit, close, etc.) | |
| filename | Yes | Path to the file being tracked | |
| metadata | No | Optional metadata for the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but is minimal. It implies a logging/monitoring function ('tracks') but doesn't disclose behavioral traits such as whether this is a read-only operation, if it stores data persistently, requires specific permissions, or has side effects like updating a database. The description lacks details on what 'tracks' entails beyond the basic action.
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, straightforward sentence that efficiently states the tool's purpose without unnecessary words. It's front-loaded with the core function, though it could be slightly more informative 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 complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how tracking is implemented, or interactions with sibling tools (e.g., 'getActiveFiles' for retrieval). For a tool that likely involves state changes or logging, more context is needed to guide 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 description coverage is 100%, so the schema already documents all parameters (action, filename, metadata) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between parameters or typical use cases, meeting the baseline for high coverage.
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 states the tool 'tracks an active file being accessed by the user', which provides a basic purpose (verb+resource). However, it's vague about what 'tracks' means operationally and doesn't differentiate from sibling tools like 'getActiveFiles' or 'recordEpisode', which may have overlapping functionality with file tracking or logging.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., real-time monitoring vs. logging), or exclusions, leaving the agent to infer usage from the name and parameters alone.
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.
v1.0.0checkHealthdiagnoseVectorsendConversationgenerateBannergetActiveFilesgetComprehensiveContextgetMemoryStatsgetRecentEpisodesgetRecentMessagesinitConversationmanageVectorrecordEpisodestoreAssistantMessagestoreDecisionstoreMilestonestoreRequirementstoreUserMessagetrackActiveFileMost tools have distinct purposes, but there is some overlap between 'storeAssistantMessage'/'storeUserMessage' and 'endConversation'/'initConversation', which bundle similar operations. The 'manageVector' tool is broad but clearly defined, while others like 'getRecentEpisodes' and 'getRecentMessages' target different memory types, reducing confusion.
Naming is mixed with camelCase (e.g., 'checkHealth') and snake_case (e.g., 'store_assistant_message'), though most tools use a verb_noun pattern. Inconsistencies like 'diagnoseVectors' vs. 'manageVector' and variations in verb usage (e.g., 'get', 'store', 'record') detract from a uniform convention.
With 18 tools, the count is slightly high but reasonable for a memory system server covering health, diagnostics, conversation management, and multiple memory types (short-term, episodic, long-term). It avoids being overwhelming by grouping related operations, though some tools could be consolidated.
The tool set comprehensively covers the memory system domain, including initialization, conversation handling, message storage, episode recording, milestone/requirement/decision tracking, vector management, health checks, diagnostics, and context retrieval. There are no obvious gaps, supporting full lifecycle operations for memory management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
AI memory layer — one shared, persistent memory across every AI tool you connect.
Persistent, outcome-grounded episodic memory for Claude. 14ms CPU retrieval, no GPU, no vector DB.
Hosted memory for AI agents that learns from outcomes — one key across Claude, Cursor & ChatGPT.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aiurda/cursor10x-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
