Official Python SDK for Mnemoverse — persistent memory for AI agents. Sync and async REST client for the Mnemoverse Memory API.
Mnemoverse SDK exposes 7 well-structured tools with complete JSON schemas and descriptions. Tool names follow verb_noun convention (write, read, recent, feedback, stats, health). Descriptions are detailed and contextual, the read() tool includes 200+ chars explaining Hebbian expansion, temporal bounds, and ordering semantics. All parameters have type definitions and descriptions. However, descriptions occasionally exceed 1024 chars (read tool ~450 chars is acceptable; recent tool ~350 chars is good). Output schemas are documented in test fixtures but not explicitly in tool definitions. Error handling guidance is absent, tools do not indicate what to do on failure. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Security: no secrets exposed as parameters (good). Composition: tools are single-responsibility and chain well (write → read, feedback updates atoms). Naming is clear and consistent.
Update memory valence and importance based on user feedback.
Check the health status of the Mnemoverse service.
Query memory with semantic search + Hebbian expansion. ``since`` / ``until`` bound the result by creation time, inclusive at both ends; naive datetimes are read as UTC. ``order_by="recency"`` re-sorts the matched set newest-first without changing which entries matched. ``exclude_author`` drops one author principal — the "everyone but me" read in a shared room. For "what happened lately" rather than "what do I know about X", use :meth:`recent`: search returns what MATCHES, so entries that exist but do not match are absent — correctly, but invisibly.
List the newest entries first — no query, complete by construction. The temporal complement of :meth:`read`. Nothing is ranked away, so this is what to use when you need to be sure you are seeing everything: resuming after a break, catching up on a shared room, or auditing. Paged by cursor rather than truncated. When more entries exist the response carries ``next_cursor``; passing it back continues the listing with no skips and no duplicates even while writes are landing, which LIMIT/OFFSET cannot guarantee. An empty feed is a normal empty list.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot determine which tools are safe to retry or have side effects without explicit hints.
No error handling guidance in tool descriptions. Tools do not explain what to do on failure (e.g., 'If query returns no results, try broadening search terms or reducing min_relevance').
Output schemas documented only in test fixtures (DEFAULT_PAYLOADS), not in tool definitions. LLMs cannot see what fields to expect without reading test code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Get memory statistics and analytics.
Store a single memory atom.
Store up to 500 atoms in one request.
stats() and health() have minimal descriptions (65-70 chars). Descriptions should explain WHEN to call these tools and what they reveal (e.g., 'Call before write operations to verify service availability').
write_batch() accepts 'items' array but does not document per-item error handling. If 3 of 500 items fail, does the tool return partial results or fail entirely? Ambiguous behavior.