ContextLatticeは、過去のプロジェクト作業をシグナルの高い検索可能なコンテキストに変換することで、繰り返される推論を削減します。
専門ストアへのファンアウトを伴う永続的なメモリ書き込み。
ステージングされたフェッチとフェイルオープンな継続機能を備えた、高速かつ詳細な検索モード。
トークン使用量を効率的に保ちつつ、生のアーティファクトへのドリルダウンパスを保持するロールアップファーストなコンテキスト。
オプションのクラウドバックエンド依存関係を備えたローカルファーストなデプロイメント。
HTTP API、MCPトランスポート、および運用ダッシュボードを通じた人間とエージェントのUX。
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バンドル: 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 quickstartDocker/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 | ストレージ |
| ノートPC向けのローカル利用 | 2-4 vCPU | 8-12 GB | 25-80 GB |
| より高いスループットと深いリコール | 6-8 vCPU | 12-20 GB | 100-180 GB |
Glamaシングルコンテナプロファイルは、明示的なスコープを持つ3つのMCPツールを公開します：
health: 読み取り専用の準備状況/トラブルシューティングチェック (GET /health)。副作用なし。
memory.search: ライフサイクル状態 (ready|pending|degraded|empty) とオプションのグラウンディング/デバッグペイロードを備えた、読み取り専用のスコープ付き検索 (POST /memory/search)。
memory.write: 明示的なファンアウトステータスと警告フィールドを備えた、状態を変更する永続的な書き込み (POST /memory/write)。
これら3つのツールはすべて、クライアントの互換性のために、テキストコンテンツと構造化ペイロードの両方の形式で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.
