Loading ToolBench
Perfect recall for imperfect machines. A shared memory MCP server for LLMs.
Mnem-O-matic demonstrates solid definition quality with 15 well-named tools following verb_noun conventions (store_*, search, read, list_*, delete_*, restore). All tools have substantive descriptions (100-400+ chars, well above the 10-char minimum). Input schemas are present and typed for all tools. However, several tools lack output schema documentation, and error handling guidance is minimal. Tool descriptions are thorough but could be more concise for LLM parsing efficiency. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk classifications.
Mechanical consolidation candidates for a namespace: near-duplicate clusters and stale items. The report is read-only; use the delete and update tools to act on it.
Delete all items in a namespace. Removes every document, knowledge entry, and note in the given namespace in a single atomic operation. Each item's final state is kept as a revision, so individual items can be recovered via list_revisions + restore — but there is no one-call undo for the whole namespace, so treat this as destructive. If you only want to reorganize content, use rename_namespace instead.
Report which embedding model is in use, and whether it matches the index. Use this when semantic search returns odd results, before reading much into a similarity score, or to check whether semantic search is available at all. Search only works when the model embedding your query is the one that embedded the stored content — query a model against another model's vectors and the results come back plausible but wrong, with no error.
The full timeline of a fact: the current entry first, then every superseded version, newest first. Knowledge is temporal — when a fact changes (via store_knowledge or update_knowledge), the old entry is closed rather than overwritten. Use this to answer "what did we believe before?" or to audit when an answer changed: each superseded entry carries valid_until (when it stopped being current) and superseded_by (the id of its replacement). History entries are read-only; only the current entry can be updated or superseded.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. Tools like delete_namespace and store_* should declare their mutability to guide agent planning.
Output schemas not documented in tool definitions. Agents cannot infer response structure (e.g., what fields search() returns, pagination format for list_items). Requires reading implementation code.
Error handling descriptions missing. Tools do not explain recovery paths (e.g., what to do if embedding_info shows model mismatch, or if search fails due to unavailable embedder). Agents cannot self-correct.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Health check endpoint. Returns server status and configuration.
List the audit trail — one event per write operation, newest first. Use this to review recent activity ("what changed in this namespace and when?"), trace what happened to a specific item, or see where a change came from. Complements revisions: revisions hold the content an item had (for restore), the audit log holds the events (who did what, when). Each event carries: ts, op (store/update/supersede/delete/tag/restore/ rename_namespace/delete_namespace, plus reindex when the whole store was re-embedded), item_type/item_id/namespace/title, actor (the client's self-declared X-Mnemomatic-Actor header, if any), client (user-agent), ip, and op-specific detail. With a shared API key the actor is self-reported, not authenticated.
List items of one type in a namespace, newest first, with pagination. Use this to browse or inventory a namespace — e.g. reviewing what's stored, finding stale entries, or walking a large namespace page by page. For finding content by topic, prefer the search tool. Results are summaries (id, title/subject, tags, updated_at, ...) without document/note bodies; use the read tool to fetch an item's full content. The response's `total` is the overall item count, so `offset + len(items) < total` means there are more pages.
List saved revisions — prior versions of items captured on every update and delete. Use this to find a version to roll back to (then call the restore tool with the revision's id), to recover something deleted by mistake, or to review what recently changed in a namespace. Filters combine; with no filters the newest revisions across the whole store are returned. Each revision is a summary (revision id, item_type, item_id, namespace, title/subject, op, revised_at) — op is "update" (the item changed after this state was saved) or "delete" (the item was deleted). The server keeps a limited number of revisions per item; older ones are pruned.
Read the full content of a document, knowledge entry, or note by ID. Use this after searching to retrieve complete content — search results only contain a snippet. The item's resource_uri field tells you the type and ID.
Find items most similar to an existing item — "more like this". Use after reading an item to discover connected context without crafting a search query: related decisions around a document, notes touching the same topic as a fact. Results span all content types, ranked by embedding similarity to the given item. Requires semantic search (an embedder); works for chunked documents via their chunk-vector centroid. The item itself is never returned.
Rename a namespace across all documents, knowledge entries, and notes. Moves every item in old_namespace to new_namespace atomically. If new_namespace already exists this acts as a merge: on a title/subject collision the moved item replaces the target's item (the same upsert semantics as the store tools). Check `replaced` in the response to see how many target items were overwritten.
Restore an item to a saved revision — undo an update or recover a deleted item. Find the revision id with the list_revisions tool first. If the item still exists, its content is rolled back to the revision's state (the current state is saved as a new revision first, so a restore can itself be undone). If the item was deleted, it is recreated with its original id. Restoring re-embeds the content, so search reflects the restored state immediately.
Search across documents, knowledge, and notes in Mnem-O-matic. Always search before storing — Mnem-O-matic may already contain what you're looking for, and searching first avoids creating duplicates. Also search at the start of a session to load relevant context before answering questions or starting work. Search modes: - "hybrid" (default): Combines keyword and semantic search using Reciprocal Rank Fusion. Best general-purpose choice — catches both exact matches and conceptually related content. Falls back to fulltext if embedder is unavailable (will include "_metadata" in response). - "fulltext": Keyword and phrase matching. Use when searching for a specific term, name, or exact phrase. Faster but misses synonyms and paraphrased content. - "semantic": Embedding-based similarity search. Use when the query is a concept or question and the stored content may use different words. E.g. "authentication" finds "JWT login tokens". Returns error if embedder is unavailable.
Store a document in Mnem-O-matic's shared memory. Use for structured, long-form reference material: code files, specs, configs, architecture docs, runbooks, README content, API schemas, or any content with a clear title that other sessions should be able to retrieve and read in full. Prefer documents over knowledge when the content is multi-line or prose-form. Prefer documents over notes when the content is structured and reusable rather than a passing thought. Uses upsert semantics: if a document with the same namespace + title already exists, it is updated in place. Check `created` in the response to distinguish a new entry (true) from an update (false). When the new content is nearly identical to items already in the namespace, the response includes `similar` (id, title, score) — review those before creating another near-duplicate.
Store a knowledge entry (a discrete fact or decision) in Mnem-O-matic. Use for atomic, self-contained facts: architectural decisions, technology choices, conventions, constraints, or observations that can be expressed in one or two sentences. Prefer knowledge over documents when the content is a single fact rather than long-form material. Prefer knowledge over notes when the content is a confirmed fact rather than a tentative idea or rough thought. Good subjects: "auth mechanism", "database choice", "deploy pipeline", "rate limit policy" Good facts: "Uses JWT with RS256 signing", "Postgres, not MySQL — chosen for JSONB support" Uses temporal upsert semantics on namespace + subject: storing the same fact again refreshes the entry in place, while storing a *different* fact for an existing subject supersedes it — the old fact is kept as queryable history (see the fact_history tool) and the response carries its id in `superseded`. When the new content is nearly identical to items already in the namespace, the response includes `similar` (id, title, score) — review those before creating another near-duplicate.
consolidation_report description is vague ('Mechanical consolidation candidates'). Does not explain what 'near-duplicate clusters' means, how similarity_threshold is used, or what 'stale' means operationally.
Parameter descriptions in search() and list_items() could specify valid ranges more explicitly. E.g., limit defaults to 10 (max 100) but this is buried in description text, not a formal constraint.