Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LLMKOSH_ROOTNoThe root directory for the cartridge (alternative to --root)

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
search_memoryC

Search the Cartridge Knowledge Base for memories, decisions, and files.

get_cartridge_memory_mapB

Returns a structural map of the knowledge base projects and active concepts.

get_project_contextC

Fetches all context and active decisions for a specific project.

list_intakeB

Lists the current items pending in the intake queue.

get_daemon_statusC

Verifies the cryptographic ledger of the Cartridge.

company_memory_searchC

Permission-first hybrid search over atomic, evidence-backed company memory.

company_context_compileD

Compile structured, cited, token-budgeted context for an agent task.

company_memory_getB

Get one authorized memory with its evidence references and lifecycle.

company_brain_healthB

Validate canonical company-brain storage and projection consistency.

company_brain_evaluateB

Run reference storage, citation, and projection acceptance checks.

company_session_understandC

Build normalized sessions, episodes, and cited candidates from JSONL evidence.

company_sessions_listC

List authorized normalized source sessions.

company_episodes_searchC

Search authorized goal-oriented work episodes and observed outcomes.

company_episode_getB

Get one authorized episode with ordered event and candidate provenance.

company_artifact_registerB

Register an existing local artifact by fingerprint without copying its bytes.

company_artifact_inspectC

Verify and inspect a bounded region of an authorized registered artifact.

company_artifact_segmentC

Inspect an artifact and persist bounded derived segments with native citations.

company_artifact_snapshotC

Explicitly materialize an authorized artifact into immutable snapshot storage.

company_memory_proposeC

Create immutable evidence and a non-authoritative candidate memory.

company_memory_propose_from_evidenceC

Create a candidate semantic memory citing an existing registered artifact.

company_memory_reviewC

Apply a governed lifecycle transition to an authorized memory.

create_private_context_packC

Creates a highly focused context pack for a specific task. Includes private and sensitive information.

submit_memory_receiptA

Submits a MEMORY_RECEIPT.md formatted string to the intake queue. Does not apply it directly; it must be reviewed and applied.

intake_convert_fileC

Converts a local file (e.g. PDF, DOCX, XLSX, PPTX, PNG, WAV) to structured markdown using the MarkItDown converter and ingests it into the cartridge.

apply_intake_proposalC

Directly applies an intake proposal batch to the live memory.

reasoning_ingestA

Add a bounded atomic fact to the Temporal Causal Reasoning Graph. This is a write operation and requires --allow-write. documented_at and valid_from are ISO 8601 datetime strings. causal_edges: JSON array of {"target_id": str, "edge_type": str, "confidence": float}. Returns the new fact_id.

reasoning_queryB

Query the Temporal Causal Reasoning Graph. By default returns a human-readable causal narrative (narrative=True). Set narrative=False to get raw JSON with full fiber bundle details. temporal_context: ISO 8601 datetime or Unix timestamp string (omit for now).

reasoning_critiqueA

Run the Lyapunov critic on a specific list of fact IDs. Returns stability score, status, and per-dimension breakdown.

reasoning_exploreB

Enumerate all causal paths between two known facts. Returns the fiber bundle for that specific pair.

kosh_verifyC

Verify a question against local temporal/causal evidence.

This is read-only. The returned JSON report can include supporting facts, causal paths, contradictions, inferred-but-not-discovered relationships, missing evidence, stability information, and an explicit abstention state.

It does not consult the internet, seed demo data, write or mutate memory, export private context, or make an imported source trustworthy.

trusted_memory_recallC

Recall governed memory with admission and lifecycle policy enforced.

trusted_memory_inboxB

List authorized candidate and quarantined Trusted Memory items.

trusted_memory_conflictsC

List unresolved authorized Trusted Memory conflicts.

trusted_memory_explainB

Explain one authorized memory with evidence and admission history.

trusted_memory_proposeA

Propose governed memory. Requires MCP write capability.

If evidence_id is omitted, the proposal is persisted as an agent_observation. Agents cannot self-label new MCP evidence as user_direct. To preserve a stronger or different source type, register evidence first and pass its existing id.

trusted_memory_reviewC

Explicitly approve, quarantine, reject, or supersede governed memory.

Requires the existing MCP mutate capability. Conflict resolution is never inferred from a generic approval.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.4/5.0

Scored across 36 tools

Disambiguation2/5

There are multiple overlapping retrieval and governance clusters: search_memory, company_memory_search, trusted_memory_recall, and kosh_verify all serve different-but-similar memory/questioning purposes, while company_brain_health and company_brain_evaluate appear nearly interchangeable. The trusted_memory_* and company_memory_* families further blur boundaries around 'governed memory' vs 'company memory'.

Naming Consistency2/5

Naming mixes several patterns: verb-first (search_memory, list_intake), noun-first domain actions (trusted_memory_propose, company_memory_search), and prefix-plus-verb (reasoning_query, intake_convert_file). Although all names are snake_case, the inconsistent ordering and domain-prefix placement make the surface harder to predict.

Tool Count2/5

36 tools is heavy for a single MCP server, spanning at least four major subsystems: cartridge/intake, trusted memory, company memory/artifacts, and causal reasoning. Many tools could reasonably be split into separate servers, and the count creates cognitive load and selection risk.

Completeness3/5

The server covers many lifecycle stages across memory, evidence, artifacts, intake, and reasoning, including propose/review/recall/search and artifact registration/inspection/snapshot. However, there are notable gaps such as no direct memory deletion/update, no artifact listing, and no project listing beyond a structural map.

Maintenance

ActivityMaintained
ResponsivenessNo issues