Loading ToolBench
A multi-layer memory management system for AI assistants with semantic indexing, raw content archival, and intelligent context retrieval. Serves as an MCP server for integration with Claude and other AI clients.
YuMem provides 14 well-named tools with mostly complete descriptions and schemas. Naming follows verb_noun conventions (get_, create_, update_, search_) and is action-oriented. All tools have descriptions ranging from ~60-200 chars, meeting the LLM-optimization baseline. Input schemas are present for all tools with proper JSON Schema types and descriptions. However, there are critical gaps in output schema documentation (no return type specifications visible), error handling guidance is absent, and some parameter validation rules are underdocumented. The three-layer memory abstraction (L0 user profile, L1 semantic index, L2 raw archive) is logically sound and well-named, but the tools lack security considerations (no permission gates documented), and output formatting/pagination guidelines are not evident. The server demonstrates solid foundational quality but lacks production-grade completeness in error recovery, security, and output shaping.
Add a file to the L2 raw content archive
Consolidate L0 data: deduplicate facts, mark expired, clean up
Create a new node in the L1 semantic index tree
Get summary and key information from a stored conversation by session ID
Get the user's core memory: identity traits, current focus, and preferences. Call this at the start of every conversation to understand who you're talking to.
Get the user's L0 profile context (facts about the user)
Get the actual content of an L2 entry by ID
Output schemas are not documented anywhere in the visible code. Tools return data but LLMs cannot know the structure in advance, forcing runtime discovery. This violates the 'Document the output schema' critical check and wastes tokens on exploration.
No error handling guidance is visible. Tools provide no actionable recovery instructions (e.g., 'User not found. Try search_users()' pattern). Agents receive failures without context on next steps.
No pagination parameters visible for list/search tools. retrieve_context accepts max_items (numeric) but search_l1 and search_l2 lack limit/offset/cursor support. Large result sets will bloat context windows without capacity to paginate.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Recall relevant memories using AI semantic search on the knowledge tree. Always includes user profile.
Intelligently retrieve assembled context from all memory layers
Search the L1 semantic index for relevant knowledge nodes
Search L2 raw content archive
Store a memory: conversation turn (with session_id) or standalone note. For conversations, content is appended to the same L2 entry per session. Analysis runs on end_session or every 10 turns.
Update the user's L0 profile (identity, name, context, preferences)
Update an existing L1 node's summary and keywords
No permission gates or scope declarations documented. Tools like update_l0, store_memory, and add_l2_file perform state mutations without visible authorization checks. No audit trail pattern evident.
Parameter validation rules are underdocumented. add_l2_file accepts 'path' (required, string) but does not specify file size limits, path traversal restrictions, or allowed file types. Agents can pass arbitrary paths without guidance.
Tool descriptions lack dependency hints and usage ordering. retrieve_context doc does not explain when to call this vs recall_memory. store_memory mentions session_id and end_session but does not clarify the conversation lifecycle or when analysis runs.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from irreversible writes without these hints. consolidate_l0 and store_memory have side effects but no annotation to signal this.
search_l1 and search_l2 lack enum constraints on filter parameters. search_l2 accepts open-ended 'tags' array; no documentation of valid tags or how to discover them. Agents will hallucinate tag values without guidance.