ContextLattice reduce la inferencia repetida al convertir el trabajo previo del proyecto en contexto recuperable de alta señal.
Escrituras de memoria duraderas con distribución (fanout) a almacenes especializados.
Modos de recuperación rápida y profunda con obtención por etapas y continuación en caso de fallo.
Contexto basado en resúmenes (rollup) para mantener el uso de tokens eficiente mientras se preservan las rutas de desglose hacia artefactos sin procesar.
Despliegue de prioridad local con dependencias opcionales respaldadas en la nube.
UX para humanos y agentes a través de APIs HTTP, transporte MCP y panel de operaciones.
Related MCP server: copilot-memory-store
Capa | Entorno de ejecución principal | Responsabilidad |
Puerta de enlace/API | Go | Orquestación de |
Servicios de recuperación + memoria | Go + Rust | Carriles de recuperación rápida/duradera, manejo de resúmenes, adaptadores de banco de memoria |
Respaldo heredado | Python | Solo respaldo de compatibilidad (no es la ruta principal predeterminada) |
Panel de control | TypeScript/Next.js | Consola, mapa mental, estado, facturación, UX de configuración |
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 quickstartEntorno de ejecución compatible con Docker/Compose v2
macOS, Linux o Windows (WSL2)
gmake, jq, rg, python3, curl
cp .env.example .env
ln -svf ../../.env infra/compose/.env
gmake quickstartgmake quickstart solicita un perfil de ejecución y se inicia con valores predeterminados razonables.
Si se inicia desde el bootstrap DMG de macOS, también genera:
~/ContextLattice/setup/agent_contextlattice_instructions.md (copiado al portapapeles)
~/ContextLattice/setup/agent_smoke_write_read.md (verificación de escritura/lectura del operador)
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'Perfil | Caso de uso | CPU | RAM | Almacenamiento |
| Uso local amigable para portátiles | 2-4 vCPU | 8-12 GB | 25-80 GB |
| Mayor rendimiento y recuperación más profunda | 6-8 vCPU | 12-20 GB | 100-180 GB |
El perfil de contenedor único de Glama expone tres herramientas MCP con alcance explícito:
health: verificación de preparación/solución de problemas de solo lectura (GET /health), sin efectos secundarios.
memory.search: recuperación con alcance de solo lectura (POST /memory/search) con estados de ciclo de vida (ready|pending|degraded|empty) y cargas útiles opcionales de fundamentación/depuración.
memory.write: escritura duradera que cambia el estado (POST /memory/write) con estado de distribución explícito y campos de advertencia.
Las tres herramientas devuelven JSON tanto en formato de texto como en forma de carga útil estructurada para compatibilidad con el cliente.
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
}'Establezca solo lo que necesite para la operación normal:
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:3000Para obtener una referencia completa de la configuración, utilice .env.example.
UI: http://127.0.0.1:3000/console
Mapa mental: http://127.0.0.1:3000/mindmap
Estado: http://127.0.0.1:3000/status
Este repositorio rastrea el carril público gratuito (v3.x).
El ajuste premium avanzado, la política de optimización propietaria y los documentos de comercialización privada viven fuera de este carril público.
Documentos del sitio web: https://contextlattice.io/
Índice de documentos locales: docs/
Despliegue lite en Hugging Face: docs/huggingface-space-lite.md
Apache 2.0. Ver 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.
