Loading ToolBench
轻量级 MCP Server，为 AI 编程助手提供跨会话持久记忆能力 (Lightweight MCP Server providing cross-session persistent memory for AI programming assistants)
AIVectorMemory exhibits critical quality gaps across naming, descriptions, schema clarity, and error handling. While tool schemas ARE present with typed parameters, most descriptions are short (20-50 chars) or in Chinese only, descriptions lack clarity on WHEN to use each tool and what distinguishes them, and parameter naming is inconsistent. The server mixes single-responsibility tools (remember, recall, forget) with mega-tools (track, task) that bundle multiple actions under 'action' enums, violating single-concern principle. No evidence of error recovery guidance, input validation constraints, or permission gates. Schemas present but sparse in documentation. No tool annotations (readOnlyHint, destructiveHint) despite having READ, WRITE, and DESTRUCTIVE tools with clear risk profiles.
自动保存偏好 (Save user preferences for auto-save)
删除记忆 (Delete memory by ID or batch)
README生成 (Generate README with customizable sections)
语义搜索 (Semantic search for memories by query)
存入记忆 (Store memory with content, tags, and scope)
会话状态 (Get or update session status)
任务管理 (Task management: create, update, list, delete, and archive tasks)
Mega-tools that bundle multiple operations under 'action' enums (track, task, status) violate single-responsibility principle. Each action should be a separate tool (create_issue, update_issue, list_issues, etc.) so agents can compose and retry atomically.
Tool descriptions are predominantly in Chinese (with English translations in parentheses) and too short (<50 chars). LLM-optimized descriptions should be 50 - 200 chars in English, state WHAT/WHEN/WHY, and disambiguate from similar tools (e.g., remember vs recall). Current descriptions lack this depth and are not LLM-friendly.
No input validation constraints documented. Parameters like 'top_k' lack min/max bounds, 'content' has no max length, 'tags' array has no size limits. This invites hallucinated invalid values from LLMs. Add explicit ranges and patterns to descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | 2024-11-05+ | v1 |
问题跟踪 (Issue tracking: create, update, list, and archive issues)
Parameter dependencies are undocumented. E.g., in 'status' and 'task', some params are required only for specific action values. In 'forget', 'memory_id' and 'memory_ids' are mutually exclusive but not stated. LLMs will pass both, causing ambiguity.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools marked DESTRUCTIVE (forget) or WRITE (remember, status, track, task, auto_save) lack explicit annotations in schema, forcing LLMs to infer safety from descriptions alone. Add annotations per MCP spec.
Output schemas are not documented. LLMs cannot plan downstream tool calls or know what fields to extract. E.g., what does 'recall' return (memory objects with id/content/score)? What does 'task' batch_create return (array of task IDs or full task objects)? Document all return structures.
No error recovery guidance. Tools marked DESTRUCTIVE (forget) or with complex logic (recall, task) lack error messages that tell the LLM what to do next. E.g., 'Memory not found, try recall() first to find matching memories.' Implement recovery patterns.
Generic/vague tool names reduce clarity. 'status' (should specify what status), 'track' (should be 'manage_issue' or 'create_issue'), 'task' (verb missing), 'readme' (should be 'generate_readme'). Verb_noun naming lets LLMs infer intent from the name alone.
Parameters with array/object types lack element/property schemas. E.g., 'tags' (array of what?), 'preferences' (array of what objects?), 'state' (object with what fields?). LLMs cannot know what to pass. Add nested JSON Schema definitions.