Loading ToolBench
Super personal assistant for any AI CLI - Universal, cross-project, 100% local & private memory system with conversation history, long-term memory storage, vector indexing, and hybrid search
Three tools with complete schemas and descriptions, but descriptions are verbose (200+ chars) and lack WHEN-TO-USE clarity for LLM selection. All tools have proper input schemas with types and descriptions. memory_search and memory_record are well-structured; memory_update_long_term uses enum constraints correctly. However, descriptions bury actionable guidance in prose rather than leading with concise intent. No output schemas documented. Error handling and recovery guidance absent.
Record the current conversation exchange for future reference. WHEN TO USE: - After EVERY meaningful conversation exchange - When the conversation contains information worth remembering - To ensure continuity across sessions What to record: - user_message: The user's question or request - ai_response: Summary of your response (key points, not full text) This builds memory over time, allowing recall of past discussions in future sessions.
Search through conversation history and long-term memories. WHEN TO USE: - When user asks about past discussions, decisions, or preferences - When user references something "we talked about before" - When you need context from previous sessions - When user asks "what did we decide about X" or "remember when we..." - When you need to know user preferences (search "preferences" or specific topic) This searches across all recorded conversations and long-term memories. Use specific keywords for better results (e.g., "TypeScript preferences", "database decision").
Store important information in long-term memory for easy retrieval. WHEN TO USE - Call this when you identify: - User preferences (coding style, tools, communication preferences) - Important decisions (architecture choices, technology selections) - Key facts about user or their projects - Contact information or team details Categories: - preferences: User's personal preferences and working style - decisions: Important technical or project decisions - facts: Key information about user, projects, or context - contacts: People, teams, or organizations mentioned Long-term memories are searchable via memory_search.
Descriptions exceed 200 chars and bury key intent. 'memory_search' description is 380+ chars with WHEN-TO-USE guidance embedded in prose. LLMs parse the first 50-100 chars for intent, verbose descriptions waste tokens and obscure selection criteria.
No output schemas documented. Callers cannot predict response structure, field types, or pagination. memory_search likely returns results array but format is unspecified, LLMs must guess at field names.
No error handling or recovery guidance. Tools lack descriptions of failure modes (e.g., 'query too short', 'invalid date format', 'no results found'). LLMs receive raw errors with no actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
memory_search 'limit' parameter lacks bounds. Unbounded numeric parameters invite LLMs to pass absurd values (e.g., limit=999999) that degrade performance or exhaust resources. Should specify min/max (e.g., 1 - 100).
memory_record and memory_update_long_term lack idempotency guarantees. Agents retry on ambiguous failures, repeated calls with identical inputs could create duplicate memory entries. No deduplication or upsert semantics documented.