Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
dbNoPath to the SQLite database file where memory is stored (e.g., './memory.db').
project_nameNoThe name of the project for which memory is being managed.
skip_integrityNoBypass tool description integrity verification. Useful for development.

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
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
recordA

Record a typed episode to memory. Call this when important decisions are made, patterns are noticed, tensions are identified, questions arise, or outcomes are observed. Record the reasoning, not just the fact — 'Chose X because Y' is more valuable than 'using X'. Episodes accumulate during a session and serve as raw material for compression into the continuity file at session end.

recallA

Query episodes from memory with filters. Call this to find prior context before making decisions, to locate specific episodes for citation during graduation, or to review recent work. Returns matching episodes ordered by timestamp (newest first). Supports time range, type, source, and keyword filters. The keyword is matched as an exact phrase first; if no episode contains the whole phrase and it has two or more distinctive words, the call falls back to ranking episodes by how many of those words they contain (the reply says so and names the words each episode matched), so a multi-word query does not need to appear verbatim. A phrase of three or more distinctive words with only one or two exact hits is followed by a few word matches, listed under 'Also matching by words'. A durable fact whose cue words appear in the keyword (or two distinctive words of its text) is listed first, under 'Durable facts matching your words'. limit=0 returns nothing at all, facts included.

prepare_wrapA

Prepare a compression package for session wrap. Call this at session boundaries — when work is ending, the user says to wrap up, or the session is getting long. Returns all episodes since the last wrap, the current continuity file, stale pattern warnings, Hebbian association context (which episodes have been thought about together before), and compression instructions. Marks a wrap as in-progress and mints a session-handshake token (shown as 'Wrap token: ' at the end of the response) — round-trip that token to save_continuity's wrap_token argument so the save call can verify it matches the in-progress wrap and catch stale tokens. After calling, follow the returned instructions to compress episodes into an updated continuity file, then save with save_continuity. The compression step is where the real thinking happens — patterns emerge that weren't visible in the raw episodes.

save_continuityA

Validate and save the compressed continuity file. Call this after compressing your episodes using the instructions from prepare_wrap. The text must contain exactly 4 sections: ## State, ## Patterns, ## Decisions, ## Context. The server validates structure, checks graduation citations against real episodes (cited IDs must exist), checks explanation overlap (evidence must reference actual episode content), detects citation gaming (suspicious reuse of single episodes), and may demote ungrounded graduations. Also records Hebbian associations between co-cited episodes (episodes cited together on the same pattern line form strong links; episodes cited in the same wrap form weaker links) and decays unreinforced associations. Returns validation results, association metrics, and section sizes.

wrap_cancelA

Abandon a wrap that is in progress, clearing the wrap-in-progress state so a fresh prepare_wrap can run. Call this when prepare_wrap refuses with 'a wrap is already in progress' and that wrap is NOT going to be finished — typically one an earlier session opened and then ended without saving, so nothing is left to compress it. Episodes are NOT deleted: cancelling discards the frozen snapshot and its handshake token, and every episode in the abandoned window is still recorded and is picked up by the next prepare_wrap. The cancellation is written to the audit trail with the abandoned token and episode IDs. Check who owns the wrap before cancelling it. One server process runs per client session against a shared store, so the wrap may belong to another session that is still running and part-way through composing its compression; cancelling makes that session's save fail and throws its work away. Call status first — it reports when the wrap started, and one opened moments ago is probably a live peer rather than a corpse. Prefer finishing a wrap you opened yourself. Do not call this to recover from a save_continuity validation failure you can fix by editing the text and saving again — that wrap is still live and cancelling it throws away the snapshot you are working against. If you opened the wrap yourself, pass the wrap_token prepare_wrap gave you: the cancel then succeeds only if that wrap is still the one in progress, and is refused without changing anything if a peer replaced it. Omit wrap_token to cancel whatever is current, which is what you want when recovering a wrap you did not open. Exception: a wrap prepared under the consolidate gate is cancelled without its token only when session_id is the session that prepared it, or with force=true when that session is gone; a wrap opened with a token its preparer supplied is cancelled without that token only with force=true. PARTIAL (corrupt) wrap state is cleared with partial=true, which refuses if a healthy wrap has replaced it.

delete_episodeA

Delete a single episode by ID. Use this for content that should not exist: accidentally recorded PII, sensitive data, or fundamentally wrong recordings. Do NOT use for factual corrections — record a new episode with the correction instead and let compression resolve it. Deletion cascades: all Hebbian associations involving the episode are removed, and the deletion is logged in the audit trail. By default, a tombstone is preserved as an existence proof for audit integrity: episode ID, original timestamp, episode type, and SHA-256 content hash are retained — the original text is fully erased. Under GDPR framing, the retained fields are pseudonymized metadata, not content; disable tombstones at Store construction (keep_tombstones=False) if even this metadata must not survive. The hash chain remains verifiable either way. This action is irreversible.

statusA

Get memory health metrics. Call this at session start to understand memory state, or when diagnosing issues. Returns episode counts (total and since last wrap), wrap history, continuity file size, episodes by type, whether a wrap is currently in progress, Hebbian association network metrics (total links, average/max strength, network density), and audit trail health (enabled/disabled, entry count, log path, retention window). Use anneal-memory verify from the CLI to validate the audit hash chain itself — status() only surfaces cheap health signals, not integrity proof.

crystal_recallA

