Loading ToolBench
Persistent local memory MCP server for Claude Code, Codex CLI, Cursor and any MCP client: 74 tools — temporal knowledge graph, procedural memory, episodic memory, AST codebase ingest, pre-edit guard, auto-consolidating error capture
This MCP server provides 20 tools covering temporal memory management and self-reflection. While tool names follow verb-noun conventions well (memory_recall, memory_save, etc.), the implementation has critical gaps: (1) Input schemas are visible and properly typed, but several tools lack substantive descriptions (under 20 chars). (2) Output schemas are not documented anywhere in the provided source, the rubric requires documentation of what each tool returns for downstream chaining. (3) Parameter descriptions exist but are often minimal; many lack guidance on constraints, expected formats, or error recovery. (4) No evidence of error handling patterns or recovery guidance. (5) The server exposes two destructive operations (memory_delete, memory_forget) with no confirmation/dry-run pattern. (6) No documented permission gates or audit trails despite sensitive operations. This server is functional but significantly underdeveloped for production use by agentic systems that rely on structured schemas and error recovery.
Consolidate and deduplicate memories in the knowledge graph
Permanently delete a memory entry
Export memories to JSON or other formats
Extract and save observations from a session automatically
Forget/delete a memory entry
Get version history of a memory entry
Capture and queue an observation for auto-extraction
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields each tool returns. This violates the baseline that 100% of A+ tools have documented return types.
Destructive operations (memory_forget, memory_delete) lack confirmation or dry-run patterns. Agents can irreversibly delete memory without explicit user consent. No evidence of confirmation_request or recovery_guide patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Recall memories from the temporal knowledge graph with decay scoring and fuzzy search
Create relationships between memory entries in the knowledge graph
Save a memory entry with content, type, tags, and optional project/branch context
Search memories by tag
Get aggregate statistics about stored memories
Retrieve memories ordered by temporal proximity and decay scoring
Update an existing memory entry with new content or metadata
Log an error for self-improvement analysis
Extract insights from error patterns and experiences
Identify behavioral and coding patterns from memory
Generate self-reflection insights
Derive and store rules for future decision-making
Retrieve rules relevant to current context
Minimal parameter descriptions on tools like memory_stats, memory_consolidate, self_insight, self_patterns, self_reflect. Descriptions like 'Get aggregate statistics about stored memories' (57 chars) lack guidance on format, constraints, pagination, or error recovery.
No evidence of error handling patterns or recovery guidance. Code does not show how tools handle failures, invalid inputs, or how to guide LLM retry/fallback behavior. No actionable error messages visible.
No documented pagination support for list/search operations. memory_recall, memory_timeline, and memory_search_by_tag appear to return unbounded results with no limit, offset, or cursor parameters. Large result sets will exhaust context windows.
No security patterns evident. No permission gates, audit trails, or scope declarations for sensitive operations (memory_delete, memory_forget, self_rules). No evidence of rate limiting or input sanitization.
Tool composition issues: memory_forget and memory_delete appear to do the same thing (delete a memory) but with different names. This violates the pattern that duplicate tools confuse LLMs. Consolidate into one canonical delete_memory tool.
memory_observe and memory_extract_session have overlapping scope, both seem to queue/capture observations. No clear distinction in when to use one vs. the other. Tool naming and descriptions do not disambiguate.