Provides persistent memory capabilities for GitHub Copilot.
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., "@JauMemory MCP Server save this for later: meeting with John about Q3 results"
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.
A Model Context Protocol (MCP) server that provides persistent memory capabilities for AI assistants like Claude. Store, recall, and analyze information across conversations with intelligent memory management.
🧠 Persistent Memory: Store information that persists across all sessions
🔍 Smart Recall: Search memories using keywords or semantic similarity
📊 Pattern Analysis: Automatically detect patterns and extract insights
🏷️ Automatic Classification: Memories are automatically categorized (errors, solutions, insights, questions)
🔄 Collection Consolidation: Roll a collection's memories up into a single summary memory
🎯 Importance Scoring: Content-based importance assessment with learning value metrics
🤝 Multi-Agent Support: Agent identities, shared memory, assignments via shortcut flags, error-pattern learning
🚀 Production Ready: Connects to JauMemory cloud service with secure authentication
Related MCP server: Recall
Node.js 18.0.0 or higher
npm or yarn
JauMemory account (free tier available at mem.jau.app)
npm install -g @jaumemory/mcp-servergit clone https://github.com/Jau-app/jaumemory-mcp-server.git
cd jaumemory-mcp-server
npm install
npm run buildAdd to your Claude desktop configuration file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Note: Claude Desktop works with the npx approach without requiring global installation.
Add to your Claude Code configuration:
MacOS/Linux: ~/.config/claude/claude_code_config.json
Windows: %APPDATA%\claude\claude_code_config.json
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Open Cursor Settings
Navigate to MCP section
Add new MCP server with command: npx -y @jaumemory/mcp-server
Or edit configuration file:
MacOS/Linux: ~/.cursor/mcp_config.json
Windows: %APPDATA%\Cursor\mcp_config.json
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Installation (Required):
⚠️ IMPORTANT: Install in the same terminal environment where Cline will run:
Windows (native): Install in PowerShell or Command Prompt (the same environment Cline uses)
WSL (Windows Subsystem for Linux): Install in WSL terminal for your specific user
macOS/Linux: Install in your terminal of choice
npm install -g @jaumemory/mcp-serverIf using both Windows and WSL, install in both environments:
# In Windows PowerShell
npm install -g @jaumemory/mcp-server
# In WSL terminal
npm install -g @jaumemory/mcp-serverAdd to Cline MCP settings (in your Cline configuration file):
{
"mcpServers": {
"jaumemory": {
"type": "stdio",
"timeout": 60,
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Note: The "type": "stdio" and "timeout": 60 settings are important for Cline compatibility. Installing in the correct terminal environment ensures Cline can find and execute the server. The global installation helps avoid Windows file locking issues.
Add to Windsurf MCP configuration:
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Add to GitHub Copilot MCP settings:
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Add to ChatGPT MCP configuration:
{
"mcpServers": {
"jaumemory": {
"command": "npx",
"args": ["-y", "@jaumemory/mcp-server"]
}
}
}Environment variables are not required for basic setup. Authentication is handled by the mcp_login and mcp_authenticate tools; no identity or credential values belong in configuration files.
Optional settings (see .env.example for the full list):
# Optional: Logging configuration
LOG_LEVEL=info
NODE_ENV=productionNote: Even with environment variables set, you must still authenticate using the mcp_login tool on first use.
Launch your AI assistant (Claude Desktop, Cursor, etc.) - the MCP server will start automatically
Use the mcp_login tool to initiate authentication
Click the approval link that opens in your browser
Complete the authentication in your web browser
The server will automatically store your credentials securely
That's it! No configuration files or environment variables needed for basic setup.
The server exposes 50 tools. Full argument contracts for every
tool are available in-band — call
get_guide({ topic: "tools/<category>/<name>" }), or browse the
same docs at https://mem.jau.app/v1/help.
Category | Tools |
Discovery |
|
Auth |
|
Memory |
|
Agents |
|
Collections |
|
Credential vault |
|
Tool registry |
|
Skills |
|
Toolkit |
|
Scheduling |
|
Berrry integration |
|
Highlights with examples:
remember - Store a new memory with automatic classification
remember({
content: "Important insight about TypeScript generics",
tags: ["typescript", "learning"],
importance: 0.8,
shortcuts: ["--insight", "--high"]
})recall - Search and retrieve memories
recall({
query: "typescript generics",
limit: 10,
mode: "keyword" // or "semantic" for AI-powered search
})forget - Delete a specific memory
forget({
memoryId: "550e8400-e29b-41d4-a716-446655440000"
})update - Update an existing memory
update({
memoryId: "memory-id",
content: "Updated content",
importance: 0.9
})analyze - Analyze patterns and extract insights
analyze({
timeRange: "week" // or "day", "month", "all"
})consolidate - Consolidate similar memories (args:
similarity_threshold, min_group_size, archive_originals,
dry_run). Note: the server does not implement standalone
consolidation yet and returns a clean error pointing to
consolidate_collection, which summarizes one collection's memories
for real.
memory_stats - Get statistics about memories
memory_stats({
query: "project-name",
timeRange: { start: "2024-01-01", end: "2024-12-31" }
})create_agent - Create an AI agent with personality
create_agent({
name: "Code Reviewer",
personalityTraits: ["analytical", "detail-oriented"],
specializations: ["code-review", "best-practices"]
})agent_error_learning - Two-strike error learning for agents
agent_error_learning({
action: "report",
agentId: "…uuid…",
errorSignature: "TypeError user.profile undefined",
errorMessage: "Undefined property access in user service"
})Quick memory creation with metadata flags:
remember({
content: "Fix authentication bug",
shortcuts: ["--bug", "--high", "--assign @backend-dev", "--project webapp"]
})Available shortcuts:
Types: --todo, --task, --bug, --question, --note, --reflection
Status: --pending, --wip, --done, --blocked [reason]
Priority: --low, --medium, --high, --urgent
Assignment: --assign @agent-name, --notify @agent1,@agent2
Context: --project name, --repo url
The full semantics live in
get_guide({ topic: "concepts/shortcuts" }).
JauMemory automatically classifies memories:
🔴 Error: Problems and bugs encountered
✅ Solution: Fixes and resolutions
💡 Insight: Patterns and realizations
❓ Question: Unknowns and research needs
# Install dependencies
npm install
# Run in development mode
npm run dev
# Build for production
npm run build
# Run tests
npm test
# Lint code
npm run lintjaumemory-mcp-server/
├── src/ # TypeScript source code
│ ├── index.ts # Main entry point
│ ├── auth/ # Authentication logic
│ ├── client/ # gRPC client code
│ ├── tools/ # MCP tool implementations
│ └── utils/ # Utility functions
├── dist/ # Compiled JavaScript
├── proto/ # Protocol buffer definitions
└── package.json # Package configurationIf you encounter TAR_ENTRY_ERROR errors on Windows when using npx:
Solution 1: Use global installation
# Run in PowerShell as Administrator
npm install -g @jaumemory/mcp-server --forceThen update your config to use the global command:
{
"mcpServers": {
"jaumemory": {
"command": "jaumemory-mcp-server",
"args": []
}
}
}Solution 2: Clear npm cache
npm cache clean --force
npm config set fetch-retries 10
npm config set fetch-timeout 60000
npx -y @jaumemory/mcp-serverSolution 3: Local installation
mkdir C:\JauMemory
cd C:\JauMemory
npm install @jaumemory/mcp-serverThen use in config:
{
"mcpServers": {
"jaumemory": {
"command": "node",
"args": ["C:\\JauMemory\\node_modules\\@jaumemory\\mcp-server\\dist\\index.js"]
}
}
}Ensure you have a valid JauMemory account
Check your username and email are correct
Look for the approval link in your browser
Check logs: LOG_LEVEL=debug npm start
Verify internet connection
Check if JauMemory service is available at https://mem.jau.app
Ensure firewall allows HTTPS/gRPC connections
Try clearing auth cache and re-authenticating
Verify MCP configuration in Claude desktop
Restart Claude after configuration changes
Check Claude logs for MCP errors
Ensure Node.js version is 18.0.0 or higher
Authentication uses secure MCP approval flow
Credentials are encrypted and stored securely
All communication uses HTTPS/TLS
No sensitive data is logged
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Built for use with Claude by Anthropic
Uses the Model Context Protocol specification
Powered by JauMemory's high-performance Rust backend
Made with ❤️ for the AI assistant community
Add a memory to a collection.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection | |
| memory_id | Yes | ID of the memory to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not specify if the collection must exist, if duplicate memories are allowed, or if the operation is idempotent. Lacks critical behavioral details 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?
Single sentence is extremely concise. No wasted words, but arguably too brief given the lack of other information. Still, conciseness is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description is minimal. It does not address side effects, errors, or completion scenarios. The agent needs more context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb+resource: 'Add a memory to a collection.' It distinguishes from sibling 'remove_from_collection' which performs the opposite operation. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., collection must exist) or scenarios where 'remove_from_collection' might be more appropriate. Only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage collaboration between agents.
Usage Examples: // Start a collaboration agent_collaboration({ action: "start", agentId: "frontend-dev", collaboratorId: "backend-dev", collaborationType: "api-integration", memoryId: "task-123" })
// Complete a collaboration agent_collaboration({ action: "complete", agentId: "frontend-dev", collaborationId: "collab-456", outcome: "success" })
// List collaborations for an agent agent_collaboration({ action: "list", agentId: "backend-dev" })
Collaboration Types:
code-review: Code review collaboration
pair-programming: Pair programming session
api-integration: API integration work
testing: Testing collaboration
debugging: Debugging session
planning: Planning and design
documentation: Documentation work
Outcomes:
success: Collaboration completed successfully
partial: Some goals achieved
failed: Collaboration did not achieve goals
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| agentId | Yes | Initiator agent ID | |
| collaboratorId | No | Collaborator agent ID (for start action) | |
| collaborationType | No | Type of collaboration (for start action) | |
| collaborationId | No | Collaboration ID (for complete action) | |
| outcome | No | Outcome (for complete action) | |
| memoryId | No | Related memory ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry the burden. It explains actions and outcomes but does not disclose side effects (e.g., record creation), permission requirements, or error handling, leaving some behavioral ambiguity.
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?
Description is front-loaded with a clear summary, followed by concise usage examples and enumerations. Every section is useful and avoids redundancy.
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?
Covers actions, parameters, and enumerated values well, but lacks return value description (no output schema) and error handling details, leaving gaps for an agent to fully understand the tool's output and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by showing parameter usage via examples, listing collaboration types and outcomes with explanations, and implying conditional requirements (e.g., collaboratorId only for 'start').
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 'Manage collaboration between agents' and provides usage examples for the three actions (start, complete, list), making it distinct from sibling tools like agent_memory or agent_reflection.
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?
Usage examples illustrate typical scenarios, but no explicit guidance on when not to use this tool or comparisons with alternatives is provided. However, the examples effectively convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable agents to learn from errors using a 2-strike protocol.
Usage Examples: // Report a new error agent_error_learning({ action: "report", agentId: "backend-dev", errorSignature: "TypeError: Cannot read property 'x' of undefined", errorMessage: "Undefined property access in user service", contextSnapshot: "const name = user.profile.name; // user.profile is undefined", attemptedSolution: "Added optional chaining: user.profile?.name", projectContext: "api-service" })
// Mark error as solved agent_error_learning({ action: "solve", agentId: "backend-dev", patternId: "err-pattern-123", solution: "Always check if user.profile exists before accessing properties", verificationSteps: [ "Run: npm test user.service.spec.ts", "Verify no TypeErrors in logs", "Check user profile endpoint returns 200" ] })
// Record failed attempt agent_error_learning({ action: "fail", agentId: "frontend-dev", patternId: "err-pattern-456", attemptedSolution: "Tried using default values but still crashed" })
The 2-Strike Protocol:
First encounter: Agent gets the error signature to recognize it
Second encounter: Agent must solve it or face consequences
After 2 failures: Error importance increases, agent status may change
Response Types:
first_occurrence: New error, pattern ID provided
solution_found: Previous solution exists
previous_attempts_failed: Shows attempt count (pressure!)
new_problem: Similar to other errors but unique
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| agentId | Yes | Agent ID | |
| errorSignature | No | Unique error identifier (for report) | |
| errorMessage | No | Error message (for report) | |
| contextSnapshot | No | Code/context where error occurred | |
| attemptedSolution | No | What was tried | |
| projectContext | No | Project name | |
| patternId | No | Error pattern ID (for solve/fail) | |
| solution | No | Working solution (for solve) | |
| verificationSteps | No | How to verify the fix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains response types (first_occurrence, etc.) and consequences (agent status may change). This provides good behavioral context beyond the basic read/update intent, though it omits details like data persistence or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings and code examples, making it easy to scan. While lengthy, the content is justified for a tool with 10 parameters and a protocol. Every section adds value, though some repetition exists.
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 (10 parameters, no output schema), the description covers the protocol, usage patterns, and response types. It lacks details on return values or error handling, but for a learning tool, it provides sufficient context for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 10 parameters have descriptions in the schema (100% coverage). The description adds value by showing how parameters are used together in examples (e.g., report uses errorSignature, solve uses patternId). This clarifies parameter relationships beyond individual schema descriptions.
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: 'Enable agents to learn from errors using a 2-strike protocol.' It specifies three distinct actions (report, solve, fail) and provides usage examples, distinguishing it from sibling tools focused on memory or collections.
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 explicit usage examples for each action and explains the 2-strike protocol, giving clear context for when to use each action. However, it does not explicitly state when not to use the tool or compare with alternatives, though siblings are clearly differentiated by purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link memories to agents or recall agent-specific memories.
Usage Examples: // Link a memory to an agent agent_memory({ action: "link", agentId: "frontend-dev", memoryId: "mem-123-456", category: "learning", projectContext: "webapp" })
// Recall all memories for an agent agent_memory({ action: "recall", agentId: "backend-dev" })
// Search agent memories agent_memory({ action: "recall", agentId: "code-reviewer", query: "authentication", category: "error", limit: 10 })
// Project-specific recall agent_memory({ action: "recall", agentId: "test-engineer", projectContext: "api-service", category: "task" })
Memory Categories:
task: Assigned tasks and TODOs
learning: Things the agent learned
error: Errors encountered
solution: Solutions found
reflection: Agent reflections
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| agentId | Yes | Agent ID | |
| memoryId | No | Memory ID (for link action) | |
| category | No | Memory category like task, learning, error | |
| projectContext | No | Project name for context | |
| query | No | Search query (for recall action) | |
| limit | No | Max results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains the two actions and required parameters, but does not disclose side effects (e.g., whether linking creates a new memory or associates an existing one), authorization needs, or rate limits. Partial 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 front-loaded with the purpose and includes well-structured examples and a category list. While somewhat lengthy, each section serves a purpose. Could be more concise, but it is structured logically.
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 7 parameters, no output schema, and no annotations, the description covers the two actions, all parameters through examples, and provides a category list. However, it does not describe the return format of recall, which would be helpful for 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 coverage is 100%, so baseline is 3. The description adds value by defining memory categories and showing parameter combinations in examples, which enhances understanding beyond the schema's property descriptions.
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 'Link memories to agents or recall agent-specific memories' and provides specific usage examples for both actions. It effectively distinguishes the tool's purpose from siblings by focusing on agent-memory linking and recall.
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?
Examples show when to use link vs recall, but there is no explicit guidance on when to use this tool instead of siblings like 'remember' or 'memorize'. The description provides clear context but lacks exclusions or alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and retrieve agent reflections for continuous improvement.
Usage Examples: // Create a learning reflection agent_reflection({ action: "create", agentId: "frontend-dev", reflectionType: "learning", content: "Discovered that React.memo can prevent unnecessary re-renders in large lists", lessonsLearned: [ "Use React.memo for expensive components", "Profile before optimizing", "Not all components need memoization" ] })
// Create a mistake reflection agent_reflection({ action: "create", agentId: "backend-dev", reflectionType: "mistake", content: "Forgot to add database indexes, causing slow queries in production", lessonsLearned: [ "Always analyze query patterns before deployment", "Add indexes for frequently filtered columns", "Monitor query performance in staging" ] })
// Create a collaboration reflection agent_reflection({ action: "create", agentId: "code-reviewer", reflectionType: "collaboration", content: "Worked with frontend-dev to establish better PR review guidelines", lessonsLearned: [ "Clear PR descriptions save review time", "Automated checks reduce manual review burden" ], relatedAgents: ["frontend-dev", "test-engineer"] })
// List all reflections for an agent agent_reflection({ action: "list", agentId: "test-engineer" })
// List specific type of reflections agent_reflection({ action: "list", agentId: "project-manager", reflectionType: "success" })
Reflection Types:
learning: New knowledge or insights gained
mistake: Errors made and lessons learned
success: Achievements and what worked well
collaboration: Insights from working with other agents
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| agentId | Yes | Agent ID | |
| reflectionType | No | Type of reflection | |
| content | No | Reflection content (for create) | |
| lessonsLearned | No | Key takeaways | |
| relatedAgents | No | Other agents involved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool supports two actions (create and list) and defines reflection types. It does not mention persistence, side effects, or permissions, but the examples imply typical behavior.
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?
Description is well-structured with clear sections for usage examples and reflection type definitions. However, it is verbose due to multiple examples; could be slightly more concise while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers all aspects: purpose, actions, parameters, reflection types, and typical usage patterns. It is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value beyond schema: it provides typical values for lessonsLearned and relatedAgents, and explains reflection types with context. The examples clarify parameter usage effectively.
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: 'Create and retrieve agent reflections for continuous improvement.' It distinguishes from sibling tools like agent_memory and agent_collaboration by focusing on reflections with specific types (learning, mistake, etc.).
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?
Usage examples show when to use create vs list and different reflection types. However, it does not explicitly exclude alternatives or mention when not to use this tool over siblings like agent_error_learning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze memory patterns and extract insights
| Name | Required | Description | Default |
|---|---|---|---|
| timeRange | No | Time range to analyze (e.g., "day", "week", "month", "all") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, modifies state, or requires authentication. The description is too brief to convey behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Front-loaded with action. 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?
With no output schema and only one parameter, description should clarify what insights are returned, example outputs, and side effects. Currently incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear enum for timeRange. Description adds 'memory patterns and insights' but doesn't elaborate on how the parameter affects analysis. Baseline 3 achieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Analyze memory patterns and extract insights', which is a verb+resource but vague. It doesn't specify what 'analyze' entails or what insights are extracted. It is not clearly differentiated from siblings like 'agent_memory' or 'consolidate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites or context where analysis is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidate similar memories into insights based on semantic similarity
| Name | Required | Description | Default |
|---|---|---|---|
| similarity_threshold | No | Minimum similarity score to group memories (0.0-1.0, default: 0.7) | |
| min_group_size | No | Minimum number of memories to form a group (default: 2) | |
| archive_originals | No | Archive original memories after consolidation (default: true) | |
| dry_run | No | Preview consolidation without making changes (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions consolidation into insights but fails to note that originals are archived by default (destructive), nor does it explain the dry-run preview. Safety-critical details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core purpose. No extraneous 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 tool with 4 parameters and no output schema, the description lacks detail on return values, effects of dry_run, and what 'insights' implies. These gaps reduce 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?
All parameters have descriptions in the schema (100% coverage). The tool description adds no additional context beyond the schema, thus baseline 3 applies.
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 'consolidate', the resource 'similar memories', and the basis 'semantic similarity'. It effectively distinguishes from siblings like 'consolidate_collection' and 'recall'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The sibling list is extensive, but the description does not mention contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consolidate all memories in a collection into a comprehensive summary or insight.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection to consolidate | |
| summarize_only | No | Only create a summary without modifying the collection (default: false) | |
| title | No | Title for the consolidated memory (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose whether consolidation modifies or deletes memories, or what permissions are needed. The 'summarize_only' parameter implies default modification, but this is not stated.
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 concise single sentence without clutter, but it lacks structure (e.g., no use-case sections). It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return values or side effects, but it does not. The tool has 3 parameters and no annotations, and the description fails to fully explain the operation's impact on the collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds no additional parameter-level information beyond the schema's descriptions, so it does not enhance understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Consolidate' and the resource 'all memories in a collection', producing 'a comprehensive summary or insight'. It distinguishes this from sibling tools like 'consolidate' (general) and other collection 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?
No guidance is provided on when to use this tool versus alternatives like 'consolidate' or 'add_to_collection'. The description lacks context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new agent with personality traits and specializations.
Usage Examples: // Basic agent create_agent({ name: "Code Reviewer" })
// Agent with personality create_agent({ name: "Frontend Expert", personalityTraits: ["detail-oriented", "creative", "user-focused"], specializations: ["React", "TypeScript", "CSS", "UX"] })
// Agent with custom prompts create_agent({ name: "Test Engineer", personalityTraits: ["thorough", "systematic"], specializations: ["Jest", "Cypress", "TDD"], updatePrompts: [ "Always consider edge cases", "Write tests before implementing fixes" ] })
Pre-configured Agents (from migration):
code-reviewer: Analytical, detail-oriented reviewer
backend-dev: Systems thinker for backend development
frontend-dev: Creative UI/UX focused developer
test-engineer: Quality-focused testing specialist
project-manager: Organized project coordinator
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent name | |
| personalityTraits | No | Personality traits like curious, analytical, creative | |
| specializations | No | Areas of expertise like frontend, backend, testing | |
| updatePrompts | No | Custom prompts for agent updates | |
| id | No | Optional agent ID (if not provided, will be auto-generated) | |
| initialLearningRate | No | Initial learning rate (0.0-1.0, default: 0.5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes creation parameters but omits side effects (e.g., persistence, error on duplicate ID, return value). Mutating nature is implied but not detailed.
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 longer than necessary (244 words) due to extensive code examples and pre-configured agent list. While examples aid understanding, they could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the description lacks explanation of return values (no output schema), post-creation behavior, or parameter constraints (e.g., uniqueness of ID). Incomplete for a creation tool.
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?
All 6 parameters have schema descriptions (100% coverage). The description's examples illustrate parameter combinations but add no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new agent' with specific attributes (personality traits, specializations). This distinguishes it from sibling tools like 'update_agent_name' or 'list_agents'.
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?
Usage examples demonstrate typical invocations (basic, with personality, with prompts). The list of pre-configured agents provides context but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new collection for organizing memories.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the collection | |
| description | No | Description of the collection (optional) | |
| memory_ids | No | Initial memory IDs to add to the collection (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states a create operation. It fails to disclose behavioral traits like behavior on duplicate names, return values, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and concise. Every word is necessary; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (3 params, no output schema), the description omits important context such as return behavior, uniqueness constraints, and how it relates to sibling collection operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal value beyond the schema, only hinting at the purpose of memory_ids. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new collection for organizing memories' clearly states the verb (create), resource (collection), and purpose (organizing memories). It unambiguously distinguishes from sibling tools like add_to_collection, update_collection, and get_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as add_to_collection or consolidate_collection. The description does not mention prerequisites or context for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a collection (memories are not deleted, only the collection).
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses a critical behavioral trait (memories are preserved) beyond the basic action. Could mention irreversibility but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-param, no-output tool, description is sufficiently complete. Could add 'This action cannot be undone' but overall covers the main purpose and side effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description and pattern. The description adds no extra meaning beyond what the schema already provides for collection_id.
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 (Delete a collection) and adds a key nuance (memories are not deleted), making it specific and unambiguous.
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?
Usage is implied: use to delete a collection without affecting memories. However, no explicit guidance on when to use vs. siblings like update_collection or consolidate_collection, and no mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific memory
| Name | Required | Description | Default |
|---|---|---|---|
| memoryId | Yes | Memory ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Delete' but does not disclose if the action is irreversible, what happens to related data, or any permission requirements. Essential behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at only 5 words, which is efficient. However, it lacks any structural elements like sections or bullet points, and the brevity borders on under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is minimally adequate. However, it omits details about the tool's role within the broader memory system and what happens after deletion, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'memoryId', and its description is already present. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 'Delete' and the resource 'specific memory', making the tool's purpose immediately clear. It distinguishes from sibling tools like 'remember' (store) and 'recall' (retrieve), though it could specify scope or 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 provides no guidance on when to use this tool versus alternatives, such as removing all memories or handling cascading effects. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific collection including all its memories.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read-only operation (get details), but lacks disclosures on authentication, rate limits, or what happens if collection_id is invalid.
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 concise sentence that is front-loaded with the core action. No wasted words.
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 simple schema (1 parameter, no output schema), description covers the essential purpose. Could mention requirement for existing collection ID, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter with description and pattern). Description adds no new information beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get details of a specific collection including all its memories,' specifying verb and resource, and distinguishes from sibling tools like list_collections (list all) and create_collection.
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 when-to-use or when-not-to-use guidance. Implied that it's for retrieving a single collection's details, but no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available agents with their details.
Usage Examples: // List all agents list_agents({})
// List only active agents list_agents({ status: "active" })
// List agents in error state list_agents({ status: "error" })
Agent Statuses:
active: Ready for tasks
learning: Currently improving from errors
error: Encountered issues, needs attention
archived: No longer in use
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses that this is a read-only listing operation with no destructive side effects, and it explains the meaning of status values.
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 concise and well-structured, starting with a clear purpose sentence followed by usage examples and a status key, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers all relevant details: status filter values and example usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description elaborates on the status enum values and provides usage examples, adding significant meaning beyond the schema's minimal description 'Filter by status'.
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 'list' and resource 'agents', distinguishing it from sibling tools like create_agent or update_agent_name.
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?
Usage examples are provided for listing all agents or filtering by status, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your collections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only operation but does not disclose any limitations, pagination, or ordering. The transparency is adequate for a simple list but lacks depth.
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 no wasted words. It is perfectly concise for the simplicity of the tool.
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, no output schema, and a straightforward purpose, the description completely covers the required information. It states what the tool does (list all collections) adequately.
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 no parameters, and the schema coverage is 100%. The description adds no parameter information because none is needed, meeting the baseline for parameterless tools.
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 'List' and resource 'your collections', making the action unambiguous. It distinguishes from sibling tools like get_collection (likely for a specific collection) and create_collection.
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 like get_collection or consolidate_collection. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete MCP authentication with the auth token you received from the web approval page. You MUST have clicked the link, approved in your browser, and copied the authentication code.
| Name | Required | Description | Default |
|---|---|---|---|
| auth_token | Yes | The EXACT authentication code shown on the approval webpage after clicking Approve (e.g., "happy-star") | |
| request_id | No | The request ID from mcp_login response (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Provides basic prerequisite but omits error handling, side effects (e.g., session creation), and contradicts schema on request_id requiredness.
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?
Two sentences with clear focus. Could be better structured (e.g., list prerequisites), but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value description, error handling, and does not explain the full authentication flow (preceding mcp_login). Inconsistency in request_id reduces 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 coverage is 100% so baseline 3. Description adds examples for auth_token, but for request_id it claims required (schema says optional), adding confusion rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it completes MCP authentication with an auth token, specifying the prerequisite of having clicked the link and approved. However, it does not differentiate from sibling tools like mcp_login or mcp_logout.
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?
Emphasizes the prerequisite action (must have clicked and approved), implying it should be used after mcp_login. But lacks explicit when-not-to-use or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate MCP authentication flow. Provide your REAL JauMemory username and email to start the manual approval process. NOTE: You MUST click the link provided and approve in your browser. Test accounts will not work. Username and email can be optionally set via JAUMEMORY_USERNAME and JAUMEMORY_EMAIL environment variables.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Your REAL JauMemory username (not a test account). Optional if set in JAUMEMORY_USERNAME env var. | |
| No | Your REAL JauMemory email address (must match your registered account). Optional if set in JAUMEMORY_EMAIL env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses manual browser interaction, test account restrictions, and env var support. It does not detail idempotency or side effects, but for a login tool this is reasonable.
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 front-loaded with the action and uses three sentences. Some redundancy exists (e.g., repeating 'REAL' for both fields), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not mention what the tool returns (e.g., a link or status). It implies a link is provided but is not explicit, leaving agents guessing about the next step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial meaning: 'REAL' credentials, 'not a test account', and env var fallback. This goes beyond the schema's basic descriptions.
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 'Initiate MCP authentication flow' with a specific verb and resource. It distinguishes mcp_login from sibling tools like mcp_authenticate and mcp_logout by focusing on starting the authentication process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires real JauMemory credentials, manual browser approval, and env var fallback. However, it does not explicitly contrast with mcp_authenticate or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logout and revoke the current MCP session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It states 'revoke,' indicating a destructive action, but does not clarify side effects, such as whether future calls will fail or if re-authentication is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately front-loaded and 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?
For a simple tool with no parameters or output schema, the description covers the essential purpose. However, it could note that an active session is required and that the action is irreversible.
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?
There are zero parameters, so the schema provides full coverage. The description adds no parameter information, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (logout and revoke) and the resource (MCP session). It effectively distinguishes itself from sibling tools like mcp_login and mcp_authenticate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to end the current session) but provides no explicit guidance on prerequisites, such as needing an active session, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about memories with optional filtering.
Usage Examples: // Get overall stats memory_stats()
// Stats for memories containing "error" memory_stats({ query: "error" })
// Stats for last week memory_stats({ timeRange: { start: "2025-01-17", end: "2025-01-24" } })
// Stats for React-related errors memory_stats({ query: "react error*", minImportance: 0.5 })
// Stats for specific tags memory_stats({ tags: ["bug", "frontend"] })
Returns:
Total memory count (filtered)
Memory type distribution
Top 20 tags with counts
Importance distribution
Keyword frequency (if applicable)
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (supports wildcards with *) | |
| tags | No | Filter by tags | |
| minImportance | No | Minimum importance threshold | |
| timeRange | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It lists the return data (count, distributions, top tags, etc.) but does not explicitly state that the tool is read-only, nor does it mention performance implications or side effects. The name implies read-only behavior, but this is not confirmed.
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 well-structured with a brief overview, multiple examples, and a bullet list of return fields. While slightly verbose, each section adds value. It is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values. All parameters are optional and described. The examples cover different use cases. Missing information includes potential pagination or limits on the number of memories processed, but overall it is complete enough for a stats tool.
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 covers 75% of parameters with descriptions. The description adds value by showing usage examples that illustrate wildcard support in 'query', date format in 'timeRange', and combination of parameters. This goes beyond the schema alone.
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 'Get statistics about memories with optional filtering,' using a specific verb and resource. The examples further clarify the purpose, and the tool is distinct from siblings like 'recall' and 'remember' which focus on retrieval rather than statistics.
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 concrete usage examples showing various filtering options, which implicitly guides when to use the tool. However, it does not explicitly state when not to use it or compare it to sibling tools like 'recall' or 'consolidate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and retrieve memories
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| limit | No | Maximum results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as authentication, rate limits, or side effects. It only states the basic function.
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, front-loaded sentence. It is concise but lacks depth; however, for its length it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain what 'memories' are, how the tool fits among siblings, or any important context like scope or limitations. It is incomplete given the presence of multiple memory-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with minimal descriptions ('Search query', 'Maximum results'). The tool description adds no further detail, so it meets the baseline without adding 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 'search and retrieve' and the resource 'memories', making the purpose unambiguous. It distinguishes itself from siblings like 'remember' and 'forget'.
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 like 'remember' or 'memory_stats'. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new memory with optional context and importance scoring
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The memory content to store | |
| context | No | Additional context for the memory | |
| importance | No | Importance score (0-1) | |
| tags | No | Tags for categorization | |
| metadata | No | Additional metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Store a new memory' without mentioning side effects, idempotency, overwrite behavior, or permissions. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 10 words. Front-loaded with the core action. Efficient, though slightly more detail could be added without harming 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?
No output schema and no annotations. The description does not explain return values, storage behavior, or parameter constraints beyond schema. For a storage tool with 5 parameters, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value by mentioning 'optional context and importance scoring', but this largely restates what is in the schema. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Store), the resource (a new memory), and optional features (context and importance scoring). It distinguishes from siblings like recall, forget, and memory_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like add_to_collection or recall. The description does not mention prerequisites, exclusions, or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a memory from a collection.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection | |
| memory_id | Yes | UUID of the memory to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only says 'remove', implying modification without destruction, but does not disclose side effects, permissions, or whether the memory itself is deleted or just the association.
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 extremely concise (one sentence) with no unnecessary words. However, it could be slightly improved by adding minimal context 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?
For a simple tool with two UUID params and no output schema, the description is adequate but lacks details like whether the memory is deleted or what the return value is. It does not fully cover the context needed for complete 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%; each parameter is already described as a UUID. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Remove a memory from a collection' with a specific verb and resource. It distinguishes itself from sibling 'add_to_collection' and other collection-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?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'delete_collection' or 'forget', nor does it explain prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing memory
| Name | Required | Description | Default |
|---|---|---|---|
| memoryId | Yes | Memory ID to update | |
| content | No | New content | |
| importance | No | New importance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether content is overwritten or merged, side effects, or validation. It only states it updates, which is already implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks important details. It is not overly verbose, but it sacrifices completeness for 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?
With no output schema, no annotations, and many sibling tools, the description is insufficient. It does not explain return values, error conditions, or constraints, making it incomplete for an agent to use safely.
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?
Input schema descriptions cover all three parameters clearly (memoryId, content, importance). The description does not add additional meaning beyond the schema, meeting the baseline for full 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 it updates an existing memory, which is a specific verb and resource. However, it does not differentiate from other update tools like update_agent_name or update_collection, though those target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'remember' or 'recall'. No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an agent's name using the new naming convention.
Usage Examples: // Update an agent's name update_agent_name({ agentId: "DW1", newName: "Documentation Writer:dw1" })
// Change to a different role update_agent_name({ agentId: "ta1", newName: "Test Automation Engineer:tae1" })
Name Format Requirements:
Must include both long name and short name
Format: "Long Name:shortname"
Example: "Backend Developer:bd1"
Short names should be 2-4 characters
This allows agents to be reassigned to different roles as they grow and evolve.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | Agent ID to update | |
| newName | Yes | New name in format "Long Name:shortname" |
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 mentions reassigning roles but does not disclose destructive potential, auth needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes multiple sections (summary, examples, format) and is front-loaded, but could be more concise by merging repetitive parts.
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?
It covers purpose and usage well but lacks mention of return values or error handling, which would be needed for full completeness without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds format details and examples beyond the schema's descriptions, helping the agent construct correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an agent's name using a new naming convention. It distinguishes from siblings like 'create_agent' and 'update' by being specific to renaming agents.
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?
Usage examples and format requirements are provided, but there is no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update collection details (name and/or description).
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | UUID of the collection | |
| name | No | New name for the collection (optional) | |
| description | No | New description for the collection (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Update' without disclosing side effects, permissions, reversibility, or what happens to unspecified fields. Lacks 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?
Single sentence, zero wasted words. Front-loads the action and resource efficiently.
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 output schema, the description is too minimal. It does not explain return values, error conditions, or whether the update is partial or replaces all details. Given the presence of sibling tools like 'update', 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 has 100% coverage with descriptions for all parameters. The description reiterates that name and/or description are optional but adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('collection details') with specific fields ('name and/or description'). It distinguishes from sibling tools like create_collection, delete_collection, get_collection, and list_collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'update' or other collection operations. Does not mention prerequisites, when not to use, or alternatives.
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.
v0.3.3add_to_collectionagent_collaborationagent_error_learningagent_memoryagent_reflectionanalyzeconsolidateconsolidate_collectioncreate_agentcreate_collectiondelete_collectionforgetget_collectionlist_agentslist_collectionsmcp_authenticatemcp_loginmcp_logoutmemory_statsrecallrememberremove_from_collectionupdateupdate_agent_nameupdate_collectionMost tools have clearly distinct purposes, such as memory CRUD, collection management, and agent operations. However, tools like 'analyze', 'consolidate', and 'consolidate_collection' could cause slight confusion due to overlapping analytical functions, though descriptions help differentiate them.
All tool names follow a consistent snake_case pattern, typically using verb_noun structure (e.g., 'add_to_collection', 'create_agent', 'list_collections'). Even simple verbs like 'update' and 'forget' fit the pattern. The 'mcp_' prefix is uniformly used for authentication tools.
The server provides 25 tools covering memory operations, agent management, collections, authentication, and analysis. While slightly above the typical compact range, the number is justified by the breadth of features and each tool serves a specific purpose without unnecessary duplication.
The tool set covers full CRUD for memories and collections, agent lifecycle (create, list, update name), and additional agent-specific features like error learning and reflections. Missing an explicit 'delete_agent' tool and bulk operations, but the core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Long-term memory for AI assistants. Isolated per-user storage, recall across conversations.
Gives your AI assistant persistent memory and intelligence about your work patterns.
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jau-app/JauMemory-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
