Loading ToolBench
Smart memory for AI agents. Memories decay, topics are frequency-weighted, one-time questions don't become obsessions. Solves the Karpathy memory problem.
mcp-memory provides 4 tools with explicit descriptions and input schemas visible in index.js. However, multiple definition quality gaps prevent a higher score: (1) Tool names are generic action verbs without clear nouns (remember, recall, forget, inspect), they don't follow verb_noun convention and lack specificity about what domain they operate on. (2) Parameter descriptions are present but minimal (20-50 chars); they lack detail about constraints, format, expected values, and error conditions. (3) Output schemas are NOT documented anywhere in the source, the code does not specify what fields are returned or what structure agents should expect. (4) Error handling is minimal; no recovery guidance or error categorization visible. (5) No parameter validation rules documented (e.g., no min/max for limit/min_relevance, no regex for id). The server implements interesting memory decay logic and auto-categorization, but the tool interface is under-specified for reliable LLM use.
Explicitly remove a memory
Debug view: all memories with decay status and scores
Retrieve memories (auto-reinforces matches, auto-prunes dead)
Store a memory (auto-categorizes, auto-deduplicates)
Tool names lack domain context and specificity. 'remember', 'recall', 'forget', 'inspect' are generic verbs that could apply to many domains. Should be 'remember_memory', 'recall_memories', 'forget_memory', 'inspect_memories' to signal this is a memory-specific tool suite. Current names force LLMs to read descriptions to understand scope.
No output schema documentation. Code does not declare what fields agents should expect from tool responses. For 'remember', does it return {id, content, category, tags}? For 'recall', is it {memories: [{...}], total_count, next_cursor}? Without this, agents cannot plan downstream operations or extract required fields reliably.
Parameter descriptions are too short (20-50 chars) and lack constraint documentation. E.g., 'limit' parameter has description 'Maximum number of memories to return (default 10)' but omits valid range (e.g., 1-100). 'min_relevance' lacks format detail (0.0-1.0?). 'category' lists 7 allowed values but doesn't mark them as an enum constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
forget tool (irreversible operation) has no confirmation or dry-run pattern. Agents can call forget with a memory ID with no validation, recovery hint, or undo mechanism. Critical operations should support a 'dry_run' parameter or explicit confirmation step per pattern:confirmation-request.
No error handling guidance visible. Code does not show what happens when: (a) memory not found by ID, (b) query returns 0 results, (c) invalid category supplied, (d) similarity dedup results in no insertion. LLMs need error messages that explain what went wrong and what to try next, per pattern:recovery-guide.
Input validation rules not documented. The 'category' parameter accepts one of 7 values (one-time, question, interest, preference, correction, fact, context) but this is not declared as an enum in the schema, it's only visible in the code comment. Agents cannot validate their input before calling.
The 'tags' parameter accepts 'string' type with description 'Optional comma-separated tags' but does not specify max length, max tag count, character restrictions, or format. LLMs may pass very long strings or special characters that break parsing.
Missing pagination parameters in recall. The 'limit' parameter is present (default 10) but no offset/page or cursor parameter documented. If agent repeatedly calls recall with same query, there's no way to paginate through all results beyond the first 10.