Skip to main content
Glama
enesjakoruzh
Arin016

context-lattice

by Arin016
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Context Lattice

Context Latticeは、AIコーディングエージェントの会話エクスポートをインデックス化する、スタンドアロンでソース検証可能なメモリインデックスです。Codex、Cursor、Kiro、または自分自身のエージェントが生成したJSONやJSONLを指定すると、履歴全体を次のコンテキストウィンドウで再生する代わりに、コンパクトなエビデンスバンドルを取得できます。

生のレコードは不変です。階層的なサマリーは非可逆で、使い捨てのナビゲーションインデックスです。すべての結果は、ソースファイル、JSONレコード、SHA-256ハッシュに遡ることができます。

クイックスタート

APIキーや外部データベースは必要ありません。Python 3.11+に対応しています。

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

デフォルトでは、データベースは ~/.context-lattice/memory.db に作成されます。--db /path/to/memory.db でオーバーライドします。取り込みは、単一の .json、.jsonl、またはその両方を含むディレクトリツリーを受け付けます。init は、同じデータベースとソースルートを使用して、そのまま貼り付け可能なMCP設定を出力するため、CLIとサーバーの設定のずれを防ぎます。

Related MCP server: logbook

MCPサーバーとしてインストール

Context Latticeは、ローカルstdio MCP上でmemory_search、memory_get、memory_explain、memory_sync、memory_statusを公開します。データベースと明示的なソース許可リストを設定し、MCP対応クライアントをインストール済みの実行ファイルにポイントします。

{
  "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"
      }
    }
  }
}

複数の許可ルートは、プラットフォームのパス区切り文字を使用します（macOS/Linuxでは : 、Windowsでは ; ）。memory_sync は、唯一の変更を行うMCP操作です。検索エビデンスは、信頼できないとして明示的にマークされ、トークン予算に制限され、ソースハッシュに解決できます。docs/MCP.md を参照してください。

入力アダプター

--adapter auto はレコードのエンベロープを調べ、現在次のものを認識します。

  • codex： session_meta と response_item レコードを含むイベントJSONL

  • cursor： メッセージ、バブル、またはターンを含むエクスポートされた会話

  • kiro： メタデーターヘッダーを持つrole/content JSONL

  • claude： ネストされたメッセージブロックを含むClaude CodeプロジェクトJSONL

  • canonical： 安定したContext Lattice v1フォーマット

  • generic： 一般的なrole/content、speaker/text、ネストされたメッセージの形状

プロバイダーのフォーマットは変更される場合があります。Codex、Cursor、Kiroアダプターは意図的に寛容で、フィクトゥールテスト済みですが、保証された統合境界はネイティブスキーマです：schemas/conversation-v1.schema.json を参照してください。最小の完全な例は examples/canonical.json を見てください。

{
  "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"]
    }
  ]
}

認識可能な会話コンテンツを持たないレコードは、スキップとして数えられます。不正なまたは失敗したレコードは、インポート結果に報告され、インポート監査ログに保存されます。同じファイルを再インポートすることは冪等です。

検索モデル

  • イミュータブルな、追加専用の生イベントをSQLiteで

  • 元の生JSONに加えて、ファイル/レコードの来歴とハッシュ

  • 完全一致識別子のためのFTS5/BM25

  • オフラインの特徴ハッシュベースラインを備えた転置スパースポスティングインデックス

  • 固定ファンアウトの時系列サマリーツリー

  • 語彙、セマンティック、階層の候補全体を対象とした相互ランク融合

  • オプションの fact_key 値による訂正チェーン

  • 不一致トリガーによる検索拡張と、信頼度に基づく棄権

  • 明示的な証拠トークン予算と検査可能な検索トレース

インデクサーとリトリーバーは決定論的であり、LLM呼び出しを行いません。バンドルされたセマンティックモデルは特徴ハッシュであるため、移植性があり正確に再現できる一方、学習済み埋め込みモデルよりも弱いです。外部LLMはエビデンスを消費することは可能ですが、メモリインデックスの維持を信頼されません。エンベッダー境界は、エビデンス契約を変更することなく、置き換え可能です。

時系列の階層構造は、セグメントツリーに似たナビゲーションインデックスです。セマンティック検索や語彙検索を代替することはできません。ツリーは時間範囲を刈り込み、FTS5とスパーポスティングは用語と概念を特定します。クエリ際の内積はSQLite内で集約され、境界によって限定されたルートセットとビームだけがツリーを降ります。docs/ARCHITECTURE.md を参照してください。

テストと評価

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?"

決定論的な50問の評価は、(直近のトークンウィンドウ、(最新の)ウィンドウウィンドウ、フラットなベクトル検索、や階層ハイブリッド検索を比較します。answer_accuracy は、エビデンス十分性の指標であり、LLMジャッジスコアではありません。支持 と DESIGN.md を参照してください。

手動でレビューされたgolden-v1スイートは、ソースの再現率、精度、ランキング、クリニア化した結果、サポートされていない事実、引用の整合性、階層ブランチの再現率のリリースゲートです。これは、しきい値が退行した場合に意図的にコマンドを失敗させます。docs/GOLDEN_EVAL.md を参照してください。

本番運用体制

ローカルファーストコアには、会話ごとのアトミックなインデックス更新、WAL並行性、プロセス間メンテナンスロック、ン変更可能なイベント、ソースの検証、入力と検索の制限、入れ子になったシンボリックリンクに安全なMCP許可リスト、スキーマ互換性チェック、CI、決定論的リリースゲートがあります。context-lattice doctor は、データベースの整合性、インデックスの肥大性、FTS5、権限、SQLite、Python、MCPをチェックします。プロバイダーのフォーマットは非公式であり、変更される可能性があります。canonical v1スキーマファイルが安定した統合境界です。ローカルstdio以外のものを公開する前に SECURITY.md を確認してください。

具体的なリリースチェックリストと現在の非チュウゴクは、docs/RELEASE_GATES.md にあります。

Available Tools

5 tools
memory_explainC

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

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
token_budgetNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault
citationYes
include_rawNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

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_statusA

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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

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
NameRequiredDescriptionDefault
pathsNo
adapterNoauto

Output Schema

ParametersJSON Schema
NameRequiredDescription

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.

  1. 5 tool updatesv0.3.0
    • 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 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

Related MCP Connectors

Related MCP Servers

  • chat-history-db

    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.
    -

  • logbook

    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.
    2
    MIT

  • motif-solo

    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.
    Apache 2.0

  • Literature Evidence MCP

    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.
    5
    1
    MIT