Loading ToolBench
An agentic memory system for LLM agents based on the Zettelkasten principle. Provides tools for atomic note creation, semantic memory retrieval, graph-based knowledge management, and automated memory maintenance through comprehensive enzymes.
A-MEM MCP server demonstrates reasonable tool naming and schema structure but suffers from critical gaps in parameter descriptions, output schema documentation, and error handling guidance. 14 tools are defined with consistent verb-noun naming (create_, retrieve_, get_, list_, add_, delete_, update_, run_), but descriptions vary widely in clarity and completeness. Most tools lack documented return types, and parameter descriptions are inconsistent, some parameters have helpful detail while others are bare. The server includes destructive operations (reset_memory, delete_atomic_note) and data-modifying operations (create_atomic_note, add_file) without confirmation/dry-run patterns or explicit permission checks. Error handling is not evident in tool definitions. Pagination is not implemented for list_ tools (list_notes, list_relations return unbounded results). Security-critical tools like reset_memory lack confirmation patterns.
Stores the content of a file (e.g., .md) as a note in the memory system. Supports automatic chunking for large files (>16KB). Note: Requires an absolute path or the file must be in the server directory.
Adds a manual relation between two notes.
Stores a new piece of information in the memory system. Automatically classifies the note type (rule, procedure, concept, tool, reference, integration), extracts metadata, and starts the linking and evolution process in the background.
Deletes a note from the memory system. Removes the note from Graph and Vector Store as well as all associated connections.
Returns the full graph snapshot (nodes + edges). Optionally saves the graph to disk for visualization tools.
Returns statistics about the memory system (number of nodes, edges, etc.).
Critical: No documented return/output schemas for any tool. LLMs cannot plan downstream operations or extract required fields from responses. Pattern:response-shaper requires structured output documentation.
Critical: Destructive/irreversible operations (reset_memory, delete_atomic_note) lack confirmation/dry-run patterns. Agents cannot be safely deployed when destructive tools offer no confirmation gate. Pattern:confirmation-request required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Returns a single note (metadata + content) by id.
Lists all stored notes from the memory graph.
Lists relations in the memory graph, optionally filtered by note id.
Removes a relation between two notes.
Resets the complete memory system (Graph + Vector Store). Deletes all notes, edges, and embeddings. WARNING: This action cannot be undone!
Searches for relevant memories based on semantic similarity with priority scoring. Returns the best matches with linked contexts, ranked by combined similarity and priority score.
Runs comprehensive memory maintenance enzymes: repairs corrupted nodes, prunes old/weak links and zombie nodes, validates and corrects note types/keywords/tags, refines duplicate summaries, suggests new relations, links isolated nodes, digests overcrowded nodes, performs temporal cleanup (archives old notes), calculates graph health score, and detects dead-end nodes. Automatically optimizes the entire graph structure.
Updates contextual summary, tags or keywords for an existing note.
High: List tools (list_notes, list_relations) have no pagination parameters (limit, offset, cursor) and no indication of result capping. Returning unbounded result sets will exhaust context windows. Pattern:paginated-result and mxe:enforce-result-limits required.
High: Parameter descriptions are inconsistent and often minimal. Tools like list_notes, update_note, delete_atomic_note, add_relation, remove_relation have descriptions under 20 characters or lack parameter-level detail. LLMs cannot infer parameter meaning from names alone. Pattern:tool-description requires 10-1024 character descriptions for each parameter.
High: No error handling or recovery guidance in tool definitions. Pattern:recovery-guide requires tool descriptions to tell LLMs what to do if a call fails (retry, ask user, fallback action). No error classification (retryable vs user-fixable vs fatal).
Medium: Tool descriptions vary from 30 characters (get_memory_stats, list_notes) to 300+ (run_memory_enzymes). Short descriptions lack actionable context. Baseline for A+ tools is 50-200 chars. Descriptions like 'Returns statistics about the memory system (number of nodes, edges, etc.)' and 'Lists all stored notes from the memory graph.' are too terse and lack WHEN/WHY context.
Medium: update_note parameter 'data' is a generic object type with no schema for allowed fields. Description says 'Fields to update (contextual_summary, tags, keywords)' but does not define the structure, types, or constraints for each field. Pattern:constrained-input requires enum-style constraints or explicit field definitions.
Medium: add_file tool requires either file_path or file_content but schema shows both as non-required. If both are optional, the tool may fail silently when neither is provided. Parameter requirements and dependencies must be explicit and validated early with clear error messages.
Medium: No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. MCP spec (2026-07-28) supports per-tool annotations to help LLMs reason about side effects and safe retry behavior. List tools should have readOnlyHint=true; destructive tools should have destructiveHint=true.
Low: File path handling in add_file notes 'Requires an absolute path or the file must be in the server directory.' This is a security/path-traversal concern. No mention of path validation or sandboxing. Pattern:tool-gateway requires input sanitization and path traversal defense.