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

Tools

Functions exposed to the LLM to take actions

NameDescription
accept_refinementA

Accept one listed refinement proposal by id only after the user gives an unambiguous item-level accept decision. For cross_space_discovery, pass the selected destination space. Not available over remote HTTP MCP transport (local stdio only).

accept_revisionA

Accept a pending memory revision. Replaces the target memory's content with the proposed revision content and removes the revision row from the pending list. Returns the consumed revision id. Returns an error if no pending revision exists for that target. Not available over remote HTTP MCP transport (local stdio only).

briefA

Read the current Space Brief when resuming project work or when the user asks to catch up. Omit topic to return only the complete Brief. Provide topic to append separately labeled related context scoped to the same Space. Reads never create or mutate a Brief; the first handoff update can create it.

captureA

Capture a memory: one durable insight the user's wiki should keep.

STORE PROACTIVELY, without waiting for 'remember this' (a floor, not a trigger): when the user states a preference, makes a decision, corrects you or earlier information, or shares a durable fact about themselves or the people, projects, and tools they care about.

WHEN NOT TO STORE: conversation filler; things the user can trivially re-derive (file paths, recent git history); anything already stored (recall first if unsure); Tool output or command results (file contents, build logs, system prompts); transient task state; general world facts not personal to this user; Your own inferences the user did not express; agent operating rules ('always X' / 'never Y' belong in the agent's own config, not shared memory: store the preference as a fact, never the rule).

CONTENT QUALITY: Specific beats vague ('prefers Rust for CLI tools because of compile-time safety' > 'likes Rust'). Include the WHY, which only you know. Name people, projects, and tools; this powers the knowledge graph. Atomic: one idea per memory. Each call is one atomic idea: 'prefers TDD' and 'uses pytest' are two calls. Declarative, not narrative: 'User prefers X because Y', not 'User said today they prefer X'; memories outlive the conversation.

MEMORY TYPES: omit and trust the backend. By default do NOT set memory_type; the backend auto-classifies into identity / preference / decision / lesson / gotcha / fact with more context than you have, and agents that over-specify pick wrong. Opt in only when sure: 'profile' (about the user: identity / preference), 'knowledge' (about the world: decision / lesson / gotcha / fact), or a precise type when the distinction matters. EXCEPTION: set memory_type="decision" explicitly ONLY when the user articulated the alternatives weighed AND the reasoning; those structured fields power the Decision Log view. A bare 'I'm switching to Cursor' is a preference change, not a decision. NO MODEL: when a capture receipt says enrichment: paused or enrichment: off, nothing classifies memories, so set memory_type yourself on every capture.

Omitting structured_fields beats guessing. If supersedes is supplied for a correction, this call can replace an existing memory in retrieval; use it only when that replacement is intended.

confirm_memoryA

Confirm a pending memory by source_id. Use during review to accept a memory the agent captured. The user typically picks from a list_pending result. To reject instead, call forget with the same memory_id.

create_entityA

Resolve a durable named entity idempotently. Use only as a support step when the user explicitly establishes a durable named entity, or when resolved ids are needed for a relation the user explicitly stated. Do not call create_entity for every ordinary capture: with a model source chosen, daemon enrichment extracts entities. Without one (a capture receipt says enrichment is paused or off), capture's entity links only an entity that already exists, so create the entity first.

create_relationA

Create a source-backed directed relation only when the user explicitly states a durable relation. Resolve both endpoint ids with create_entity, capture the user's relation statement, then pass those ids plus the capture result's source_memory_id. If a conflicting relation already exists for the same endpoints, the daemon may auto-supersede that existing relation. Entity names are not accepted or auto-created. Never infer an unstated relation.

delete_pageA

Delete a page by id only when the user explicitly asks to remove it. Destructive — removes both the DB row and the on-disk md projection. To refresh an existing page while preserving its page_id and version history, use write_page. Pages without sources can be re-derived by running /distill again on the same scope.

dismiss_revisionA

Dismiss a pending memory revision. Deletes the revision row; the original memory is unchanged. Returns an error if no pending revision exists for that target. Not available over remote HTTP MCP transport (local stdio only).

distillA

Trigger Wenlan's distillation pass. With no target, runs a full pass that clusters new memories into pages and refreshes the wiki view. With a target, scopes the pass: a page id (page_* or concept_*) re-distills that single page, an entity name scopes clustering to that entity, a space value (e.g. work, personal) scopes to that space. With force=true on a page target, clears the user-edited guard and can replace the page prose during rebuild. Rebuild may send page and source material to the daemon's configured external LLM provider. Use when the user explicitly asks to synthesize, distill, or rebuild a page. With a model source chosen the daemon also distills in the background, so don't trigger redundantly; without one, nothing distills in the background.

forgetA

Delete a memory by ID. Use when the user says 'forget this', 'delete that', 'that's wrong and should be removed'. Requires the source_id — get it from recall first.

This is destructive and cannot be undone. For corrections, prefer storing a new memory with the supersedes param pointing to the old one — this preserves history. If your agent's trust level is below full, that supersedes write may stage for human review instead of taking effect immediately.

get_memory_revisionsA

Fetch the supersede chain for one memory, ordered by depth (0 = current). Use after recall only when the user explicitly asks for that memory's history or evolution, or to verify that a correction was recorded.

get_page_revisionsA

Fetch the version changelog for one page, ordered newest-first. Use only when the user explicitly asks for a page's changelog, version history, or which source memories triggered a re-distill.

get_page_sourcesA

Fetch the source memories of a page — the memory ids the page was distilled from, each enriched with the memory's title, content, type, and space. The /distill skill uses this on the stale-page refresh path after obtaining the page id from the stale_pages block in distill output.

lintA

Run Wenlan's read-only system lint on demand. General is the default bounded deterministic profile. Deep adds expensive deterministic checks plus full-store local semantic candidate generation; bounded candidate packets are adjudicated either by the daemon's configured provider or, with explicit agent_assist consent, by the calling agent through a typed prepare-and-submit protocol. General returns the text wenlan lint prints; Deep returns the canonical typed report. Incomplete takes precedence over findings. With work_digest (plus offset and limit) it instead pages the cached agent-assisted Deep work packet from this local MCP process: each page holds candidates plus only their referenced records; follow next_offset until absent, then submit exactly one verdict per candidate in the second lint call.

lint_repair_applyA

Apply exactly one prepared lint repair through the daemon's CAS canonical writer. Requires the exact user approval string apply repair <manifest-id> <manifest-digest> and refuses stale targets. Local stdio only.

lint_repair_prepareA

Plan or prepare lint repairs from the reports this local MCP process cached for the exact lint_scope (never paste reports). With only lint_scope: open a new repair plan; returns the summary with source_reports, the first page of entries (up to 100), and next_offset. With plan_id, plan_digest and offset: read the next page; pages are byte-bounded, so follow next_offset until absent. With choice: turn exactly one Review Item into one approval-gated manifest (reclassification needs complete General plus agent-assisted Deep). Planning and preparing write private immutable artifacts and never mutate canonical data. Do not retry a lost plan response: artifacts may already exist. Local stdio only.

lint_repair_verifyA

Record verification for an applied lint repair after rerunning complete General and applicable agent-assisted Deep lint. Rejects surviving target evidence, new actionable findings, stale reports, or any non-target state change. Local stdio only.

list_pagesA

List wiki pages with their ids, titles, summaries, Space, status, and last-modified time. Use it to browse what the wiki already covers before writing a page, or to find the page id read_page needs. Filter by Space or status; page with limit and offset.

list_pendingA

List pending captures: memories waiting for review before they count. Use when the user wants to audit what got captured — typical phrases: 'review pending', 'pending captures', 'what got captured'. Pair with confirm_memory to accept and forget to reject.

list_pending_importsA

List in-flight chat-history imports awaiting processing or completion. Use only when the user asks what imports are running, whether an export is done, or requests import progress. Returns id, vendor, stage, and processed/total conversation counts; the id distinguishes concurrent imports. The source_path is included only over local stdio; remote HTTP returns a progress summary without filesystem paths.

list_pending_revisionsA

List memories awaiting human accept/dismiss because a newer version was proposed (Protected tier supersede). Use when the user asks 'what revisions are pending', 'show me memories awaiting approval'. Each item carries target_source_id (the memory being revised; pass this to accept_revision only after the user explicitly approves that item) and revision_content for display. Review acceptance is local-only; accept_revision is unavailable over remote HTTP MCP. Optional limit caps results (default 50, max 500).

list_refinementsA

List pending daemon refinement proposals only when the user explicitly asks to inspect or review the proposal/refinement queue; never poll this queue ambiently. Returns typed actions and payloads, including vocab_promote. Filter by action and bound the result with limit. Pair with accept_refinement or reject_refinement only after an unambiguous item-level user decision.

list_rejectionsA

List quality-gate flags and rejections: memories the daemon discarded before storing (low quality or another filter), plus near-duplicate memories that were stored anyway but logged for review (reason "near_duplicate"). Use only to diagnose a missing capture, a flagged near duplicate, or when the user asks what Wenlan rejected. Returns reason codes, detail, and similarity info; optional limit and reason filters narrow the audit.

page_basisA

Track what a wiki page relies on another page for. Use when read_page, list_pages or recall shows a pending basis. mark/confirm need version (the basis note's page.version from read_page) and fail if it moved on. diff shows the text relied on next to the text now. remove drops it. Changes are local stdio only.

page_code_basisA

Settle a code_basis row that is pending, unavailable or moved, after reading the code. confirm: the page still holds for the code as it reads now; Wenlan re-reads the file and sets the row ok. If it no longer holds, rewrite with write_page. remove: drop the reliance. Pass the row's repo_root, path, line_start, line_end. Local stdio only.

read_pageA

Read one wiki page in full: its title, body, status, Space, and the source memories it cites, in one call. Use it after list_pages or recall when the user wants the page itself rather than search snippets. The page id is opaque; never guess it from a title.

recallA

Search memories by query. Use when the user asks 'do you remember', 'what do you know about', 'look up', or when you need a specific fact before acting.

Write queries as natural language — the search engine handles semantic matching. For precision, use filters (memory_type, space) to narrow results. If you get too many results, add filters rather than making the query longer.

For higher retrieval quality at the cost of latency, pass rerank: true to opt into the cross-encoder reranker (requires WENLAN_RERANKER_ENABLED=1 on the daemon).

This is for targeted lookups. To resume work from a Space-owned project snapshot, use brief instead. Search records the query and accessed memory IDs in local activity history for auditability; it does not rewrite stored knowledge.

reject_refinementA

Reject one listed refinement proposal by id only after the user gives an unambiguous item-level reject decision. Rejecting marks the proposal dismissed and terminal, so it cannot be retried; this changes workflow state but does not delete or overwrite the underlying memory or page. Skip or cancel is a no-op. Not available over remote HTTP MCP transport (local stdio only).

rename_pageA

Rename an existing page only when the user explicitly asks to change its title. Pass the page_id and expected_version from the latest page result; the version prevents renaming a page that changed since it was read. This changes the title only and preserves the page id and content. It is unavailable over remote HTTP MCP transport (local stdio only). Do not call this during distillation, synthesis, or content refresh; write_page keeps an existing title when refreshing.

save_sourceA

Save a document from another app or the web (email, Notion or Drive page, Slack thread, article) with a permanent link to the original. Use this instead of capture when the content has a link. Pass the text as read, not a summary; never bulk-copy an inbox or channel. It is a snapshot: Wenlan does not fetch or sync the original; saving the same url replaces it.

update_briefA

Hand off to the next session by updating the Space Brief: replace the summary (guarded by expected_version) and add, edit, move, gate, or complete items. Read brief first and reuse its brief_version and item versions; conflicts are reported, never silently overwritten. The first update creates the Brief. Local stdio only.

write_pageA

Create or refresh a wiki page. When the user asks to turn something from this conversation into a page, call write_page with a title and the content; source_memory_ids are optional. This write can replace an existing page: omit page_id to create a new page (title required); with enough cited sources it lands as a distilled page, otherwise as an authored page. The daemon writes the DB row and the on-disk /.md projection atomically (default ~/.wenlan/pages/, slug made unique on collision). Pass page_id (from the stale_pages block in distill output) to refresh that page in place — replaces content + source_memory_ids + optional summary, clears stale_reason, preserves page_id and created_at, bumps version monotonically so external [[wikilinks]] keep working. Never delete_page + recreate to refresh: that churns ids and loses version history. To change an existing page's title at the user's explicit request, use rename_page; refresh keeps the existing title. Before a refresh, read_page and pass its page.version as expected_version: if the page moved on, the write is refused with nothing changed, so re-read and retry. Without expected_version, a refresh of a page the user wrote or edited is refused the same way. A page with review_required set stages every refresh as a revision card for the user. basis [{page_id, version}] lists notes relied on (versions from read_page); a changed one lands pending (see page_basis). minor: true = small edit. code_basis [{repo_root, path, line_start, line_end}]: code lines relied on (see page_code_basis). Refresh is not available over remote HTTP MCP transport (local stdio only).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 33 tools

Disambiguation4/5

Most tools target clearly distinct resources and actions (capture vs save_source vs write_page vs read_page), and descriptions supply explicit disambiguation cues like 'use this instead of capture when the content has a link'. Residual confusion lives in the review-queue family — list_pending, list_pending_revisions, list_pending_imports, list_refinements, plus confirm_memory/accept_revision/accept_refinement — and in the near-twin page_basis/page_code_basis pair, where an agent must read carefully before choosing.

Naming Consistency4/5

The dominant pattern is snake_case verb_noun (list_pages, get_page_sources, delete_page, dismiss_revision, create_relation), which is applied consistently across CRUD and review operations. Deviations are minor: a handful of bare verbs (capture, recall, distill, lint, forget, brief) and two noun-first names (page_basis, page_code_basis).

Tool Count3/5

33 tools is on the heavy side, and a tail of rarely invoked, local-stdio-only operations (lint_repair_prepare/apply/verify, page_code_basis, list_rejections, list_pending_imports) inflates the surface. The domain genuinely spans several subdomains — memory lifecycle, distillation, wiki pages, lint/repair, refinements, briefs — so each tool has a defensible role, but the set is borderline oversized for a single MCP endpoint.

Completeness4/5

Coverage is unusually thorough: memories have capture/recall/confirm/forget plus revisions, pages have full create/read/list/write/rename/delete with revisions and sources, and review queues, lint, briefs, entities, and relations all have entry points. Gaps are minor but real — no direct get_memory-by-id (forget depends on finding the memory via recall first), no entity/relation listing or deletion, and no page search beyond list_pages paging.

Maintenance

ActivityActive
ResponsivenessWithin a week