Lorekeeper
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lore_searchA | Search memories by semantic + keyword query, or bulk-fetch by ID. When |
| lore_insertB | Insert memories and/or links into the store. Each memory dict must include:
Each top-level link dict must include source_memory_id, target_memory_id, relation_type, and reason. |
| lore_recommend_linksA | Suggest link candidates between a memory and related memories. Returns ranked candidates with per-signal scores. Does NOT write any links — call lore_insert with links=[] to confirm. |
| lore_rememberA | Capture a thought instantly — one fact, one call. Use this when you discover something worth keeping: a decision, a bug root cause, a user preference, a pattern. Minimal effort, high reward. Your future self will find this useful. |
| lore_updateA | Rate memories and links after using them. Drives the quality signal loop. Each memory_feedback dict: {id (str), useful (bool), confidence (int 1-10)}. Each link_feedback dict: {id (str), useful (bool), confidence (int 1-10)}.
|
| lore_processed_sessionsA | Return all session IDs that have been marked as processed via lore_reflect. |
| lore_reflectA | Reflect on a completed session — save what you learned. Minimal usage: pass session_id and summary. That's enough. The rest are extras for when you discovered something substantial. |
| lore_forgetA | Soft-delete one or more memories by ID. Memories are marked soft_deleted=1 and excluded from future search results. This is reversible at the DB level but no undelete tool is exposed in v1. |
| lore_get_suggestionsA | Retrieve pending link suggestions for review, sorted by quality score. Returns the top candidates from the sweep engine's pending queue.
Use |
| lore_review_suggestionA | Accept or reject one or more link suggestions in a single call. Processes each suggestion independently — a failure on one does not block the rest. Suggestion rows are never deleted; status is updated to 'accepted' or 'rejected' for audit trail. On accept: creates a real On reject: marks the suggestion as rejected. Future sweeps skip this pair. Idempotent per item: double-accept and double-reject both return
|
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 10 tools
Most tools target distinct operations, but lore_insert and lore_remember both create memories with only a lightweight-vs-structured distinction, and lore_recommend_links vs lore_get_suggestions both surface link candidates through different pipelines. The descriptions help, but an agent could reasonably choose the wrong tool in these overlapping cases.
Tools consistently use the lore_ prefix and mostly follow verb_noun naming like lore_search, lore_insert, lore_update, and lore_review_suggestion. Deviations include bare verbs like lore_remember and lore_reflect, the noun-phrase lore_processed_sessions, and lore_get_suggestions using get_ where other retrieval-like tools do not.
10 tools is well-scoped for a memory store: search, write, feedback, forgetting, link suggestions, and session reflection all have a dedicated tool. No tool feels redundant enough to remove, and the set is not bloated.
The surface covers the core memory lifecycle: create, search, rate, soft-delete, plus link suggestion handling and session reflection. Minor gaps include no direct way to update memory content and no undelete, but bulk-fetch by ID and explicitly reversible soft-delete mitigate the impact.