Remembra
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REMEMBRA_HOME | No | Override the storage directory (default ~/.remembra) | |
| REMEMBRA_API_KEY | No | Optional API key for HTTP mode authentication |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_storeB | Persist a fact, decision, role or history entry so it survives context window resets. Use type 'fact' for stable knowledge, 'decision' for choices already made, 'role' for standing instructions/roles, 'history' for condensed chronology of past work. |
| memory_batchA | Run a bounded store, update, delete, or selected export batch. Items are validated before writes; operational failures are returned per item and are not a transaction. |
| memory_digestA | Extract facts, decisions, roles and history from a conversation transcript and store them automatically (exact and near-identical duplicates are skipped; changed quantities go to the LLM merge). Call at the end of a session with the transcript or a detailed summary of it. Requires REMEMBRA_LLM + an API key. |
| memory_maintainA | Run maintenance: archive memories unused past REMEMBRA_ARCHIVE_AFTER_DAYS (default 90), auto-delete archived memories past REMEMBRA_ARCHIVE_TTL_DAYS (default 365), and backfill missing embedding vectors. Roles never decay. Safe to call anytime. |
| memory_searchB | Retrieve relevant memories from external storage. Call this at the start of a session (or whenever prior context might exist) to recover facts, decisions, roles and history. |
| memory_listB | List stored memories, optionally filtered by scope or type; paginate with offset/limit. |
| memory_forgetB | Permanently delete a memory by its id. |
| memory_getA | Fetch one memory by id with its related links and backlinks (memories that point at it). Use after memory_search when you need the full statement, not the snippet. |
| memory_relateA | Create or remove directed links between memories (the relationship graph): e.g. tie a decision to the facts it depends on, or a history entry to the decision it records. Targets must exist; backlinks are visible via memory_get. |
| memory_historyA | Version history of one memory with unified line diffs — every content-changing update (e.g. a contradiction merge) snapshots the previous version. Newest first. |
| memory_updateA | Patch an existing memory by id — any subset of type/content/scope/tags/importance/confidence/source. Changing scope moves it between trees; a content change refreshes its embedding and snapshots the old version into memory_history. |
| memory_archiveA | Move a memory to the archived tree — out of search results but kept (and listed with includeArchived). Prefer this over forgetting when something may be needed again. |
| memory_reviveB | Bring an archived memory back to active search. |
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
Most tools are clearly distinct: store, get, update, forget, archive, revive, search, list, relate, history, and maintain each map to a separate operation. The main ambiguity is memory_batch, which wraps store/update/delete/export and could be confused with the individual write/update/delete tools, though its batch purpose is stated.
The memory_ prefix is consistent and most suffixes are action verbs: store, search, list, forget, get, relate, update, archive, revive, maintain. memory_batch and memory_history break the verb pattern, but the overall convention remains predictable and readable.
Thirteen tools is well within the ideal range and each tool covers a distinct aspect of memory management: CRUD, search, versioning, relationships, archival, batch operations, ingestion, and maintenance. No tool feels redundant or unnecessary.
The surface fully covers memory lifecycle: store, retrieve, list, search, update, delete, archive, revive, version history, relation management, batch processing, and automated digesting from transcripts. There are no obvious dead ends or missing core operations for the stated purpose.