Loading ToolBench
MCP server providing semantic memory capabilities for Claude Code
This server has 13 tools with generally clear naming and adequate descriptions, but falls short of production-grade quality on several fronts. Tool names follow verb_noun conventions (create_memory, search_memory, delete_memory, etc.), which is excellent. However, output schemas are not documented anywhere in the provided code, only input schemas are visible. Parameter descriptions exist but lack critical constraint details (format, range, valid values). Error handling is minimal: no evidence of recovery guidance, error classification, or actionable error messages. The server uses STDIO transport, which is a hard cap at 50 for protocol readiness. Most tools score in the 60-70 range individually; the average reflects decent naming and schema presence but gaps in descriptions completeness and missing output documentation.
Store a new memory with semantic embedding for later retrieval
Create a relationship between two memories (parent-child, related, etc.)
Delete a memory by its ID
Delete a relationship between two memories
Delete a project and all its associated memories
Get the name of the currently active project
Build a graph of related memories starting from a root memory
Output schemas are not documented. Only input schemas are visible; no documentation of what fields or structure the agent should expect in responses. This forces LLMs to guess at response structure and increases hallucination risk.
Parameter descriptions lack constraint details. For example, 'threshold' in search_memory is described as 'Similarity threshold (0-1, default: 0.7)' but does not state whether 0 and 1 are inclusive, or what happens if an out-of-range value is passed. 'limit' and 'offset' parameters lack minimum/maximum bounds. 'metadataFilter' in list_memories is documented as 'JSON string of metadata filters' but does not specify the structure or valid keys.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Get all relationships for a specific memory
List all memories with optional pagination and sorting
List all available projects/namespaces
Search through stored memories using semantic similarity
Switch to a different project/namespace for memory storage
Update an existing memory content or metadata
No error handling guidance visible. The code shows tool registration but no evidence of try-catch blocks, validation, or error categorization. Destructive tools (delete_memory, delete_project, delete_memory_relation) lack confirmation or dry-run patterns. LLMs will have no guidance on retryability or recovery.
Sparse parameter descriptions on discovery tools. list_projects, get_current_project, and list_memories have minimal guidance on when to call them or what data they expose. Description text should include 'Call this first to discover available projects' or similar dependency hints.
Metadata parameters accept 'JSON string' but lack schema specification. 'metadata' in create_memory and update_memory, and 'metadataFilter' in list_memories are documented as strings but the actual JSON structure (keys, types) is not defined. This forces LLMs to guess or invent structures.
Ambiguity in tool naming for relations. 'get_memory_relations' and 'get_memory_graph' are similar, both retrieve relationships. The distinction (get_memory_relations returns direct relationships; get_memory_graph builds a traversed graph) is not clear from names alone. Descriptions should make this explicit to avoid LLM confusion.
No documented pagination or result limits for list_memories and get_memory_graph. list_memories defaults to limit=50 but no maximum is documented. get_memory_graph defaults depth=2 but no maximum is specified. Large result sets can blow the context window; limits should be documented and enforced.