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
capture_eventA

Capture a lifecycle event — called by hook scripts, not intended for direct use. session_start/prompt_submit return context packs; file_save reindexes and may return rules governing the edited file; session_end runs consolidation.

consolidateA

Run deferred consolidation — promote supported observations to rules, merge confirmed duplicates. Housekeeping, not a write path; dedup and contradiction checks already run on every insert.

create_entityA

Create a knowledge-layer entity. entity_type picks the lifecycle, not the topic — ask what the entry IS: 'observation' = something that happened (bug found, surprising behavior, decision noticed) — raw, append-only, unvalidated; consolidation promotes the good ones to rules. 'rule' = a verified directive agents must always follow (conventions, constraints) — pushed into every context pack; change via supersede, not edits. 'knowledge' = a curated reference doc (architecture, gotchas, design decisions) — the only editable type (update_knowledge). Requires: content always; title+category for knowledge.

find_orphansA

Find code entities with no incoming calls/imports/extends edges — dead-code candidates. Use during cleanup audits. Entry points like main() surface by design; test code is excluded.

get_callersA

Find entities that call this function — answers 'who calls X?' with resolved call edges, not text matches. Use instead of grepping for the name when you need real callers (not comments, strings, or same-named functions).

get_contextA

Assemble a context pack — a scoped, ranked bundle of orientation, rules, relevant code, and knowledge for a task query. Use at the start of substantial work on a topic instead of reading files broadly — narrower than a session-start pack, broader than a single search.

get_impactA

Transitive dependents of an entity — what breaks or needs updating when it changes (incoming calls/imports/extends up to max_depth hops), plus knowledge that references it. Use before renaming, deleting, or changing a signature.

get_statusA

CogZ system status — entity counts, DB stats, model availability, staleness. Use to check the index is fresh and retrieval is at full capability before relying on it.

list_entitiesA

List IDs and titles for all entities of a type. Use to enumerate a type or resolve an entity_id for get_callers/get_impact — returns no content; for substance use search or query_* tools.

query_entitiesA

Browse knowledge-layer entities of one type — 'observation' (raw findings, recency order), 'rule' (verified directives, confidence order), or 'knowledge' (curated docs). Use to enumerate what exists before writing (avoid duplicates) or to review a type — for ranked retrieval on a question use search; for code entities use list_entities or search.

reject_entityA

Reject a knowledge-layer entity — writes status: rejected (and an optional rejected_reason) into its canonical file, then syncs so the status lattice validates the transition. Only active entities can be rejected; verify a stale one first if it must be ruled wrong. This is a verdict, not an edit — do not use it for content changes. Rejected entities stay on record: retrieval filters them out, and dedup can warn when a matching claim resurfaces.

searchA

Ranked search across all entities — code (functions, files, classes) plus rules, observations, and knowledge — using hybrid lexical + semantic retrieval with graph expansion. Use when you know the concept but not the exact name, or want related entities surfaced automatically. For exact identifier/text matches, grep is faster and equally precise.

suggest_observationsA

Mine recent session usage for observation candidates — zero-hit packs followed by edits, hot files, error→fix sequences. Use at natural stopping points to capture what the session learned; confirm salient suggestions via create_entity.

update_knowledgeA

Update an existing knowledge entry's content — use to correct or extend documentation when facts change. The only entity type allowing in-place edits; observations and rules are append-only.

verify_knowledgeA

Re-verify a knowledge entity against its referenced code — re-stamps verified_against provenance, clears drift annotations, and reactivates the entity if it was stale. Use after reading drift-flagged or stale knowledge and confirming it is still accurate — not for changing content (use update_knowledge instead).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 15 tools

Disambiguation4/5

Tools are mostly well-differentiated with explicit cross-references ('use update_knowledge instead', 'for code entities use list_entities'). The overlap between list_entities and query_entities is real but the descriptions carefully delineate them (code vs knowledge-layer, IDs only vs content). search vs query_entities vs get_context is a slightly murky trio, but each description states its intended use.

Naming Consistency4/5

Predominantly verb_noun snake_case (update_knowledge, verify_knowledge, list_entities, query_entities, get_impact, create_entity). A few bare verbs (search, consolidate) and internal/verb-only names (reject_entity, capture_event, suggest_observations) are acceptable and readable. Minor deviation but consistent overall.

Tool Count4/5

15 tools for a knowledge/code-graph memory system with retrieval, lifecycle, write, and maintenance concerns is reasonable. One or two (capture_event explicitly marked 'not intended for direct use') could be hidden from the agent-facing surface, but nothing feels excessive.

Completeness4/5

Covers the full knowledge lifecycle: create, update, verify, reject, consolidate, plus retrieval (search, query, context, impact, callers, orphans) and status. Gaps are minor — no explicit delete of knowledge-layer entities (rejection/supersede likely intended instead) and no direct supersede tool despite it being referenced.

Maintenance

ActivityActive
ResponsivenessNo issues