Mnemo MCP server

Read from the package source without running it. The installed server may list more.

• check_conflictwrite action

  WRITE-TIME conflict check (read-only, no LLM): BEFORE you remember() a fact, see whether it would CONTRADICT an existing memory — a value change on a managed `key`, or a numeric/negation clash with a similar memory. Returns the conflicting records (empty list = clean) so you can flag or gate the write instead of blindly trusting it. A pure duplicate does NOT flag; a contradiction that merely looks

• consolidatewrite action

  Run the consolidation 'dream' pass over ALL memories: flag universal-matcher 'hub' notes, link near-duplicates, and (if `keep` is given) supersede the lowest-value surplus. Includes the STATE-TOGGLE guard — a high-similarity pair that is a polarity clash (a preference flip) is superseded, not merged, so recall returns the new state. ADDS a derived layer only; never edits or deletes raw memories. R

• consolidate_clusters

  Cluster-TRIGGERED consolidation: consolidate a semantic cluster only once it has grown past `threshold` members — not a global blanket. Avoids prematurely consolidating sparse topics (raw episodes stay the best representation) and unbounded growth in dense ones. Cheap to call often (a no-op until a cluster is ripe). Returns clusters_total / clusters_fired / linked_pairs / ...

• contradictions

  Surface mutually-incompatible memories (related in content, opposite in polarity) for review. It FLAGS, never auto-resolves — silent rewrites destroy trust. Returns the conflicting pairs.

• credit

  Close the accuracy loop: when the work some recalled memories fed gets a real verdict — a forecast resolves, a claim is ruled correct/wrong, a plan succeeds/fails — call credit(those ids, outcome) so each memory's track record updates. Future `recall` then ranks by WAS-IT-RIGHT (a Beta good/bad posterior), not merely by being-recalled. `outcome`: 'good'/'right'/'correct' vs 'bad'/'wrong'/'failed'

• forget

  TRULY DELETE memories — the one op that removes content (everything else is append-only: supersession only demotes). Use for an erasure / right-to-be-forgotten request, a poisoned or false memory, or a hard correction. Pass `ids` (memory ids to drop) and/or `where_contains` (delete every memory whose text contains this substring, case-insensitive). Verified forgetting: the records are deleted AND

• forget_pii

  Erase detected PII — of the given `types` (default all), optionally scoped to a `subject`. Deletes the offending content deterministically (not an LLM guess). Returns what was erased.

• forget_subject

  Right-to-erasure by SUBJECT (GDPR Art.17 / DSR): delete every memory about `subject` AND scrub its id from survivors' links/supersession pointers, so it can't resurface via recall or consolidation. `basis` records the legal/operational reason. Returns a receipt (forgotten count, ids, scrubbed_links) you can keep as evidence.

• get

  Fetch ONE memory's FULL record by id (complete untruncated text + all fields). The companion to recall's progressive-disclosure default: recall returns compact snippets + ids cheaply; call get(id) only for the few memories you actually need in full, instead of paying to dump every full record into context. Returns {} if the id is unknown.

• governance_report

  One-call GOVERNANCE snapshot: erasure/retention posture, tamper-evidence status of the write chain, and integrity counters — the summary a DPO/CISO or auditor asks for. Deterministic, no LLM.

• index_coherence

  Does the derived semantic index agree with the store? Reports active text records missing a vector while an embedder is configured (index behind store), persisted-vector recipe vs the current embedder, and the persistence regime. A governed store can still serve stale answers through a lagging index — this is the deterministic check for exactly that. Read-only.

• influence_gate_report

  POISON / adversarial-integrity status: which memories are gated from influencing recall durability (self- asserted / uncorroborated / slashed) vs earned. The at-a-glance view of the store's poison-resistance state.

• neighbors

  Expand context AROUND a memory: the k memories most related to the one with `id` (compact snippets), by recalling on that memory's own text and excluding itself. Use it for on-demand local context after recall surfaces a relevant hit — a bounded expansion, not a whole-store dump. Returns [] if the id is unknown.

• observe

  READ-PATH review trigger — the mirror of a write-time hold-for-review. Feed it an OBSERVATION (evidence, NOT an authoritative write) that CONTRADICTS a settled memory: a different value for `key`, or object="" for a value-obscuring revert ("go back to what we had", names no value). Instead of silently trusting or ignoring it, this REOPENS that settled record for review — but only once the contradi

• pii_report

  What PII the store currently holds, by type (emails, phones, cards, …) — a data-minimization / audit view. Read-only; pair with forget_pii to act on it.

• recall

  Retrieve the top-k memories by RELEVANCE × accrued VALUE (not recency). Use this to load relevant prior knowledge before reasoning.

• remember

  Store a memory (append-only; raw text is never edited afterward). `tags` group memories into cohorts; `value` (>=1) is its importance — higher-value memories outrank merely-similar ones at recall, and recall itself nudges value up. `mtype` ∈ {episodic, semantic, procedural} sets the decay prior — episodic (events) fades fast, semantic (durable facts) slow, procedural (rules / preferences) barely;

