Loading ToolBench
Personal memory as files — fast retrieval, higher accuracy, lower cost. Embedding-only memory service exposing progressive retrieval, file listing, and commit operations over a pluggable store.
memU is a STDIO-only MCP server with 3 tools focused on memory retrieval and storage. While tool names follow verb-noun conventions and descriptions are present, the implementation has significant gaps in schema completeness, parameter documentation, and error handling guidance. Input schemas are visible but lack comprehensive parameter descriptions, and output schemas are not documented. The server is designed as a memory backend for agents but lacks patterns for idempotency, pagination clarity, and error recovery guidance that production memory systems require.
Commit one prepared developer run and clear its ephemeral artifacts. Writes recall files and resources to the store after vectorizing them.
List one keyset page of RecallFiles across every track. No track filter is forced, so skill-track files are included alongside memory-track ones. The page is ordered by (track, name, id) and returned with next_cursor; a None next_cursor marks the last page.
Single-shot, LLM-free retrieval over the segment/file/resource layers. The query is embedded once and used to rank two layers by vector similarity. Returns segments, files, and resources ranked by embedding similarity.
Output schemas not documented. LLMs cannot determine what fields to expect in responses, breaking downstream tool composition and forcing guesswork about pagination continuation.
Parameter descriptions missing or insufficient. 'where' parameter in list_all_recall_files and progressive_retrieve documented as 'Optional scope filters as a dict' but no explanation of valid filter keys, types, or examples. LLMs cannot construct valid filter objects.
Pagination implementation ambiguous. list_all_recall_files mentions 'next_cursor' and 'None marks last page' but does not specify: (1) cursor format/opacity, (2) whether cursor is required for page 2+, (3) what 'limit' default of 50 implies for large datasets. Agents cannot reliably paginate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
commit_results lacks error handling guidance. Description does not specify: (1) what happens if vectorization fails, (2) whether partial commits are possible, (3) how to recover from mid-operation failures. Agents cannot intelligently retry.
commit_results (WRITE operation) lacks idempotency or confirmation pattern. Description does not indicate whether duplicate calls produce duplicate data, and no mention of dry-run or confirmation step. Agents cannot safely retry after transient failures.
progressive_retrieve parameters lack constraints. 'query' accepts free-form string with no length limit, embedding model specification, or vector dimension guidance. What query length causes embedding failure? How are embeddings chosen?
Array parameter type mismatch in commit_results. 'resource' parameter documented as array but in description says 'List of resource objects', unclear if this is a list of one or many, and no schema for individual resource object provided.
Tool composition broken. If progressive_retrieve returns file/resource IDs, do they match the format expected by commit_results? If list_all_recall_files returns 'id' field, can it be passed to downstream operations? No documentation of field consistency.