The DevContext (formerly Cursor10x) MCP server provides a persistent memory layer for AI assistants, enabling comprehensive context management across multiple memory types to optimize development workflows.
Maintain context awareness through sophisticated retrieval methods across short-term, long-term, episodic, and semantic memory systems
Store and manage messages with configurable importance levels (low, medium, high, critical)
Track development activities including active files, milestones, decisions, and requirements
Record chronological sequences of actions and events in episodic memory
Perform semantic searches using vector embeddings for code and text
Generate comprehensive context by combining insights from all memory subsystems
Optimize workflows with unified init/end operations that handle multiple memory operations in single calls
Monitor system health and retrieve detailed memory statistics
Generate status banners containing memory system information
Adapt to development patterns through continuous learning from user behavior
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cursor10x MCP recall the project milestones for the authentication module"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🔄 Continuous Context Awareness - Sophisticated retrieval methods focusing on what matters 📊 Structured Metadata - From repository structure down to individual functions 🧠Adaptive Learning - Continuously learns from and adapts to your development patterns 🤖 Completely Autonomous - Self-managing context system that works in the background 📚 External Documentation - Automatically retrieves and integrates relevant documentation 📋 Workflow Integration - Seamless task management workflow built-in
The DevContext Project Generator is launching in the next couple days and will create a COMPLETE set up for your project to literally 10x your development workflow.
DevContext is a cutting-edge Model Context Protocol (MCP) server providing developers with continuous, project-centric context awareness that understands your codebase at a deeper level.
The Cursor10x Memory System creates a persistent memory layer for AI assistants (specifically Claude), enabling them to retain and recall:
Recent messages and conversation history
Active files currently being worked on
Important project milestones and decisions
Technical requirements and specifications
Chronological sequences of actions and events (episodes)
Code snippets and structures from your codebase
Semantically similar content based on vector embeddings
Related code fragments through semantic similarity
File structures with function and variable relationships
This memory system bridges the gap between stateless AI interactions and continuous development workflows, allowing for more productive and contextually aware assistance.
Related MCP server: Mnemoverse Memory
The memory system is built on four core components:
MCP Server: Implements the Model Context Protocol to register tools and process requests
Memory Database: Uses Turso database for persistent storage across sessions
Memory Subsystems: Organizes memory into specialized systems with distinct purposes
Vector Embeddings: Transforms text and code into numerical representations for semantic search
The system implements four complementary memory types:
Short-Term Memory (STM)
Stores recent messages and active files
Provides immediate context for current interactions
Automatically prioritizes by recency and importance
Long-Term Memory (LTM)
Stores permanent project information like milestones and decisions
Maintains architectural and design context
Preserves high-importance information indefinitely
Episodic Memory
Records chronological sequences of events
Maintains causal relationships between actions
Provides temporal context for project history
Semantic Memory
Stores vector embeddings of messages, files, and code snippets
Enables retrieval of content based on semantic similarity
Automatically indexes code structures for contextual retrieval
Tracks relationships between code components
Provides similarity-based search across the codebase
Persistent Context: Maintains conversation and project context across multiple sessions
Importance-Based Storage: Prioritizes information based on configurable importance levels
Multi-Dimensional Memory: Combines short-term, long-term, episodic, and semantic memory systems
Comprehensive Retrieval: Provides unified context from all memory subsystems
Health Monitoring: Includes built-in diagnostics and status reporting
Banner Generation: Creates informative context banners for conversation starts
Database Persistence: Stores all memory data in Turso database with automatic schema creation
Vector Embeddings: Creates numerical representations of text and code for similarity search
Advanced Vector Storage: Utilizes Turso's F32_BLOB and vector functions for efficient embedding storage
ANN Search: Supports Approximate Nearest Neighbor search for fast similarity matching
Code Indexing: Automatically detects and indexes code structures (functions, classes, variables)
Semantic Search: Finds related content based on meaning rather than exact text matches
Relevance Scoring: Ranks context items by relevance to the current query
Code Structure Detection: Identifies and extracts code components across multiple languages
Auto-Embedding Generation: Automatically creates vector embeddings for indexed content
Cross-Reference Retrieval: Finds related code across different files and components
Node.js 18 or higher
npm or yarn package manager
Turso database account
Configure Turso Database:
# 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-mcpOr you can visit Turso and sign up and proceed to create the database and get proper credentials. The free plan will more than cover your project memory.
Configure Cursor MCP:
Update .cursor/mcp.json in your project directory with the database url and turso auth token:
{
"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_initConversationInitializes a conversation by storing the user message, generating a banner, and retrieving context in one operation. This unified tool replaces the need for separate generateBanner, getComprehensiveContext, and storeUserMessage calls at the beginning of each conversation.
Parameters:
content (string, required): Content of the user message
importance (string, optional): Importance level ("low", "medium", "high", "critical"), defaults to "low"
metadata (object, optional): Additional metadata for the message
Returns:
Object with two sections:
display: Contains the banner to be shown to the user
internal: Contains the comprehensive context for the agent's use
Example:
// 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_endConversationEnds a conversation by combining multiple operations in one call: storing the assistant's final message, recording a milestone for what was accomplished, and logging an episode in the episodic memory. This unified tool replaces the need for separate storeAssistantMessage, storeMilestone, and recordEpisode calls at the end of each conversation.
Parameters:
content (string, required): Content of the assistant's final message
milestone_title (string, required): Title of the milestone to record
milestone_description (string, required): Description of what was accomplished
importance (string, optional): Importance level ("low", "medium", "high", "critical"), defaults to "medium"
metadata (object, optional): Additional metadata for all records
Returns:
Object with status and results of each operation
Example:
// 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_checkHealthChecks the health of the memory system and its database connection.
Parameters:
None required
Returns:
Object with health status and diagnostics
Example:
// 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_getMemoryStatsRetrieves detailed statistics about the memory system.
Parameters:
None required
Returns:
Object with comprehensive memory statistics
Example:
// 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_getComprehensiveContextRetrieves a unified context from all memory subsystems, combining short-term, long-term, and episodic memory.
Parameters:
None required
Returns:
Object with consolidated context from all memory systems
Example:
// 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_storeUserMessageStores a user message in the short-term memory system.
Parameters:
content (string, required): Content of the message
importance (string, optional): Importance level ("low", "medium", "high", "critical"), defaults to "low"
metadata (object, optional): Additional metadata for the message
Returns:
Object with status and timestamp
Example:
// 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_storeAssistantMessageStores an assistant message in the short-term memory system.
Parameters:
content (string, required): Content of the message
importance (string, optional): Importance level ("low", "medium", "high", "critical"), defaults to "low"
metadata (object, optional): Additional metadata for the message
Returns:
Object with status and timestamp
Example:
// 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_trackActiveFileTracks an active file being accessed or modified by the user.
Parameters:
filename (string, required): Path to the file being tracked
action (string, required): Action performed on the file (open, edit, close, etc.)
metadata (object, optional): Additional metadata for the tracking event
Returns:
Object with status, filename, action and timestamp
Example:
// 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_getRecentMessagesRetrieves recent messages from the short-term memory.
Parameters:
limit (number, optional): Maximum number of messages to retrieve, defaults to 10
importance (string, optional): Filter by importance level
Returns:
Object with status and array of messages
Example:
// 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_getActiveFilesRetrieves active files from the short-term memory.
Parameters:
limit (number, optional): Maximum number of files to retrieve, defaults to 10
Returns:
Object with status and array of active files
Example:
// 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_storeMilestoneStores a project milestone in the long-term memory.
Parameters:
title (string, required): Title of the milestone
description (string, required): Description of the milestone
importance (string, optional): Importance level, defaults to "medium"
metadata (object, optional): Additional metadata for the milestone
Returns:
Object with status, title, and timestamp
Example:
// 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_storeDecisionStores a project decision in the long-term memory.
Parameters:
title (string, required): Title of the decision
content (string, required): Content of the decision
reasoning (string, optional): Reasoning behind the decision
importance (string, optional): Importance level, defaults to "medium"
metadata (object, optional): Additional metadata for the decision
Returns:
Object with status, title, and timestamp
Example:
// 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_storeRequirementStores a project requirement in the long-term memory.
Parameters:
title (string, required): Title of the requirement
content (string, required): Content of the requirement
importance (string, optional): Importance level, defaults to "medium"
metadata (object, optional): Additional metadata for the requirement
Returns:
Object with status, title, and timestamp
Example:
// 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_recordEpisodeRecords an episode (action) in the episodic memory.
Parameters:
actor (string, required): Actor performing the action (user, assistant, system)
action (string, required): Type of action performed
content (string, required): Content or details of the action
importance (string, optional): Importance level, defaults to "low"
context (string, optional): Context for the episode
Returns:
Object with status, actor, action, and timestamp
Example:
// 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_getRecentEpisodesRetrieves recent episodes from the episodic memory.
Parameters:
limit (number, optional): Maximum number of episodes to retrieve, defaults to 10
context (string, optional): Filter by context
Returns:
Object with status and array of episodes
Example:
// 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_manageVectorUnified tool for managing vector embeddings with operations for store, search, update, and delete.
Parameters:
operation (string, required): Operation to perform ("store", "search", "update", "delete")
contentId (number, optional): ID of the content this vector represents (for store, update, delete)
contentType (string, optional): Type of content ("message", "file", "snippet", etc.)
vector (array, optional): Vector data as array of numbers (for store, update) or query vector (for search)
vectorId (number, optional): ID of the vector to update or delete
limit (number, optional): Maximum number of results for search operation, defaults to 10
threshold (number, optional): Similarity threshold for search operation, defaults to 0.7
metadata (object, optional): Additional info about the vector
Returns:
Object with status and operation results
Example:
// 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": { ... }
// },
// ...
// ]
// }The memory system automatically creates and maintains the following database tables:
messages: Stores user and assistant messages
id: Unique identifier
timestamp: Creation timestamp
role: Message role (user/assistant)
content: Message content
importance: Importance level
archived: Whether the message is archived
active_files: Tracks file activity
id: Unique identifier
filename: Path to the file
action: Last action performed
last_accessed: Timestamp of last access
milestones: Records project milestones
id: Unique identifier
title: Milestone title
description: Detailed description
timestamp: Creation timestamp
importance: Importance level
decisions: Stores project decisions
id: Unique identifier
title: Decision title
content: Decision content
reasoning: Decision reasoning
timestamp: Creation timestamp
importance: Importance level
requirements: Maintains project requirements
id: Unique identifier
title: Requirement title
content: Requirement content
timestamp: Creation timestamp
importance: Importance level
episodes: Chronicles actions and events
id: Unique identifier
timestamp: Creation timestamp
actor: Actor performing the action
action: Type of action
content: Action details
importance: Importance level
context: Action context
vectors: Stores vector embeddings for semantic search
id: Unique identifier
content_id: ID of the referenced content
content_type: Type of content (message, file, snippet)
vector: Binary representation of the embedding vector
metadata: Additional metadata for the vector
code_files: Tracks indexed code files
id: Unique identifier
file_path: Path to the file
language: Programming language
last_indexed: Timestamp of last indexing
metadata: Additional file metadata
code_snippets: Stores extracted code structures
id: Unique identifier
file_id: Reference to the parent file
start_line: Starting line number
end_line: Ending line number
symbol_type: Type of code structure (function, class, variable)
content: The code snippet 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",
});Database Connection Problems
Verify your Turso database URL and authentication token are correct
Check network connectivity to the Turso service
Verify firewall settings allow the connection
Missing Data
Check that data was stored with appropriate importance level
Verify the retrieval query parameters (limit, filters)
Check the database health with mcp_cursor10x_checkHealth()
Performance Issues
Monitor memory statistics with mcp_cursor10x_getMemoryStats()
Consider archiving old data if database grows too large
Optimize retrieval by using more specific filters
Check system health:
const health = await mcp_cursor10x_checkHealth({});
console.log("System Health:", health);Verify memory statistics:
const stats = await mcp_cursor10x_getMemoryStats({});
console.log("Memory Stats:", stats);Generate a status banner:
const banner = await mcp_cursor10x_generateBanner({});
console.log("Memory Banner:", banner);When storing items in memory, use appropriate importance levels:
low: General information, routine operations, everyday conversations
medium: Useful context, standard work items, regular features
high: Critical decisions, major features, important architecture elements
critical: Core architecture, security concerns, data integrity issues
MIT
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
