ContextLattice сокращает количество повторных обращений к модели (inference), превращая результаты предыдущей работы над проектом в высококачественный, извлекаемый контекст.
Надежная запись в память с распределением (fanout) по специализированным хранилищам.
Режимы быстрого и глубокого поиска с поэтапной выборкой и продолжением при сбоях.
Контекст с приоритетом сводных данных (rollup) для эффективного использования токенов при сохранении путей к исходным артефактам.
Локальное развертывание с опциональными облачными зависимостями.
UX для людей и агентов через HTTP API, транспорт MCP и панель управления операциями.
Related MCP server: copilot-memory-store
Уровень | Основная среда выполнения | Ответственность |
Шлюз/API | Go | Оркестрация |
Сервисы поиска и памяти | Go + Rust | Каналы быстрого/надежного поиска, обработка сводных данных, адаптеры банков памяти |
Устаревший резервный вариант | Python | Только для обеспечения совместимости (не основной путь) |
Панель управления | TypeScript/Next.js | Консоль, интеллект-карта, статус, биллинг, UX настройки |
macOS DMG: https://github.com/sheawinkler/ContextLattice/releases/latest/download/ContextLattice-macOS-universal.dmg
Linux bundle: https://github.com/sheawinkler/ContextLattice/releases/latest/download/ContextLattice-linux-bootstrap.tar.gz
Windows MSI: https://github.com/sheawinkler/ContextLattice/releases/latest/download/ContextLattice-windows-x64.msi
git clone git@github.com:sheawinkler/ContextLattice.git
cd ContextLattice
gmake quickstartСреда выполнения, совместимая с Docker/Compose v2
macOS, Linux или Windows (WSL2)
gmake, jq, rg, python3, curl
cp .env.example .env
ln -svf ../../.env infra/compose/.env
gmake quickstartgmake quickstart запрашивает профиль среды выполнения и запускается с разумными настройками по умолчанию.
При запуске из загрузчика macOS DMG также создаются:
~/ContextLattice/setup/agent_contextlattice_instructions.md (скопировано в буфер обмена)
~/ContextLattice/setup/agent_smoke_write_read.md (проверка записи/чтения оператором)
ORCH_KEY="$(awk -F= '/^CONTEXTLATTICE_ORCHESTRATOR_API_KEY=/{print substr($0,index($0,"=")+1)}' .env)"
curl -fsS http://127.0.0.1:8075/health | jq
curl -fsS -H "x-api-key: ${ORCH_KEY}" http://127.0.0.1:8075/status | jq '.service,.sinks'Профиль | Вариант использования | CPU | RAM | Хранилище |
| Локальное использование на ноутбуке | 2-4 vCPU | 8-12 ГБ | 25-80 ГБ |
| Более высокая пропускная способность и глубокий поиск | 6-8 vCPU | 12-20 ГБ | 100-180 ГБ |
Профиль Glama в одном контейнере предоставляет три инструмента MCP с явной областью действия:
health: проверка готовности/устранение неполадок только для чтения (GET /health), без побочных эффектов.
memory.search: поиск с ограниченным доступом только для чтения (POST /memory/search) с состояниями жизненного цикла (ready|pending|degraded|empty) и опциональными полезными данными для отладки.
memory.write: надежная запись с изменением состояния (POST /memory/write) с явным статусом распределения и полями предупреждений.
Все три инструмента возвращают JSON как в текстовом виде, так и в виде структурированных данных для совместимости с клиентами.
curl -X POST "http://127.0.0.1:8075/memory/write" \
-H "Content-Type: application/json" \
-H "x-api-key: ${ORCH_KEY}" \
-d '{
"projectName": "my_project",
"fileName": "notes/decision.md",
"content": "Switched retrieval_mode to balanced for normal runs.",
"topicPath": "runbooks/retrieval"
}'curl -X POST "http://127.0.0.1:8075/memory/search" \
-H "Content-Type: application/json" \
-H "x-api-key: ${ORCH_KEY}" \
-d '{
"project": "my_project",
"query": "retrieval mode decision",
"topic_path": "runbooks/retrieval",
"include_grounding": true
}'curl -X POST "http://127.0.0.1:8075/memory/search" \
-H "Content-Type: application/json" \
-H "x-api-key: ${ORCH_KEY}" \
-d '{
"project": "my_project",
"query": "full architecture context",
"retrieval_mode": "deep",
"include_grounding": true,
"include_retrieval_debug": true
}'Устанавливайте только то, что необходимо для нормальной работы:
CONTEXTLATTICE_ORCHESTRATOR_URL=http://127.0.0.1:8075
CONTEXTLATTICE_ORCHESTRATOR_API_KEY=<set-by-setup>
NEXTAUTH_URL=http://localhost:3000
NEXTAUTH_SECRET=<long-random-secret>
APP_URL=http://localhost:3000Для получения полной справки по конфигурации используйте .env.example.
UI: http://127.0.0.1:3000/console
Интеллект-карта: http://127.0.0.1:3000/mindmap
Статус: http://127.0.0.1:3000/status
Этот репозиторий отслеживает публичную бесплатную ветку (v3.x).
Расширенная премиум-настройка, проприетарная политика оптимизации и документация по частной коммерциализации находятся вне этой публичной ветки.
Документация на сайте: https://contextlattice.io/
Индекс локальной документации: docs/
Развертывание Hugging Face lite: docs/huggingface-space-lite.md
Apache 2.0. См. LICENSE.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| queue | No | |
| status | No | |
| services | No | |
| components | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the non-destructive nature, the JSON envelope fields (status/services/components/queue), and the auth failure behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a clear purpose: stating the tool's nature, providing usage guidance, describing the return format, and noting an edge case. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a health check tool with no parameters and an existing output schema, the description explains the return format and distinguishes the auth failure case. It fully covers the necessary context given the tool's simplicity and the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is 100%. The description does not need to add parameter meaning. Baseline 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a non-destructive runtime health check, specifically for use before memory tool calls. It distinguishes itself from sibling tools (memory.search, memory.write) by focusing on readiness and connection validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: when a connection fails, startup seems incomplete, or readiness evidence is needed before writes. Also describes the auth failure scenario, indicating when not to expect a successful health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language retrieval query describing what context is needed now. Keep it specific to improve ranking and reduce continuation work. | |
| project | Yes | Project identifier to scope retrieval (for example: contextlattice, algotraderv2_rust). Unknown projects can return project_suggestions. | |
| agent_id | No | Optional stable agent identity used to apply retrieval profile defaults (mode/sources/escalation/query expansion). | |
| topic_path | No | Optional topic hierarchy for scoped retrieval (for example: runbooks/release). Omit for broader recall when scoped reads return empty/degraded. | |
| include_grounding | No | When true, response includes a grounding object with factual snippets and strict numeric copies for citation-safe reasoning. | |
| include_retrieval_debug | No | When true, response includes retrieval debug details (source policy, timings, staged continuation, failures/timeouts). |
| Name | Required | Description |
|---|---|---|
| results | No | |
| degraded | No | |
| warnings | No | |
| grounding | No | |
| retrieval | No | |
| result_state | No | |
| source_status | No | |
| source_summary | No | |
| retrieval_lifecycle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds: read-only nature, lifecycle handling (result_state with ready/pending/degraded/empty), grounding behavior (strict numeric copy), debug payload size impact, auth failure returns isError. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (parameter interactions, lifecycle handling). May be slightly verbose but every sentence adds value. Front-loaded with purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return states and error handling. Covers all parameter interactions, lifecycle, and failure modes. Complete for a complex retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description adds significant context beyond schema: topic_path for scoped retrieval with retry guidance, include_grounding strict copy behavior, include_retrieval_debug diagnostic value and payload cost, agent_id for profile consistency. Greatly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'retrieval', specific resource 'memory', read-only nature stated upfront. Explicitly distinguishes from siblings: 'Do not use this tool for writes or health checks: use memory.write for persistence and health for startup/readiness checks.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (pre-inference recall) and when-not-to-use (writes/health). Offers detailed guidance on parameter usage: aligning project with prior writes, retry logic for topic_path, agent_id stability. Directly names alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Memory payload to persist. Keep numeric facts verbatim. Secret handling follows server policy (redact/block/allow). | |
| fileName | Yes | Logical memory filename/path used for grouping and lookup (for example: notes/codex/xyz.md). Keep stable across updates to preserve continuity. | |
| topicPath | No | Optional topic hierarchy for retrieval scoping (for example: runbooks/runtime-hardening). If omitted, topic is derived from fileName. | |
| projectName | Yes | Project identifier for the write (must match intended retrieval scope and future search project). |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| fanout | No | |
| deduped | No | |
| event_id | No | |
| warnings | No | |
| latest_hash_unchanged | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only false hints), so the description carries the burden. It discloses asynchronous side effects (fanout/indexing/rollup), acceptance semantics (ok=true with event_id but pending fanout), and error behavior (isError=true with structured payload). This far exceeds the minimal annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into purpose, parameter interactions, side effects, usage exclusions, and error behavior. Every sentence contributes essential context, with no fluff or repetition. It is appropriately sized for a tool with async side effects and parameter interdependencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (state change, async fanout, error handling), the description covers purpose, parameters, side effects, when-not-to-use, and return semantics even though an output schema exists. It fully complements the structured information and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: projectName must match memory.search project, fileName is the lineage key for continuity/dedupe, topicPath controls partitioning and derivation, and content should be concise/factual. This enriches the raw schema with actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'State-changing durable memory write used for checkpoints, implementation decisions, and compact recall artifacts,' which clearly states the action (write), resource (durable memory), and intended use cases. It also distinguishes from siblings by explicitly directing to memory.search for reads and health for diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for checkpoints, implementation decisions, and recall artifacts. It also gives clear when-not-to-use instructions: 'Do not use this for retrieval or diagnostics: use memory.search for reads and health for readiness checks.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v4.0.6memory.writev4.0.4memory.writeScored 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.
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Cross-tool persistent memory and context for AI assistants over MCP.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
