Loading ToolBench
A secure, vector-based memory server for Claude Desktop using sqlite-vec and sentence-transformers. Stores and retrieves coding memories, experiences, and knowledge using 384-dimensional embeddings for semantic search.
This server has clear, well-structured tool definitions with consistent naming patterns and descriptions. All 6 tools start with action verbs (store_, search_, list_, get_, clear_, get_). Input schemas are visible and include parameter types and descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and some parameter constraints are underdocumented. The server follows basic tool pattern conventions but lacks production-grade error recovery guidance and comprehensive output schema specifications. Most parameters have descriptions, but several lack explicit constraints (min/max for numeric fields, enum validation for category). Error responses in the visible code return generic success/error dictionaries without actionable recovery guidance.
Clear old memories to free space (keeps frequently accessed).
Get specific memory by ID.
Get database statistics (total memories, categories, usage, health).
List recent memories in chronological order.
Search memories using semantic similarity (vector search).
Store coding memory with vector embedding for semantic search.
Missing output schema documentation for all tools. Only store_memory and search_memories have partial response structures visible in code (dict with success/error fields). No documented fields for list_recent_memories, get_memory_stats, get_by_memory_id return values. LLMs cannot predict response structure or plan downstream chaining.
Error handling lacks actionable recovery guidance. Visible error responses return generic {success: false, error: 'message'} without telling LLM what to try next. For example, get_by_memory_id will fail on invalid ID, but no guidance to call search_memories instead. Pattern requires: 'User not found. Try search_users() with a partial name.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Destructive operation (clear_old_memories) lacks confirmation/dry-run pattern. Agents make mistakes, this tool permanently deletes records with no confirmation step. Should support dry_run parameter returning what would be deleted, or require explicit confirmation.
Parameter constraints under-documented. 'category' parameter in store_memory lists enum values in description (code-solution, bug-fix, etc.) but not as formal enum schema. search_memories 'category' filter has no enum. limit parameters state ranges (1-50) but no explanation of what happens if user passes 0 or 100. Baseline: 100% of A+ tools formally constrain enums.
Output schema missing field details needed for tool chaining. If get_by_memory_id returns a memory object, response must include memory_id (for use in other tools), created_at (for UI), tags (for filtering), category (for context). Without documented fields, LLM cannot extract chaining references.
get_memory_stats description vague about return format. Says '(total memories, categories, usage, health)' but no structured output schema. Does 'categories' return a count per category, a list, or a dict? Is 'usage' disk usage, embedding cache, or query volume? Ambiguity forces LLM to guess.