Recall crystallized patterns relevant to a free-text query — the on-demand graduated tier (AM-CRYSTAL). Crystallized patterns are proven-and-stable wisdom that graduated OUT of the always-loaded working set into a retrievable store, so a large body of wisdom stays effective without clogging context. Call this when a decision, design choice, or question touches a topic where prior graduated wisdom might apply — recall surfaces the relevant patterns on cue (pair it with crystal_index, the always-on menu of what exists). Associative by default: a pattern grounded in an episode your query matched surfaces even with zero keyword overlap (the evidence edge). Returns scored patterns (name, level, activation, explanation, tags). In the default 'prompt' mode it is precision-biased: a thin query or no match returns none, by design (surface nothing rather than noise). Pass mode='query' when you are asking explicitly. Durable facts whose cue words appear in the query (or two distinctive words of its text) are listed first, under 'Durable facts matching your words'. max_patterns=0 returns nothing at all, facts included.

crystal_indexA

List the always-on crystallized INDEX — a name + one-clause menu of every live crystallized pattern (AM-CRYSTAL-INDEX). Call this at session start, or any time you want to know what graduated wisdom exists, so you aren't blind to your own crystallized corpus; then pull a body on cue with crystal_recall. Deliberately thin (name + clause only) — the menu is meant to be cheap to keep in view. Sorted by name. Returns nothing when no patterns have been crystallized yet.

spore_addA

Plant a spore — an open cognitive loop in the PROSPECTIVE layer (a thing that must RESOLVE), distinct from episodic/continuity memory (which accretes and never completes). Use for an open intention you want to carry forward and close later: a task (open doing), a question (open not-knowing), or a thought (open idea). Set tier to weight intent (hot/warm/cold/parked) and next (YYYY-MM-DD) to ask for re-surfacing on a date. Resolve later via spore_descend (compost) or spore_ascend (transmute into memory/a project).

spore_getA

Fetch one spore by id (searches open first, then resolved). Returns its full record including computed germination and any resolution.

spore_listA

List OPEN spores, ranked by tier then salience then germination. Germination is computed at read-time (growing <3d / resting 3–7d / dormant >7d or past its next: / parked). Filter by type, tier, domain, or germination. This is the working view; for the salience-generator surface use spore_surface.

spore_touchA

Engage a spore: set seen to today and clear an elapsed next: alarm (returning it to 'growing'). Call when you revisit an open loop but aren't resolving it — keeps germination honest.

spore_updateA

Metadata surgery on an OPEN spore. Only the fields you pass change; pass an empty string to next/pointer/domain to CLEAR them. Does NOT bump seen (use spore_touch to signal engagement). Use add_note to append a dated note.

spore_descendA

Resolve a spore DOWNWARD — compost / self-clean. kind must fit the spore's type: task -> done|dropped|composted; question -> answered|mooted|composted; thought -> explored|dropped|composted ('composted' is the universal neglect-descent). This is the close that does NOT cross into retrospective memory.

spore_ascendC

Resolve a spore UPWARD — the membrane INTO retrospective memory. The spore became real work: record a ref (a pointer to what it became — a project path, an episode id, a pattern name). kind must fit the type: task -> project|thread; question -> episode|pattern; thought -> essay|pattern|project. In v1 this RECORDS the pointer; the actual episode/continuity write stays the host's act.

spore_surfaceC

The seed-side surface a salience generator consumes. With top_of_mind=true, only the Top-of-Mind contribution (spores that are 'hot' OR 'growing', ranked, across all three types); otherwise all open spores, ranked. The downstream consumer composes the full Top of Mind from this x active threads x recent ships.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
Continuity FileThe current compressed continuity file — always-loaded agent memory.
Tool Integrity ManifestSHA-256 hashes of all tool definitions for client-side integrity verification. Compare these hashes against the tool definitions you received to detect transport-layer description mutation. This enables host-level verification WITHOUT trusting the server process.

TDQS

A3.7/5.0

Scored across 17 tools

Disambiguation4/5

Most tools target distinct resources (episodes, spores, crystals, wraps), and tricky pairs like spore_touch vs spore_update and spore_descend vs spore_ascend are explicitly differentiated in their descriptions. The main soft spots are spore_list vs spore_surface (both enumerate open spores) and recall vs crystal_recall (both surface 'durable facts'), which require careful reading to separate.

Naming Consistency3/5

Names are domain-grouped (spore_*, crystal_*, wrap_*) but ordering conventions are mixed: noun_verb (spore_list, crystal_recall, wrap_cancel) sits alongside verb_noun (prepare_wrap, save_continuity, delete_episode) and bare verbs (record, recall, status). It remains readable and largely predictable within the spore_ and crystal_ families, but the global pattern is inconsistent.

Tool Count4/5

17 tools is slightly above the ideal band but justified by three genuinely distinct memory layers (episodic/continuity, prospective spores, crystallized patterns) plus health/diagnostics. Each tool earns its place; the eight spore_* tools are the heaviest cluster but map to a real state machine.

Completeness4/5

Coverage is strong across the lifecycle: episodes (record/recall/delete), continuity (prepare_wrap/save_continuity/wrap_cancel), spores (add/get/update/touch/list/surface/descend/ascend), crystals (index/recall), and status. Minor gaps like fetching a single episode by ID or any direct episode correction path (intentionally delegated to re-recording) are workable around.

Maintenance

ActivityActive
ResponsivenessUnresponsive