en es ja ko ru zh

context-lattice

Name: context-lattice
Author: Arin016

by Arin016

Overview Schema Source Related Servers Discussions Admin

Python

Local

Context Lattice es un índice de memoria independiente y verificable de fuentes para exportaciones de conversaciones de agentes de codificación de IA. Apúntalo a JSON o JSONL producidos por herramientas como Codex, Cursor, Kiro o tu propio agente, y obtén un paquete compacto de evidencia en lugar de volver a reproducir todo el historial en la siguiente ventana de contexto.

Los registros originales permanecen inmutables. Los resúmenes jerárquicos son índices de navegación con pérdida y desechables. Cada resultado remite al archivo fuente, al registro JSON y al hash SHA-256.

Inicio rápido

No se requiere clave de API ni base de datos externa. Python 3.11+ es compatible.

cd /path/to/context-lattice
python3 -m pip install -e .

context-lattice init --root ~/exports/coding-sessions/
context-lattice ingest ~/exports/coding-sessions/
context-lattice query "Why did we change the retry policy?"
context-lattice query "What is the latest payment reference?" --json --debug
context-lattice inspect
context-lattice verify
context-lattice doctor

De forma predeterminada, la base de datos se crea en ~/.context-lattice/memory.db. Puedes sobrescribirla con --db /path/to/memory.db. La ingesta acepta un único .json, un .jsonl o un árbol de directorios que contenga ambos. init imprime una configuración MCP lista para pegar con la misma base de datos y las mismas raíces de fuentes, evitando así la desviación de configuración entre CLI y servidor.

Related MCP server: logbook

Instalar como servidor MCP

Context Lattice expone memory_search, memory_get, memory_explain, memory_sync y memory_status a través de MCP local por stdio. Configura la base de datos y una lista de fuentes permitidas explícita, y después apunta cualquier cliente compatible con MCP al ejecutable instalado:

{
  "mcpServers": {
    "context-lattice": {
      "command": "context-lattice-mcp",
      "env": {
        "CONTEXT_LATTICE_DB": "/absolute/path/to/memory.db",
        "CONTEXT_LATTICE_ALLOWED_ROOTS": "/absolute/path/to/agent/sessions"
      }
    }
  }
}

Cuando hay varias raíces permitidas se usa el separador de rutas de la plataforma (: en macOS/Linux, ; en Windows). memory_sync es la única operación MCP que altera datos. La evidencia de búsqueda se marca explícitamente como no confiable, está acotada por un presupuesto de tokens y se puede resolver hasta los hashes de fuente. Consulta docs/MCP.md.

Adaptadores de entrada

--adapter auto examina los envoltorios de los registros y actualmente reconoce:

codex: JSONL de eventos que contiene registros session_meta y response_item;
cursor: conversaciones exportadas que contienen mensajes, burbujas o turnos;
kiro: JSONL de role/content con encabezado de metadatos;
claude: JSONL de proyectos de Claude Code con bloques de mensajes anidados;
canonical: el formato estable de Context Lattice v1;
genérico: formas comunes de role/content, speaker/text y mensajes anidados.

Los formatos de los proveedores pueden cambiar. Los adaptadores de Codex, Cursor y Kiro son intencionadamente tolerantes y están probados con fixtures, pero el esquema canónico es el límite de integración garantizado: schemas/conversation-v1.schema.json. Consulta examples/canonical.json para ver el ejemplo completo más pequeño.

{
  "schema": "context-lattice/v1",
  "conversation_id": "release-planning",
  "messages": [
    {
      "role": "user",
      "content": "The deployment region is ap-south-1.",
      "timestamp": "2026-08-20T10:00:00Z",
      "fact_key": "deployment-region",
      "entities": ["ap-south-1"]
    }
  ]
}

Los registros sin contenido conversacional reconocible se cuentan como omitidos. Los registros malformados o con errores se informan en el resultado de la importación y se guardan en el registro de auditoría de importación. Reimportar el mismo archivo es idempotente.

Modelo de recuperación

