Loading ToolBench
AI Agent lifelong memory system with 4-layer memory architecture, knowledge graph, and multimodal support
MindForge presents a well-structured memory system with 13 tools covering lifecycle operations (add, update, delete, search, list, export, import). Strengths: comprehensive input schemas with proper enums (importance, layer), good parameter descriptions including temporal constraints (valid_from, valid_to, bi-temporal), clear risk classifications. Weaknesses: tool descriptions are domain-specific but not optimized for LLM selection clarity (lack of WHEN to use guidance); output schemas are not documented in the provided code; error handling strategy not evident; one tool (memory_get) has source location pointing to JavaScript file (plugins/dsh/lib/index.js) suggesting multi-language inconsistency or missing source visibility. Average tool description length ~95 chars, below baseline 194 chars. Most descriptions read as feature summaries rather than agent-guidance narratives.
Add a new memory entry to MindForge lifelong memory system.
删除记忆（不可恢复）。
导出 JSON（最多 5000 条）或 CSV（最多 20000 条）。
按 ID 获取单条完整记忆。
批量导入记忆（JSON 数组格式，≤10000 条，v5.7.0）。
分页列出记忆（支持按分类/层级/重要性过滤，v5.7.6）。
Hybrid search: vector recall + TF-IDF + fuzzy (v5.4.5). Set use_embedding=false to disable vector search.
标星/取消标星记忆（快速访问）。
Tool descriptions lack LLM selection guidance. Most descriptions state WHAT the tool does but not WHEN an LLM should choose this tool over alternatives. For example, memory_search and memory_list both retrieve memories but are not disambiguated for the agent. memory_list is pagination-oriented, memory_search is content-based, but this distinction is not explicit in descriptions.
Output schemas not documented. No evidence in provided source code of documented return types for any tool. LLMs need to know what fields are returned (e.g., does memory_search return id, content, relevance_score, created_at?). This forces the agent to infer structure from trial calls or hallucinate field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
统计：总数、按重要性/层级/分类分布、top 标签、DB 大小。
Bi-temporal 事实取代（v5.7.6）：关闭旧事实有效窗口并创建新事实，旧版本保留在历史中。
列出所有标签及用法计数（前 100 个）。
更新记忆：内容、分类、标签、重要性、层级。
按事实有效时间查询（Bi-temporal as-of，v5.7.6）：返回 timestamp 时处于有效窗口的记忆。
memory_get tool definition source location inconsistent. Listed as 'plugins/dsh/lib/index.js' (JavaScript) while all other tools reference 'mcp/server.py' (Python). Suggests either source visibility gap or multi-language implementation mismatch. Code review cannot verify memory_get's actual schema implementation.
Error handling strategy not evident from provided code. No visible error responses, recovery guidance, or error categorization (retryable vs. fatal). For destructive operations like memory_delete, no confirmation or dry-run pattern documented. This violates recovery-guide and confirmation-request patterns.
Descriptions average ~95 chars, well below baseline 194 chars. Most lack prerequisites, dependency hints, or context for multi-step planning. E.g., memory_supersede does not explain why an agent would use it instead of delete+add, or that it preserves audit history.
No explicit permission gating or access control logic visible. Tools like memory_list and memory_search accept optional 'actor' and 'agent_id' parameters for privacy filtering, but no documentation of how access is enforced or what happens when a user lacks permission. Audit trail logging not evident.
No idempotence guarantees documented. For operations like memory_add and memory_import, repeated calls with identical input could create duplicates. LLMs retry on ambiguous failures, non-idempotent tools risk side effects. Pattern requires idempotent-operation design.