Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 truncated field names it with { shown, of, rest } and the tool to call for the remainder — so treat a missing item as "not in this sample", never as "not in the vault".

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 since consumes the delta (advances the watermark); pass an explicit since for a pure read that does not.

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 truncated field with { shown, of, rest } — narrow by subject or raise limit before concluding a fact does not exist.

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 }: groups is the top limit (default 100), so read totalGroups for "how many distinct values are there" rather than counting groups, and raise limit if you need the tail.

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, key:: value, - [key] value); prose formatting like - **Owner:** Priya is precise on entity notes and noisy on report notes, so it is surfaced here instead of assumed. Review these and call lore_assert_fact for the ones that are genuinely durable facts. This keeps judgement with you and out of the index.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 15 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessNo issues