Loading ToolBench
Intelligent AI Memory Management with ML Auto-Triggers for Claude Desktop, Cursor IDE, and other MCP-compatible platforms
This MCP server exhibits significant quality gaps across naming, schema clarity, and documentation. While 19 tools are defined with basic descriptions and structured schemas, most descriptions are generic or lack actionable context. Parameter descriptions are minimal or absent in many tools. The tool set is highly redundant, multiple tools perform nearly identical functions (save_memory, create_memory, auto_save_memory; search_memory, search_memories; list_memories appears twice). This redundancy will cause LLMs to waste reasoning cycles choosing between functionally equivalent tools. Input schemas are present for all tools but lack richness, many parameters have no descriptions, and critical parameters like 'context' objects are insufficiently specified. Error handling is not documented. The server appears to mix concerns across multiple file locations (claude_mcp_server.py, cursor_mcp_server.py, lovable_mcp_server.py, http_server.py) without clear separation of responsibility. Critical issue: no evidence of output schemas being documented, LLMs cannot predict what fields will be returned. No security model, permission gates, or audit logging visible in the provided code snippets.
Analyze message for auto-triggers using ML model
Auto-save memory if content triggers threshold
Create a new memory
Log Cursor AI code assistance interactions with auto-memory
Track Cursor tab completion usage patterns
Get a specific memory
Get memory usage and ML model statistics
Severe tool redundancy across the API: save_memory, create_memory, and auto_save_memory all perform nearly identical write operations with overlapping semantics. Similarly, search_memory and search_memories are duplicates, as are list_memories (defined twice). This forces LLMs to waste reasoning cycles choosing between functionally equivalent tools.
No documented output schemas for any tool. LLMs cannot predict what fields will be returned by search_memory, get_memory_stats, or list_memories. This forces agents to guess at response structure and blocks downstream tool composition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
List memories for a project
List all saved memories with optional filtering
Save particularly valuable insights from Claude
Save UI/UX design patterns and components
Save detailed explanations provided by Claude
Save important information to memory with ML auto-detection
Save reusable UI components for Lovable projects
Search for design patterns and UI components
Search memories
Search through saved memories using semantic similarity
Track long conversation threads with context
Track Lovable project development progress
Parameter descriptions are missing or severely underdeveloped. For example, 'context' in save_memory is described as 'Additional context information' with no explanation of what fields it expects or how they affect behavior. 'min_similarity' in search_memory has a description but no guidance on typical ranges (0.1 - 0.9 would be helpful). analyze_message's 'platform_context' object is completely undescribed.
No error handling guidance. None of the tool descriptions explain what errors are possible, how to detect them, or what recovery steps an LLM should take. For example, search_memory might return no results, should the LLM try a different query? Relax the similarity threshold? Call a different tool?
Tools mix editor-specific concerns (Cursor, Claude, Lovable) without clear separation. The same server exposes cursor_code_assist, save_claude_insight, and save_design_pattern in one namespace. This violates single-responsibility and makes it unclear which tools apply to which context.
Missing parameter descriptions in several tools: get_memory_stats has no input parameters documented. list_memories (appears twice) lacks descriptions for 'limit', 'category', and 'tag' parameters. get_memory has only 'memory_id' documented. These omissions force LLMs to guess valid ranges and parameter meanings.
Enum fields lack explicit constraints or descriptions of allowed values. For example, 'complexity_level' in save_explanation has enums ['beginner','intermediate','advanced','expert'] but no guidance on how to choose. 'action_taken' in cursor_code_assist accepts ['accepted','rejected','modified'] but doesn't describe when to use each.
Generic tool descriptions provide minimal context on WHEN or WHY to use them. 'Get memory usage and ML model statistics' doesn't explain what an LLM should do with this info or when to call it. 'Track Cursor tab completion usage patterns' is vague, is this logging for analysis, or triggering auto-save? The relationship to memory operations is unclear.
No pagination or limit documentation. search_memory has a 'limit' parameter (default 5, max 20) but no explanation of what happens if the query matches > 20 results. Is there a cursor for fetching more? Will the agent need to call again with a different query? This blocks proper multi-step search workflows.
No security model documented. No evidence of permission gates, rate limiting, audit logging, or access control. Tools like save_memory and track_conversation_thread modify state but offer no indication of who can call them or what authorization is required. This is a production risk.