Loading ToolBench
MCP-first learning memory layer for Claude, Cursor, and agent workflows
SuperMemory defines 23 tools with explicit schemas and descriptions visible in server.py. All tools have non-empty descriptions (10-200 chars, within baseline range). Input schemas are present with typed properties and required fields. However, critical gaps reduce quality: (1) Many parameter descriptions are generic or minimal (e.g., 'Workflow identifier', 'Agent identifier') without actionable constraints or format guidance. (2) Output schemas are NOT documented, no return type specifications visible for any tool, violating pattern:tool and mxe:strip-api-responses. (3) Tool naming shows inconsistency: 'record_event', 'record_failure', 'record_correction' are clear, but 'learn.run.start', 'learn.run.event', 'learn.run.end' use dot notation (non-standard verb_noun) and lack clarity on what 'run' means. (4) No error handling guidance in descriptions, tools do not explain recovery paths or retryability. (5) Composition issues: 'reflect' and 'learn.reflect' appear to duplicate functionality; 'validate' and 'learn.validate' do the same. (6) Parameter relationships undocumented (e.g., when is 'reflection_id' vs 'candidate_lesson' required in validate?). Baseline: 549 production tools average 18-char names, 194-char descriptions, 100% with return types documented. SuperMemory falls short on output documentation and parameter clarity.
Add a local policy rule.
Add a reusable skill/workflow block.
Return active policies visible to a namespace.
Read a reusable skill by ID.
Get analytics for the learning system
Get improvement recommendations for a workflow
Get active policies for a namespace
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., what does retrieve() return? Does it include lesson_id for report_outcome?). Violates pattern:tool and mxe:strip-api-responses.
Duplicate tool pairs with unclear distinction: reflect vs learn.reflect, validate vs learn.validate, retrieve vs learn.retrieve. Naming convention inconsistency (dot notation vs verb_noun) and overlapping functionality force LLM to guess which to call. Violates pattern:tool and review:name-clarity.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Create a lesson from failure/correction events
Retrieve lessons for a workflow step
End a UALL run and record final metrics
Record a selective event (failure, correction, suggestion, workflow_step)
Start a UALL run with workflow and step metadata
Report lesson usage telemetry
Validate and queue a lesson for promotion
Process pending validated lessons and promote passing items.
Record a bounded correction signal.
Record a bounded significant event. Full transcripts should not be sent here.
Record a bounded failure signal.
Create a candidate lesson from evidence events.
Report telemetry for a retrieved lesson.
Retrieve policy-first, stage-aware lessons.
Search reusable skills visible to a namespace.
Validate a lesson candidate and enqueue approved lessons for promotion.
Dot-notation tool names (learn.run.start, learn.run.event, learn.run.end) deviate from standard verb_noun convention. Non-standard naming reduces LLM's ability to parse intent from name alone and conflicts with MCP tool naming best practices.
Parameter descriptions lack actionable constraints. Examples: 'Workflow identifier' (what format?), 'Agent identifier' (string, UUID, email?), 'Namespace' (max length? allowed chars?). Baseline: 72-char avg param description with format/range guidance. SuperMemory averages ~30 chars with minimal detail. Violates pattern:constrained-input.
No error handling guidance in tool descriptions. Tools do not explain retryability, recovery paths, or what to do on failure. Violates pattern:recovery-guide and pattern:error-classification.