Local-first memory engine for AI agents, with a hash-chained ledger that explains every retrieval.
memvault demonstrates solid tool design with clear verb-based naming (write, search, get, supersede, forget, explain, as_of) and comprehensive parameter schemas. All 7 tools have descriptions and typed input schemas with parameter descriptions. However, output schemas are not documented in the visible code, and some descriptions lack actionable detail for LLM selection. Error handling guidance is minimal. The domain (temporal fact storage with cryptographic erasure) is specialized and well-scoped, but descriptions could better explain WHEN to use each tool vs alternatives.
Point-in-time query: what was true, or what was believed true, as of a given moment. Omitting either bound means 'now' on that axis.
Reconstruct a past retrieval from the ledger by its id, showing every candidate considered and its scoring.
Cryptographically erase a fact: destroy its key so its content is permanently unreadable, everywhere, forever. The ledger record stays -- only its content becomes unrecoverable.
Read one fact's current version by id.
Hybrid search with full provenance for every candidate considered, combining ANN vector search, BM25 keyword search, and RRF ranking with decay and budget constraints.
Close a fact's open interval without asserting a replacement, optionally with a reason.
Assert a fact into the memory store with optional embedding, keywords, and temporal validity bounds.
Output schemas not documented. Tools return results but LLMs cannot see what fields to expect, forcing them to guess downstream field names and breaking tool chaining.
Descriptions lack WHEN-to-use guidance. 'search' and 'explain' both retrieve facts, but descriptions don't clarify when to call explain vs search, forcing LLM to reason about intent.
No error recovery guidance. Tools document what they do but not what to do if they fail (e.g., if 'forget' is called on a non-existent fact_id, what happens? Can the agent retry?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
Temporal parameters (valid_from, valid_to, valid_time, transaction_time) use RFC 3339 but descriptions don't explain the difference between valid_time and transaction_time axes or when to omit them.
No pagination or result limits documented. 'search' accepts k and max_tokens but doesn't explain what happens if results exceed max_tokens or how to paginate large result sets.