eventos originales inmutables y de solo anexión en SQLite;
JSON original sin procesar más la procedencia del archivo/registro y los hashes;
FTS5/BM25 para identificadores exactos;
un índice invertido de postings dispersos con una línea base offline de hashing por características;
árboles de resumen cronológicos de aridad fija;
fusión de rango recíproco entre candidatos léxicos, semánticos y jerárquicos;
cadenas de corrección mediante valores opcionales fact_key;
expansión de búsqueda activada por desacuerdos y abstención basada en confianza;
presupuestos explícitos de tokens de evidencia y trazas de recuperación inspeccionables.

El indexador y el recuperador son deterministas y no realizan llamadas a LLM. El modelo semántico incluido es hashing por características, por lo que es portable y exactamente reproducible, aunque más débil que un modelo de embeddings aprendido. Un LLM externo puede consumir la evidencia; no se le confía el mantenimiento del índice de memoria. El límite del embedder puede reemplazarse sin cambiar el contrato de evidencia.

La jerarquía cronológica es un índice de navegación similar a un árbol de segmentos. No puede sustituir a la búsqueda semántica ni a la léxica: los árboles recortan rangos de tiempo, mientras que FTS5 y los postings dispersos localizan términos y conceptos. Los dot product en el momento de la consulta se agregan dentro de SQLite, y solo un conjunto raíz acotado y un haz descienden por el árbol. Consulta docs/ARCHITECTURE.md.

Probar y evaluar

python3 -m unittest discover -s tests -v
python3 -m context_lattice.cli eval --output benchmark-results.json
python3 -m context_lattice.cli golden-eval --output golden-results.json
python3 -m context_lattice.cli demo \
  "What is the current meeting room for team-3?"

La evaluación determinista de 50 preguntas compara una ventana de tokens recientes, un resumen continuo, la búsqueda vectorial plana y la recuperación híbrida jerárquica. Su answer_accuracy es una métrica de suficiencia de la evidencia, no una puntuación de un juez LLM. Consulta benchmark-results.json y DESIGN.md.

El conjunto golden-v1 revisado manualmente es la puerta de lanzamiento para la recuperación de fuentes, la precisión, la clasificación, los hechos obsoletos, los resultados sin respaldo, la integridad de las citas y la recuperación de ramas de la jerarquía. Hace fallar el comando intencionadamente cuando los umbrales experimentan una regresión. Consulta docs/GOLDEN_EVAL.md.

Postura de producción

El núcleo local-first incluye actualizaciones atómicas del índice por conversación, concurrencia WAL, bloqueo de mantenimiento entre procesos, eventos inmutables, verificación de fuentes, entradas y recuperación acotadas, listas de permitidos MCP seguras frente a enlaces simbólicos anidados, comprobaciones de compatibilidad de esquema, CI y puertas de lanzamiento deterministas. context-lattice doctor comprueba la integridad de la base de datos, la vigencia de los índices, FTS5, los permisos, SQLite, Python y MCP. Los formatos de los proveedores siguen siendo no oficiales y pueden cambiar; el esquema canónico v1 es el límite de integración estable. Revisa SECURITY.md antes de exponer cualquier cosa más allá del stdio local. La lista de verificación de lanzamiento concreta y los no objetivos actuales están en docs/RELEASE_GATES.md.

Available Tools

5 tools

memory_explainC

Search memory and include deterministic routing, fusion, and abstention diagnostics.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`token_budget`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description ''carries the full burden of disclose behavioral traits. 'Search memory' implies a read-only action, but the description does not explicitly state whether it unmutated or requires permissions, nor does it explain the nature of the diagnostics beyond jargon. The behavioral disclosure is insufficient for a tool with no annotatons.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise, front-loaded sentence with no wasted wording or filler. It could use more depth, but that is a completeness issue rather than a conciseness or structure failure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though there is an output schema, the description does not establish the key context: why anyone would choose this over memory_search, what "deterministic routing, fusion, and abstention" means in practitioner terms, or what behavioral tradeoffs come. For a specialized diagnostics tool with no annotations or clear parameter docs, this definition is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needs to compensate for the three parameters explain. 'Query', 'limit', and 'token_budget' are not mentione, and 'token_budget' especially is not self-explaning. The description does not become more contribution for the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Search memory') and a scope ('include deterministic routing, fusion, and abstention diagnostics'), which makes it distinguishable from sibling memory_search. It is clear enough but does not explicitly name or contrast the sibling tools, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The diagnostics wording implies the tool is for explaining or debugging memory retrieval decisions, but the description never explicitly says when to use this over memory_search, memory_get, or memory_sync, nor does it provide any exclusions or alternatives. Usage guidance is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_getB

