Loading ToolBench
MCP server exposing memory operations (add, search, delete, count, pin, export, health) as tools over stdio for AI agents to interact with a hierarchical memory layer.
widemem exposes 7 tools with clear naming (verb-first: widemem_add, widemem_search, widemem_delete, widemem_count, widemem_pin, widemem_export, widemem_health). Naming follows the verb_noun pattern well. All tools have descriptions in the 70-180 character range. Input schemas are properly defined with JSON Schema structure (type, properties, required fields). However, parameter descriptions lack specificity around constraints, formats, and edge cases. No output schemas are documented, LLMs cannot reason about what fields will be returned. Error handling is not visible in the source; no recovery guidance. Security risk: user_id parameter is used for scoping but no clarification on whether it must be validated server-side or if it's a trusted input from the MCP client. The tool set is well-composed (single concern each: add, search, delete, count, pin, export, health check) but lacks idempotency guarantees and no mention of data loss or side-effect handling. Parameter type hints are present (string, integer) but descriptions are sparse on validation rules, defaults, and constraints.
Add a memory. The text is processed by the LLM to extract facts, resolve conflicts with existing memories, and store them.
Count stored memories, optionally filtered by user.
Delete a memory by its ID.
Export all stored memories as a JSON array, optionally filtered by user.
Health check — verify the widemem server is running and responsive.
Pin a critical fact with elevated importance (9.0). Use when the user explicitly asks to remember something, corrects a forgotten fact, or for YMYL (health, financial, legal) information.
Search memories by semantic similarity. Returns the most relevant memories ranked by similarity, importance, and recency.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract fields without knowing what the response structure is. widemem_search returns 'most relevant memories ranked by similarity' but the actual response schema is hidden.
Parameter descriptions lack validation rules and constraints. widemem_search accepts 'top_k' with 'default: 5, max: 100' in the description, but other numeric parameters (if any) may not have min/max bounds. No mention of what happens if invalid values are passed.
Destructive operations (widemem_delete, widemem_add with overwrites) lack confirmation/dry-run patterns or any guidance on how the LLM should handle accidental deletions. No mention of idempotency or retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Error handling strategy is not visible in source code. No recovery guidance, error categorization, or actionable error messages documented. If a memory_id is invalid in widemem_delete, what error is returned and how should the LLM respond?
user_id parameter is described as 'Optional user identifier to scope memories' but no clarity on whether this is a trusted value from the MCP client, whether it's validated, or if there are security implications of allowing an agent to specify arbitrary user_ids.
widemem_export returns 'all stored memories as a JSON array' but no pagination is mentioned. If there are 10,000 memories, will the response be enormous and risk context window exhaustion? No limit or pagination documented.
Tool composition is solid (single concern each) but widemem_add description says 'text is processed by the LLM to extract facts, resolve conflicts with existing memories', this indicates non-deterministic behavior. No mention of idempotency, retry safety, or whether duplicate calls with the same text will create duplicates.