loreweave
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lore_searchA | Hybrid retrieval over the markdown vault: BM25 + knowledge-graph spreading activation (+ dense embeddings when configured). Returns one passage per note — the section that best covers your query — with the file it came from, how much of your query it matched, and any entity that linked it in. Use for any "what do my notes say about X" question, including multi-hop associations where the answer shares no words with the query. Pass verbose:true only if you need score internals. |
| lore_context_packA | Progressive-disclosure primer: vault stats, top entities, recently modified notes, currently-valid facts, and (if topic given) top search hits. Call once at session start to orient; then drill down with lore_search / lore_read_note. Every list here is a sample: when one is cut, a |
| lore_read_noteA | Read the raw markdown of a note by vault-relative path (as returned in search results). Never reads outside the vault — a path that escapes it, including through a symlink whose target lives elsewhere, is refused, and such a file is not indexed or searchable either. After reading a note that answered the question, call lore_mark_used to reinforce it. |
| lore_assert_factA | Record an atomic fact (subject :: predicate :: object) with bitemporal validity. Contradicting facts in the same slot are superseded automatically (never deleted; history stays queryable). The fact is journalled to lore/journal/ in markdown, so the vault remains the source of truth. Use for durable knowledge: decisions, states, preferences, relationships. |
| lore_invalidate_factA | Close the currently-valid fact in a (subject, predicate) slot without asserting a replacement — e.g. "no longer true". Journalled; history preserved. |
| lore_resumeA | What changed since this tool was last called: notes edited, facts asserted, and knowledge updates (slot: old → new). Call once at session start to continue where the previous session left off — the delta is computed from record time, so the same watermark always yields the same answer. Calling with no |
| lore_reviewA | Important-but-fading knowledge: blocks whose retrievability has decayed below the threshold despite mattering, plus long-untouched open facts. This is the spaced-repetition loop made operable: review the list, then call lore_mark_used on anything still relevant — use is what reinforces stability. Deterministic, computed from the vault's own fitted forgetting curve. |
| lore_timelineA | Chronological history of an entity in one call: every value change from the bitemporal fact store (with what each value replaced and when it stopped holding) merged with content-dated passages mentioning the entity. Use for "what happened to X", "what was X before it changed", "history of X" — instead of sampling repeated as-of fact queries and windowed searches. |
| lore_query_factsA | Query the bitemporal fact store. Default: currently-valid facts. asOf answers "what was true on DATE", asKnownAt answers "what did we know on DATE"; includeHistory shows the full supersession chain. Prefer this over lore_search for factual slots (status, location, role, preference). Returns { facts } and, when the result is a sample, a |
| lore_aggregate_factsA | Deterministic aggregation over fact history — counts grouped by object/subject/predicate with date-range filters. Use for "how many X", "which Y most often" questions; similarity search cannot answer these reliably. Returns { groups, totalGroups, limit }: |
| lore_captureA | Append a timestamped line to lore/inbox.md (or another vault note). Use for fleeting observations worth keeping that are not atomic facts. The captured text is searchable immediately. Never overwrites anything, and never writes outside the vault — a path that escapes it, including through a symlink, is refused. |
| lore_mark_usedA | Reinforce passages that actually contributed to your answer (spaced-repetition signal: used memories decay slower). Call after citing a note. |
| lore_dream_reportA | Run the consolidation pass: duplicate passages, contradicting/recently-changed facts, stale knowledge needing review, suggested missing links, orphan notes. Leaves the vault untouched unless apply=true (which writes a digest + review queue under lore/); it does perform index maintenance either way, which changes no results. Findings are a summary — pass verbose:true for every one. |
| lore_propose_factsA | Returns candidate facts mined from a note's structure that are NOT yet in the fact store, for you to adjudicate. The engine only auto-accepts unambiguous field syntax (frontmatter, |
| lore_indexA | Incrementally sync the markdown vault into the index. Call after writing files to the vault through anything OTHER than lore_* tools (an editor, another agent, plain fs writes) — the lore_* write tools index their own writes, so their content is searchable immediately without this. |
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 15 tools
Each tool targets a distinct operation—orientation (context_pack/resume), retrieval (search/read), structured facts (query/aggregate/timeline/assert/invalidate), and maintenance (review/dream/mark_used). Descriptions explicitly guide when to prefer one over another, leaving no meaningful ambiguity.
All tools use the lore_ prefix and lower snake_case, which is highly consistent. A few names are noun phrases (context_pack, timeline, dream_report) rather than strict verb_noun, but no mixed conventions or camelCase appear.
15 tools sit at the top of the recommended range but each covers a distinct capability in a rich knowledge-management system. No tool appears redundant or tacked on; the set is well-scoped for its domain.
The surface covers ingestion, retrieval, fact lifecycle, review, and consolidation comprehensively. Direct note edit/delete tools are absent, but the design supports external vault edits via lore_index, so core workflows are not blocked.