ContextLattice
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MINDSDB_ENABLED | No | false | |
| MONGO_RAW_ENABLED | No | false | |
| CONTEXTLATTICE_ENV | No | development | |
| ORCH_START_INTERNAL | No | true | |
| ORCH_SECURITY_STRICT | No | false | |
| SECRETS_STORAGE_MODE | No | redact | |
| FANOUT_OUTBOX_BACKEND | No | sqlite | |
| ORCH_PGVECTOR_ENABLED | No | false | |
| SIGNAL_REFRESH_ENABLED | No | false | |
| SINK_RETENTION_ENABLED | No | false | |
| OVERRIDE_REFRESH_ENABLED | No | false | |
| ORCH_STARTUP_TIMEOUT_SECS | No | 45 | |
| ORCH_RETRIEVAL_FAST_SOURCES | No | topic_rollups | |
| TOPIC_ROLLUP_SQLITE_ENABLED | No | true | |
| ORCH_RETRIEVAL_DEFAULT_SOURCES | No | topic_rollups | |
| ORCH_PRODUCTION_REQUIRE_API_KEY | No | false | |
| TOPIC_ROLLUP_SQLITE_FTS_ENABLED | No | true | |
| TOPIC_ROLLUP_SQLITE_VEC_ENABLED | No | true | |
| CONTEXTLATTICE_ORCHESTRATOR_API_KEY | No |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Run a non-destructive runtime health check before any memory tool call. Use this when a connection fails, startup seems incomplete, or you need readiness evidence before writes. Returns a JSON health envelope (for example: status/services/components/queue fields) as both text and structured JSON. If the orchestrator requires an API key and the bridge is not configured, this returns an auth failure instead of mutating state. |
| memory.searchA | Read-only contextual retrieval for pre-inference recall. Required: project + query. Keep project aligned with prior memory.write calls so ranking and topic continuity remain coherent. Parameter interactions: topic_path narrows scope and usually reduces noise/latency; if scoped reads return empty/degraded, retry once without topic_path. include_grounding=true adds citation-safe grounding with strict numeric copy behavior (numbers must be consumed verbatim). include_retrieval_debug=true adds source policy/timing/failure detail for diagnosis and can increase payload size. agent_id should stay stable across sessions so retrieval profile defaults (mode/sources/escalation) remain deterministic. Lifecycle handling: result_state can be ready/pending/degraded/empty; when pending/degraded, use warnings/source status and continuation metadata to re-read after cache warm. Do not use this tool for writes or health checks: use memory.write for persistence and health for startup/readiness checks. On auth/upstream failures this returns isError=true with structured error payload. |
| memory.writeA | State-changing durable memory write used for checkpoints, implementation decisions, and compact recall artifacts. Parameter interactions: projectName should match the project used by memory.search; fileName is the logical lineage key (stable fileName preserves continuity and dedupe behavior); topicPath controls retrieval partitioning and, if omitted, is derived from fileName. content should be concise and factual (avoid full transcripts; preserve numeric facts verbatim). Side effects: successful writes may trigger asynchronous fanout/indexing/rollup work. ok=true with event_id means the write was accepted, but per-target fanout can still be pending/retrying and is returned in fanout/warnings. Do not use this for retrieval or diagnostics: use memory.search for reads and health for readiness checks. On auth/upstream errors this returns isError=true with structured error payload. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools have completely distinct purposes: health handles readiness checks, memory.search is read-only retrieval, and memory.write is state-changing persistence. Their descriptions explicitly cross-reference each other to prevent confusion.
memory.search and memory.write follow a consistent memory.<verb> pattern, but health is a standalone noun not following the same convention. Minor deviation, still readable.
Three tools is within the ideal 3-15 range and each tool serves a distinct, necessary purpose (health, retrieval, persistence). The scope is tightly focused with no redundancy.
Core read/write operations are covered along with a health check. Missing operations like delete or list all might be absent, but search and write cover the primary memory lifecycle without clear dead ends.