Loading ToolBench
A memory management system with MCP server integration, ChromaDB vector storage, and intelligent Gatekeeper agent for semantic memory search, save, update, and delete operations
The LLM Memory Bridge has 4 tools with basic structure but significant quality gaps. Tool names follow verb_noun convention (search_memory, save_memory, update_memory, delete_memory), which is positive. However, descriptions vary in quality and completeness. Input schemas are visible but lack depth, parameters have types but descriptions are sometimes vague or insufficient. A critical issue: save_memory description is entirely in Chinese, making it inaccessible to English-speaking LLMs. Error handling is minimal, with generic catch-all error messages that don't guide recovery. Response schemas are documented in prose within docstrings but not formalized. The server lacks tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having operations across the risk spectrum. Composition is reasonable (four focused tools), but save_memory's 'tags' parameter is marked 'Legacy parameter, ignored by Gatekeeper', a red flag for dead code and confusion.
Permanently delete a specific memory from the database by its ID. CRITICAL: You MUST use 'search_memory' first to find the exact 'memory_id'. Do not guess the ID. This operation cannot be undone.
智能保存记忆 (Smart Save). 只需提供原始文本，Server 端的 Gatekeeper AI 会自动进行： 1. 意图识别 (过滤无用闲聊) 2. 隐私检查 3. 自动摘要与打标签 4. 冲突检测 (如果是旧信息会自动转为更新)
Search for memories in the vector database using semantic similarity. This tool is best used when you need to recall facts, user preferences, or past project context. The 'query' can be a natural language question (e.g., "What is the project roadmap?") or keywords. Returns: A formatted string containing a list of relevant memories. Each memory includes: - ID: Unique identifier (crucial for deletion/update). - Time: Timestamp of creation. - Tags: Associated categories. - Content: The actual memory text.
Update an existing memory with new content or tags. Use this tool when you need to correct, refine, or update a specific memory found via `search_memory`. This maintains the cleanliness of the database by avoiding duplicates.
save_memory description is entirely in Chinese, making it inaccessible to English-speaking LLMs and violating the assumption that tool descriptions are readable by the calling model.
save_memory 'tags' parameter is marked 'Legacy parameter, ignored by Gatekeeper', this is dead code that confuses the LLM into thinking it has an effect when it doesn't.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels: search_memory is READ_ONLY, update_memory is REVERSIBLE, delete_memory is DESTRUCTIVE. LLMs cannot assess risk without explicit hints.
Input parameters lack format constraints (e.g., memory_id format, max content length, query string length limits). LLMs will pass arbitrary values, potentially causing downstream API failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schemas are documented only in prose within docstrings, not as formalized JSON Schema. LLMs cannot parse field types and will infer structure from examples, leading to parsing errors.
delete_memory lacks confirmation pattern. Irreversible destructive operations should support dry-run or explicit confirmation to prevent accidental data loss.
Error messages are generic ('Error: API returned status X', 'Error searching memory: str(e)'). They do not guide the LLM toward recovery, should include actionable next steps.
save_memory's 'force_save' and 'context' parameters are not documented for the LLM user. The server-side Gatekeeper behavior (intent recognition, privacy check, summarization, conflict detection) is invisible to the tool description.