verifiable-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VMEM_STATE | No | Path to the state file for verifiable memory (default: ~/.verifiable_memory) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| learn_factA | Store a fact (subject, relation, object) the agent must recall EXACTLY later, with its source. Call whenever the user states a fact, preference, decision, name, number, or rule worth remembering — it persists across sessions and is never silently distorted. Optional valid_from for valid-time. |
| recallA | Look up a stored fact and return the answer WITH its cited source — or an honest 'unknown'. ALWAYS call this before answering a factual or memory question instead of guessing: it returns nothing rather than hallucinating, and includes a signed, verifiable receipt. Optional as_of for valid-time. |
| update_factA | Update a fact's value without retraining: closes live versions (valid_to=t) and opens a new one. History is preserved. |
| historyB | Full life-line of a fact (all versions live+closed, with sources and valid-time). Audit/compliance. |
| forgetA | Permanently and PROVABLY delete a stored fact (GDPR / right-to-be-forgotten). Use when the user asks to forget or remove information — the fact is fully erased and you get a signed proof of deletion. object optional (omit to delete all values). |
| contradictionsA | Audit knowledge for conflicts: for functional relations (one value expected, e.g. 'capital','birthdate') return any (subject,relation) holding >1 live value, showing BOTH sources — call before trusting facts that may have been updated or come from multiple sources. |
| knowledge_rootA | Merkle root committing the entire current knowledge state (one hash). |
| prove_factA | Merkle inclusion proof that a fact is in the knowledge state (without revealing other facts). |
| verify_proofC | Verify a Merkle inclusion proof (leaf, proof, root). |
| verify_receiptA | Verify a signed receipt returned by recall/forget (tamper-evident). |
| multihopC | Multi-hop chain: start entity + list of relations, follows subject->object each step (exact only, 0% hallucination). |
| all_pathsC | All exact fact-paths between start and end entities (each path citable). |
| statsC | Counts + current knowledge root. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Every tool has a clearly distinct purpose: storing (learn_fact), recalling (recall), updating (update_fact), deleting (forget), auditing (history, contradictions), proving (prove_fact, verify_proof, verify_receipt), and traversing (multihop, all_paths). No two tools overlap in functionality.
All tool names use consistent snake_case with a verb_noun pattern (e.g., learn_fact, update_fact, prove_fact) or noun_verb (knowledge_root, verify_receipt). The naming is predictable and intuitive.
With 13 tools, the server covers the essential operations for a verifiable memory system without being excessive. Each tool justifies its existence by enabling a distinct workflow (CRUD, proofs, audits, traversal).
The tool surface is comprehensive: it includes create (learn_fact), read (recall, history, contradictions), update (update_fact), delete (forget), proof generation and verification (prove_fact, verify_proof, verify_receipt), multi-step traversal (multihop, all_paths), and state commitment (knowledge_root, stats). No obvious gaps.