Resolve one Context Lattice citation and verify it against its original source file.

ParametersJSON Schema

Name	Required	Description	Default
`citation`	Yes
`include_raw`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description anues "verify" against its original sourcefile, a non-obvious behavior that says the tool checks correctness and isn't just a raw accessor. It does not state outverification failures, permissions, or side effects, so the behavior is only partially disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted or repeated information. It fronts the main action and adds only the verification detail in the second clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but missing include_raw semantics and the format/form of a citation means the agent cannot safely choose correct arguments. The output schema may explain return but no the input field, and no annotation compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only clarifies that the citation targets a Context Lattice item. It does not describe include_raw, its default, or its effect, so an agent is left to guess how to request the raw variant. This is a significant gap for a two-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific action—resolving a single Context Lattice citation—and an additional verification behavior, which separates this from a plain search or sync operation. It does not fully demes multiple beats "Context Lattice" and "original source file" due to jargon, so no full 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is used when you already have a citation to resolve, rather than when searching or syncing. It never explicitly contrasts with siblings or explains when not to use it; the intended spot in a generate pipeline is inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_searchA

Search durable coding-agent memory and return bounded, untrusted, cited evidence.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`token_budget`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears the full burden and meaningfully warns that results are 'bounded and untrusted' and that the tool returns citations. That adds real behavioral context beyond the name and schema, though it does not explicitly state whether search mutates memory or what boundedness means in operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence with no filler. Every phrase earns its place: the resource, the search operation, and the caveats on returned evidence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and the description gives the most important search-relevant caveat: evitable. However, with zero parameter coverage in the schema and no usage routing among siblings, the description is adequate but not complete enough for robust agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never names or explains query, limit, or token_budget. 'Bounded' slightly hints at limits/token caps but does not map to specific parameters, leaving the required query and both optional controls semantically under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Search', identifies the resource as 'durable coding-agent memory', and states the return shape as 'bounded, untrusted, cited evidence'. This distinguishes memory_search from siblings such as memory_get or memory_explain, whose names imply other operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The task context is implied: use it when you need to search memory and retrieve cited evidence. However, it never explicitly contrasts this with memory_get, memory_explain, or other siblings, so the agent is left to infer when one should be preferred over another.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_statusA

Report corpus, schema, index model, and allowed-source health without message content.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, this description carries the burden of transparency. It explicitly discloses that the tool does not report message content, which is an important behavioral boundary. The verb 'Report' also implies a non-mutating, observability-focused behavior despite no readOnlyHint annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tight sentence with no filler. The key scope ('corpus, schema, index model, and allowed-source health') appears before the clarifying exclusion, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters and has an output schema, the description provides all needed selection context: what health areas are reported and what is explicitly excluded. There is no missing information that would prevent an agent from invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so no semantic contribution is required from the description. The schema fully covers the empty parameter set, meeting the baseline for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Report') with a specific resource: corpus, schema, index model, and allowed-source health. The added 'without message content' clause disambiguates it from memory_search and memory_get, which would return content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: this is a health/status tool, and the 'without message content' phrasing tells an agent not to use it when message content is needed. It does not explicitly name alternatives or contain a formal when-not-to-use rule, so it is slightly short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_syncB

Incrementally ingest allowed agent-session roots and atomically update affected indexes.

ParametersJSON Schema

