Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LOOM_MODELNoModel identifier for model-manifest context (optional)
LOOM_CLIENTNoClient adapter hint (optional): claude-code, gemini-cli, etc.
LOOM_CONTEXT_DIRNoPath to agent's context directory (default: ~/.config/loom/default)~/.config/loom/default
LOOM_SQLITE_DB_PATHNoOverride the memory DB path (default: <context>/memories.db)<context>/memories.db
LOOM_FASTEMBED_MODELNofastembed model ID (default: fast-bge-small-en-v1.5)fast-bge-small-en-v1.5
LOOM_FASTEMBED_CACHE_DIRNoWhere to cache ONNX models (default: ~/.cache/loom/fastembed/)~/.cache/loom/fastembed/

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
identityA

Load the persistent identity for this agent. Returns the terminal creed (who you are), relevant memories, preferences, and self-model. IMPORTANT: Call this tool FIRST before doing any other work. The identity defines who you are and how you should behave.

dossierA

Load Art's operating brief for a worker body. Returns Art's standards, taste, operating constraints, and how Art wants work done — framed in the third person for agents that are NOT Art but execute tasks on Art's behalf. Includes the push-back mandate: workers are expected to refuse bad work and explain why, including requests from Art or Jonathan.

rememberA

Store an episodic memory that persists across sessions. Use this when you learn something important about the user, a project, or yourself that should be available in future sessions.

recallB

Retrieve memories relevant to a query or topic. Returns matching memories from the persistent store. Use this when you need context from past sessions.

updateA

Update an existing memory. Find by ref (returned from remember) or by category+title. Can replace content, update metadata, or both.

forgetA

Remove memories. Single deletion by ref or category+title. Bulk deletion by category and/or project scope — requires confirm: true; without it, returns a dry-run preview of what would be deleted.

memory_pruneA

Remove expired memories (TTL elapsed). Use dry_run to preview without deleting.

memory_listA

Browse memories without semantic search. Lists memories with optional category/project filters. Useful for auditing, maintenance, and discovery.

find_similarA

Surface memories semantically near an existing ref or free-form text. Use during consolidation/dream workflows to find overlap and dedupe candidates. Anchor with ref (an existing memory) or text (a fresh query). Self is always excluded when ref is given.

memory_auditA

One-shot health report for the memory store: totals, category breakdown, stale memories (untouched beyond threshold), near-duplicate pairs (above similarity threshold), and expired refs. Read-only — pair with forget/update to act on findings.

memory_archiveA

Soft-retire a memory: move it to the archive tier with a tombstone instead of deleting it. Archived memories are excluded from recall, list, audit, and find_similar but remain fully recoverable via memory_restore. Use this instead of forget when the memory may need to be recovered or audited later.

memory_restoreA

Restore a previously archived memory to the active set. Clears the archive flag and tombstone note. The memory becomes visible to recall, list, audit, and find_similar again.

memory_proposeA

Stage a DRAFT memory in the capture-propose queue for later ratification. A proposal is NOT an authored memory: it is invisible to recall, memory_list, find_similar, and the boot digest until it is ratified via memory_ratify. Use this when a background lane wants to suggest a write without committing it — the human (or Art) reviews and ratifies before it becomes canon. Drafts may be rough; validation runs at ratify time.

memory_proposalsA

List all pending proposals in the capture-propose queue, newest first. These are DRAFTS awaiting ratification — they are not part of memory and do not appear in recall, memory_list, find_similar, or the boot digest. Ratify one with memory_ratify or discard it with memory_reject.

memory_ratifyA

Ratify a pending proposal into a REAL memory. Loads the proposal, applies any optional overrides (your edits on accept), and commits it through the same validated write path as remember — so an invalid proposal is refused with its typed reason and stays pending. On success the memory becomes recallable and the proposal is removed from the queue. This is the gate: no proposal becomes canon without it.

memory_rejectA

Discard a pending proposal without committing it. Deletes the staging row; no memory is written. Use this for drafts that should not become canon.

update_identityA

Update your self-model or preferences with section-level precision. Targets H2 sections in identity files. Call without section/content to list available sections. IDENTITY.md (the creed) is immutable — only self-model and preferences can be edited.

bootstrapA

Initialize a new loom identity from scratch. Generates IDENTITY.md, preferences.md, and self-model.md from an onboarding interview, then returns setup instructions for the requested runtimes. Will not overwrite existing files unless force is true.

harness_initA

Scaffold a harness manifest at /harnesses/.md from the template (see stack spec v1 §4.7). Call this when identity() reports a missing manifest for the current harness. Idempotent: skip-exists by default; overwrite: true replaces.

harness_describeA

