Loading ToolBench
Self-evolving memory system for AI agents with semantic search and knowledge graph capabilities. Includes MCP server for Claude and other AI assistants.
This server implements 8 memory-management tools with generally strong descriptions and well-structured Pydantic schemas. All tools have clear action verbs and descriptions exceeding 100 characters, positioning them well for LLM selection. However, several critical gaps prevent a higher score: (1) tool annotations (readOnlyHint, destructiveHint, idempotentHint) are completely absent despite many tools being read-only or destructive, this is a missed pattern opportunity for protocol readiness; (2) parameter validation and error handling descriptions are sparse; (3) output schemas are not formally documented in code, only inferred from tool logic; (4) some parameters lack constraints (e.g., `k` in search tools has no min/max bounds); (5) the `search_memories_by_time` tool's time format documentation is good but lacks validation guidance in parameter descriptions.
Save learnings to persistent memory. This builds cross-session knowledge. **SELF-COMMITMENT:** After exploring code or completing research, say: "I learned something new - saving to memory..." then IMMEDIATELY call this tool. This verbal commitment ensures you don't forget to save. **EXPLICIT TRIGGERS - Save memory when you just:** • Used Read tool to understand a file → save what you learned about it • Used Grep/Glob to find code patterns → save the pattern location • Fixed a bug or solved an error → save the solution • Discovered how components connect → save the architecture insight • Found configuration requirements → save them for next time **WHAT TO SAVE:** • Architecture: "Auth flow: JWT in cookie → AuthMiddleware → req.user" • Locations: "API routes defined in src/api/, use FastAPI" • Solutions: "ENOENT error? Run npm install first" • Patterns: "All components use React Query for data fetching" **SKIP SAVING when:** • Memory search already had the answer (nothing new learned) • Information is trivial or obvious • You only read a file without gaining reusable insight **ASYNC:** Returns immediately. Processing happens in background. ⚠️ **REMEMBER:** If you used search_memories at the start but then explored code to find the answer, you MUST save what you discovered.
Check the status of an asynchronous memory operation. **WHEN TO USE:** • After add_memory_note returns a task_id • To poll for background processing completion • To get detailed status and results of async operations **RETURNS:** Task status (pending, processing, completed, failed) with results or error details.
Delete incorrect or obsolete memories from the knowledge base. **WHEN TO DELETE:** • Memory contains completely wrong information that can't be fixed with update • Information is obsolete (e.g., "Feature X uses deprecated API Y" but Feature X was removed) • Duplicate memory that serves no purpose (prefer update_memory_note if consolidating) • Testing/placeholder memory created by accident **CAUTION:** Prefer update_memory_note over delete when information just needs correction. Only delete when the memory has no salvageable value. The memory system evolves connections automatically, so removing a memory may affect the knowledge graph.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic categories
No documented output schemas for any tool despite complex return structures
Search tool parameters lack bounds (k parameter unbounded)
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 26 | 1.0.0+ | v1 |
Read full details of one or more memories by ID. **WHEN TO USE:** • After search returns memory IDs - read full details to get complete context • To see evolution history showing how the memory has been refined over time • To view linked memories (related concepts the system connected automatically) • To check retrieval_count and last_accessed metadata **USAGE:** • Single read: provide `memory_id` - returns the note directly • Bulk read: provide `memory_ids` list - returns dict mapping each ID to its note **RETURNS:** Complete memory with content, keywords, tags, context, links, and evolution history. Use this as a follow-up to search_memories() when you need comprehensive details beyond the search preview.
CRITICAL: ALWAYS search persistent memory BEFORE starting work. This prevents re-discovering what you already know. **SELF-COMMITMENT:** When you receive a task, FIRST say: "Let me check my memory for relevant context..." then IMMEDIATELY call this tool. This verbal commitment ensures you don't skip the search. **EXPLICIT TRIGGERS - Search memory when:** • User asks "how does X work?" → search("X architecture") • User asks to fix/debug something → search("error X solution") • User asks about a file/component → search("component-name") • User asks to implement something → search("similar feature patterns") • You're about to use Grep/Glob/Read to explore → STOP, search memory first **SEARCH STRATEGY:** • Use specific terms: component names, tech stack, error messages, feature names • Try multiple searches if first yields no results (different keywords) • Search returns top-k most semantically similar memories from ALL past sessions **RETURNS:** Metadata only (id, context, keywords, tags, score) - NO full content. Use read_memory_note(memory_id) to get full content for relevant memories. ⚠️ **AFTER COMPLETING WORK:** If you explored code, read files, or discovered anything NEW beyond what memory returned, call add_memory_note() to save it. If memory already had the answer and no new exploration was needed, saving is not required.
Advanced memory search that follows the knowledge graph - returns semantically similar memories PLUS their linked neighbors. **WHEN TO USE THIS INSTEAD OF search_memories:** • Complex architectural questions spanning multiple components • Need to understand relationships between concepts • Simple search_memories gave limited results but you need more context **HOW IT WORKS:** 1. Finds semantically similar memories (like search_memories) 2. ALSO retrieves linked memories through the knowledge graph 3. Returns expanded result set showing knowledge clusters **RETURNS:** Metadata only (id, context, keywords, tags, timestamp, category, is_neighbor, score) - NO full content. Use read_memory_note(memory_id) to get full content. ⚠️ **AFTER COMPLETING WORK:** If you explored code or discovered anything NEW beyond what memory returned, call add_memory_note() to save it.
Search memories by time range, optionally combined with semantic query. **WHEN TO USE:** • Find memories from a specific time period ("what did I learn last week?") • Filter memories by date range before semantic search • Retrieve recent or old memories for temporal analysis **TIME FORMAT:** YYYYMMDDHHMM (e.g., 202501151430 = Jan 15, 2025 at 2:30 PM) **USAGE:** • Time range only: provide `time_from` and/or `time_to` • Time + semantic: add `query` to filter by both time AND semantic similarity • Results ordered by relevance score (if query provided) or time **RETURNS:** Metadata only - use read_memory_note(memory_id) for full content.
Update existing memory when you learn more or need to correct information. **USE THIS PROACTIVELY WHEN:** • You discover additional details about something already in memory (e.g., "I stored info about the auth flow, but now found it also handles rate limiting") • Initial understanding was incomplete or partially incorrect • You learn edge cases or exceptions to a previously stored pattern • Context changes (e.g., a dependency was updated, changing how something works) **IMPORTANT:** Keep memories accurate! Update rather than creating duplicate memories when you learn more about an existing topic. **WORKFLOW:** 1. Search for existing memory on a topic 2. If found and needs refinement, update it 3. If topic is different enough, create new memory with add_memory_note instead You can update: content, keywords, tags, or context. Other fields (timestamp, links) are managed automatically.
Time format validation not enforced in search_memories_by_time
Error handling and recovery guidance largely absent from descriptions
No documented pagination or result limits for search tools despite potential for large result sets