Name	Required	Description	Default
`paths`	No
`adapter`	No		auto

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral detail. It does disclose 'incrementally ingest' and 'atomically update affected indexes', which is useful, but it doesn't explain side effects, failure behavior, permissions, idempotency, or what 'allowed' means in practice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no fluff. The core action 'incrementally ingest and atomically update' is clear and front-loaded, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, undocumented parameters, and multiple siblings, it is under-specified. It omits usage direction, parameter semantics, and behavior side effects; the output schema helps but doesn't make up for those gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the paths and adapter parameters. It doesn't name either parameter or explain what paths and adapter expect, nor how they affect synchronization.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly specifies a distinct operation: incrementally ingest allowed agent-session roots and atomically update indexes. This distinguishes it from the read-oriented sibling tools memory_search, memory_get, memory_explain, and memory_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to call this tool, when not to call it, or how it relates to memory_search and memory_get. The only contexts is inferred from the phrase 'sync', but the description never says when synchronization should be triggered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.3.0Aug 25, 2026
- First observedmemory_explain
- First observedmemory_get
- First observedmemory_search
- First observedmemory_status
- First observedmemory_sync

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.5/5.0

Scored 2026-08-25 18:05 across 5 tools

Disambiguation4/5

The tools are mostly distinct in purpose: search returns evidence, get resolves a specific citation, explain adds diagnostics, sync ingests data, and status reports health. The only meaningful overlap is between memory_search and memory_explain, since both perform searches, but their different outputs make the distinction usable.

Naming Consistency4/5

All tools share the consistent memory_ prefix and lower_snake_case convention. The minor deviation is memory_status, which names a state rather than an action, while the other four tools use memory_ followed by a verb-like operation.

Tool Count5/5

Five tools is a well-scoped number for a memory/context server. Each tool covers a distinct part of the workflow: search, resolution, explanation, sync, and status.

Completeness4/5

The surface covers the core memory lifecycle: retrieval, verification, diagnostics, ingestion, and health monitoring. There is no explicit delete/forget or curation operation, but this is a minor gap because memory appears to be source-backed and managed through the sync tool.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Agent Evidence API A
io.github.Thx93
MCP-native web evidence and claim verification: cited, source-grounded evidence for AI agents.
Search Web Scraping RAG Systems
1
AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
Tillpad A
com.cnrcode
Bounded KVP, RAG search, and wipe receipts for agent jobs over remote MCP
Agent Orchestration RAG Systems Knowledge & Memory
1811
library A
com.siftdex
Verified doc corpora for agents: grep-first retrieval, hashed pages, Merkle+RFC-3161 receipts
Search Documentation Access RAG Systems
2

Related MCP Servers

chat-history-db
Knowledge & Memory RAG Systems
ThinkofRain1213
F
license
Not graded
quality
F
maintenance
Enables AI coding agents to persistently store and retrieve conversation history with hybrid semantic and keyword search, cross-encoder reranking, session filtering, and archiving through MCP tools.
Updated a month ago (2026-09-12 12:12 UTC)
-
logbook
Knowledge & Memory Search Developer Tools
olly-styles
A
license
Not graded
quality
B
maintenance
Provides full-text search and retrieval of archived Claude Code session transcripts, enabling agents to inspect past sessions without loading entire transcripts.
Updated 6 days ago (2026-10-07 20:18 UTC)
2
MIT
motif-solo
Knowledge & Memory RAG Systems Code Analysis
motif-Labs
A
license
Not graded
quality
C
maintenance
Enables coding agents to retrieve a bounded context packet linking relevant code with prior session evidence, decisions, failures, and fixes from local Codex and Claude Code history.
Updated 19 days ago (2026-09-24 03:45 UTC)
Apache 2.0
Literature Evidence MCP
Research & Data RAG Systems
phy-zhangzl
A
license
A
quality
C
maintenance
Enables local-first, versioned evidence retrieval from papers without loading the whole library into a conversation, with optional Zotero, writing, fixed-commit code, and experiment record integration returning bounded excerpts and page images.
Updated 24 days ago (2026-09-19 08:00 UTC)
5
1
MIT