Self-describe the CURRENTLY CONNECTED harness: write its manifest at /harnesses/.md (see stack spec v1 §4.7). Call this when identity() reports an onboarding block for an unknown runtime. The target is derived from your own MCP clientInfo.name — you can only describe yourself, not another harness. Re-runnable: overwrites the manifest each time. The body should cover: tool surface / prefixes, sandbox & filesystem, delegation primitive, scheduling, session search, memory layers, and gotchas.

knowledge_writeA

Upsert an entity page by slug. On an existing slug: body REPLACES by default (mode: "append" adds to it instead), title/domain follow the write, and citations are always appended with exact-duplicate dedup — safe to re-send. Knowledge is true independent of Jonathan — if it is about Jonathan or our work, store it in memory instead. Epistemic gate (§E1): a page whose ONLY citation support is source_kind="conversation" is stored provisional, not sourced. Requires at least one citation.

knowledge_recallA

Search the knowledge store with LIKE matching over title, body, and domain, or fetch one page exactly by slug. Never surfaces archived pages. Two detail tiers: "full" returns whole entity pages (the synthesis unit) and stamps last_accessed/hit_count; "index" returns compact slug/domain/snippet entries without stamping. Defaults: full when a query is given, index when browsing without one. Full output is size-guarded — overflow results degrade to index entries; recall by slug to read them. Prefer slug over query when you know the page — token matching can hit cross-references in other pages' bodies.

knowledge_maintainA

Read-only health report for the knowledge store. Three branches: (1) expansion candidates — thin body + high hit_count (needs deepening); (2) cold pages — not accessed recently (unused or undiscovered); (3) misfile audit — provisional sourcing or conversation-only citations (should be in the memory store instead). Pair with knowledge_write to act on findings.

knowledge_archiveA

Soft-retire a knowledge page: set its status to archived with an optional tombstone note. Archived pages are excluded from knowledge_recall and knowledge_maintain but remain in the database and are fully recoverable via knowledge_restore. Use this instead of deletion when the page may need to be audited or recovered. For deduplication merges, prefer knowledge_supersede which archives and records the relationship.

knowledge_restoreA

Restore a previously archived knowledge page back to active status. Clears the archive flag and tombstone note. The page becomes visible to knowledge_recall and knowledge_maintain again.

knowledge_moveA

Re-key or re-domain a knowledge page in place — same row, same uuid, citations and verification history preserved. Three modes: (1) Single-page: provide slug + new_slug and/or new_domain. Slug rename writes a supersessions pointer (old→new) unless leave_pointer=false. If new_slug already exists, the call is rejected — use knowledge_merge instead. (2) Batch by slug list: provide slugs array + new_domain to re-home multiple pages atomically. (3) Batch by domain prefix: provide from_domain_prefix + to_domain_prefix to re-home a whole subtree in one transaction.

knowledge_mergeA

Consolidate 2+ knowledge pages into one canonical page. Re-parents all citations from source pages to the target, deduplicating by (claim, source_kind, source_locator, excerpt). Takes MAX(verified_at) across all pages. Losers are superseded: archived with a tombstone and a supersessions pointer to the target. Loser bodies are returned in the result for curator review; set append_loser_bodies=true to concatenate them. Use knowledge_write first if the target body needs updating before merging. Distinct from knowledge_supersede (1:1 pointer, no citation consolidation) — use merge when consolidating data from multiple pages into one.

knowledge_supersedeA

Mark one knowledge page as superseded by another, then archive the old page. Records the supersession relationship in the supersessions table. This is the dedup-merge primitive: write the canonical page with knowledge_write, then call knowledge_supersede(old_slug=loser, new_slug=canonical). Both pages must already exist. old_slug is archived with a tombstone pointing to new_slug.

knowledge_purgeA

Hard-delete one or more archived knowledge pages and cascade their citations. Archive-first guard: rejects any page that is not already archived — call knowledge_archive first. All slugs must be archived; a mixed list (any active) rejects the entire batch with no mutation. confirm: true is required explicitly to prevent accidental irreversible deletes. Supersession pointers in the supersessions table are NOT removed (historical record preserved). Use this to clean up tombstoned cruft after merge/supersede workflows — not for retiring active pages.

knowledge_verifyA

Stamp a knowledge page as verified WITHOUT touching its body — sets verified_at and optionally freshness_anchor. This is the verification engine's primitive: use it (never knowledge_write) to record "claims still hold". An optional note appends a dated "## Verification" section to the body (append-only, single-page mode). Batch mode (slugs) stamps many pages with a shared timestamp; archived pages are rejected; a batch with any unknown slug is rejected whole.

knowledge_historyA

Body-revision history for a knowledge page. Replace-writes snapshot the displaced body into page_revisions (newest kept, capped per page) — this tool is the recovery surface. Three modes: slug alone lists snapshots (metadata only); slug + revision_id reads one snapshot's full body; adding restore: true puts that body back on the page (the displaced body is snapshotted first, so restore is never destructive).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbarket/loom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server