• remember_decision

  Store a DECISION — the thing that actually matters and that a raw event/command log misses. Use this whenever you (or the user) CONCLUDE or CHOOSE something: "we decided X", "we're going with Y", "dropped Z", "the plan is W". Pass `because` (the rationale) and `context` (the situation) — they're kept for retrieval so a later recall answers "what did we decide, and why", not just "what commands ran

• reopened

  The POST-write review queue: settled records that observe() reopened because corroborated evidence contradicted them. Each entry shows the still-current value, why it reopened, and the prior value offered to reaffirm. Read-only; pass `key` to scope to one record.

• resolve_reopened

  Steward decision to close a reopened review. decision="keep_current" clears the flag (a false alarm, the current value stands); decision="reaffirm_prior" restores the surfaced prior value through the authorized revert path (it takes the revert `capability` when a revert authority is configured, so the content path cannot launder a restore). Returns {resolved, decision, key, ...}.

• revert

  Restore the PREVIOUS value for a supersession `key` — use this when the user asks to go back to the old value WITHOUT saying what it was ("go back to the old one", "undo that change", "the earlier setting was right"). The store's supersession ledger knows exactly what the current value replaced, so no value token is needed; the flip is written append-only and is itself a ledgered, attributable eve

• route

  ONE-CALL WRITE ROUTER: hand it any utterance and it decides the right ledger operation — a new fact is remembered, a marked correction supersedes, and a revert instruction ("go back to what we had", "restore the original") is resolved against the key's version timeline and executed through the sanctioned revert channel, WITHOUT the caller naming the old value. Use it when you don't want to pick be

• sleep

  SLEEP-TIME COMPUTE: call this whenever the agent is IDLE to run background memory maintenance in one cheap, idempotent pass — the expensive reorganization the write path defers. It consolidates any ripe near-duplicate clusters (dedup + preference-flip handling), and, if `keep` is given (or a capacity was configured), prunes/re-affirms the memory budget. A no-op until something is ripe, so it's saf

• supersession_report

  The correction ledger: which facts have been superseded/reverted, by key — the auditable 'what changed and what's current' view that an append-only-plus-supersession store can produce and a plain vector store cannot.

• token_report

  DETERMINISTIC payload-size estimate (no LLM, ~chars/4) for the SAME top-k recall: how much smaller the compact projection is than the full records for those same k hits. This is the honest, apples-to-apples comparison — compact vs full for identical results — NOT a comparison against dumping the whole store (that would be a strawman baseline that inflates with corpus size), and NOT a measured toke

• value_by_cohort

  Per-tag value rollup (count / total value / average). Reported at the cohort level on purpose: at n-of-1 a single memory's value is noise; the tag/time-block is where the signal is real.

• verify_witness

  Check a hydration witness against the store as it is NOW. digest_match=true means the store is still in the exact state the witness pinned; false means the answer that carried it predates a change (stale serve made visible instead of silent). Deterministic re-computation, no LLM.

• verify_writes

  TAMPER-EVIDENCE check: verify the hash-chained write ledger is intact (no silent edits/insertions/reordering). Returns {ok, problems} — ok=false with the offending ids if the chain doesn't verify.

• why_recalled

  EXPLAINABILITY: why did (or didn't) a memory surface for `query`? Returns the per-channel breakdown (relevance/value/provenance) for the top hits, or for a specific `id`. Deterministic — no LLM rationalization.

• witness

  HYDRATION WITNESS: a compact, deterministic receipt of the store state your answer was derived from — "this answer reflects store state as of revision X". Call it right after recall() and attach the result to the answer; any later write/supersession/revert/erasure changes the digest, and verify_witness() makes that visible. When write receipts are enabled it is anchored to the tamper-evident write

• Code scan20 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 0 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

92/100

higher than 90% of 4,460 AI and agents servers

Tools

30

the typical AI and agents server has 6

Tools that change things

7%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

7

more than 81% of 2,711 AI and agents servers

Downloads a week

698

more than 90% of 1,538 AI and agents servers with a package

Mnemo: common questions

Is Mnemo MCP server safe?

Yes, by our scan: it is graded A (92/100). Read the Mnemo safety report

How do I install Mnemo?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Mnemo need an API key?

No secret keys are declared. It reads 4 settings from the environment.

Is Mnemo maintained?

The last commit was 40 days ago (2026-09-25). The latest release is v1.24.2.

What can I use instead of Mnemo?

Servers from other publishers that do the same job: Agent Recall MCP server, Total Agent Memory MCP server and Basic Memory MCP server.

How does Mnemo compare with other AI and agents MCP servers?

safety score 92/100 (higher than 90% of 4,460 AI and agents servers); tools 30 (the typical AI and agents server has 6); tools that change things 7% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.