Loading ToolBench
Multimodal Memory for AI Agents and MCP - provides persistent memory management for multimodal data (text, images, audio, video, documents) with semantic search capabilities
The PixelMemory MCP server exposes a single tool 'manage_tasks' with severe structural and documentation deficiencies. The tool name violates fundamental naming patterns (combines multiple concerns: add, list, update, complete via a single action parameter), the description is generic and lacks specificity about when/why to use it, and parameter descriptions are incomplete. The schema includes optional parameters without clear indication of which combinations are valid, and there is no documented output structure. Error handling is not evident. This server would not pass code review against production standards.
Manages a persistent to-do list for the development project.
Tool name 'manage_tasks' is a generic, non-verb action that violates verb_noun naming convention. The name does not convey what the tool does (add, list, update, or complete task?). Single tool conflates four distinct operations (add/list/update/complete) that should be separate tools: create_task, list_tasks, update_task, complete_task. This forces the LLM to guess which action to invoke and increases reasoning overhead.
Tool description 'Manages a persistent to-do list for the development project' is 60 characters, within acceptable range but lacks specificity. It does not explain: WHAT data is persisted? WHEN should the agent use each action (add vs update)? WHAT is returned? It does not document that this is a stateful tool or what the prerequisites are. Description should explain the four sub-operations and when each is invoked.
Parameter 'action' has type string with description 'The action to perform: add, list, update, or complete' but is NOT declared as an enum. Free-form string invites LLM to hallucinate invalid actions (e.g. 'delete', 'archive'). Should be: {"type": "string", "enum": ["add", "list", "update", "complete"]}.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Parameter dependency documentation is missing. The schema marks 'task_description' as required=false but notes '(required for add action)'. Similarly, 'task_id' is required for update/complete but optional for add/list. These conditional dependencies are NOT documented in descriptions and force the LLM to infer logic. Each parameter description should state: 'Required only when action=...'
No output schema documented. The tool accepts list/update/add/complete but returns nothing visible in the definition. What does list return? Is it an array of tasks? What fields per task (id, description, status, created_at)? What does update return (confirmation or the updated task)? LLM cannot plan downstream calls or extract data without knowing the response structure.
No error handling guidance. The tool does not document: What happens if task_id is invalid? What if add fails due to duplicate description? What if update tries to set an invalid status? LLM has no recovery path and cannot self-correct.
Parameter 'status' (for update action) lacks description specifying valid values. Is it 'pending', 'in_progress', 'done'? Are there other valid statuses? Undocumented enums force LLM to guess or cause invalid input errors.
The tool is marked Risk: WRITE but does not implement or document a confirmation/dry-run pattern. For irreversible operations (complete, update), best practice is to offer a confirm step to prevent accidental task deletion or status changes. Current design allows agent to silently complete wrong task.