Alpha — 機能実装済み、テスト済み。v1.0までは破壊的変更が行われる可能性があります。
問題 | Kremisの解決策 |
ハルシネーション | すべての結果は実際に取り込まれた信号に遡れる。データがない場合は明示的に「見つかりません」と返し、決して捏造しない |
不透明性 | 完全に検証可能なグラフ状態。隠れたレイヤーやブラックボックスは存在しない |
根拠の欠如 | 事前ロードされた知識はゼロ。すべての構造は仮定ではなく、実際の信号から生まれる |
非決定性 | 同じ入力には同じ出力。ランダム性やコアでの浮動小数点演算は一切なし |
データ損失 |
|
設計哲学 — なぜこれらの制約が存在するのか。
Related MCP server: tero-mcp-lite
決定論的なグラフエンジン — 純粋なRust製、コアに非同期処理なし、浮動小数点演算なし。同じ入力は常に同じ出力を生成する
CLI + HTTP API + MCPブリッジ — ターミナル、REST、AIアシスタントという3つのインターフェースを同一エンジンで提供
BLAKE3ハッシュ化 — グラフ状態全体の暗号学的ハッシュにより、いつでも整合性を検証可能
カノニカルエクスポート (KREX) — 出所証明、監査証跡、再現性のための決定論的なバイナリスナップショット
知識の埋め込みゼロ — Kremisは空の状態で開始される。すべてのノードは実際の信号から生成される
ACID永続化 — デフォルトのredbバックエンドによるクラッシュ耐性のあるトランザクション
Claude、Cursor、またはMCP互換のアシスタントに検証可能なメモリ層を提供します。Kremisは事実をグラフノードとして保存し、エージェントがクエリを行うと、すべての回答が実際のデータポイントに遡って追跡されます。埋め込みや確率的な取得は行いません。
データをインジェストし、LLMに主張を生成させ、その各主張をグラフと照らし合わせて検証します。Kremisはすべてのステートメントを [FACT] または [NOT IN GRAPH] とラベル付けします。信頼スコアや曖昧さは存在しません。
グラフ全体を決定論的なバイナリスナップショットとしてエクスポートし、BLAKE3ハッシュを計算して、いつでも整合性を検証できます。すべてのノードは、それを生成した信号にリンクされています。どのようなデータがいつ存在したかを証明する必要があるコンプライアンスワークフローに役立ちます。
いくつかの事実を取り込み、LLMに主張を生成させ、Kremisがそれぞれを検証します：
[FACT] Alice is an engineer. ← Kremis: "engineer"
[FACT] Alice works on the Kremis project. ← Kremis: "Kremis"
[FACT] Alice knows Bob. ← Kremis: "Bob"
[NOT IN GRAPH] Alice holds a PhD from MIT. ← Kremis: None
[NOT IN GRAPH] Alice previously worked at DeepMind. ← Kremis: None
[NOT IN GRAPH] Alice manages a team of 8. ← Kremis: None
Confirmed by graph: 3/6
Not in graph: 3/63つの事実は根拠あり。3つは捏造。曖昧さは一切なし。
python examples/demo_honesty.py # mock LLM (no external deps)
python examples/demo_honesty.py --ollama # real LLM via OllamaRust 1.89+ と Cargo が必要です。
git clone https://github.com/TyKolt/kremis.git
cd kremis
cargo build --release
cargo test --workspacecargo run -p kremis -- init # initialize database
cargo run -p kremis -- ingest -f examples/sample_signals.json -t json # ingest sample data
cargo run -p kremis -- server # start HTTP server別のターミナルで：
curl http://localhost:8080/health
curl -X POST http://localhost:8080/query \
-H "Content-Type: application/json" \
-d '{"type":"lookup","entity_id":1}'注意: CLIコマンドとHTTPサーバーを同時に実行することはできません（
redbが排他的ロックを保持するため）。CLIコマンドを使用する前にサーバーを停止してください。
docker build -t kremis .
# MCP server (default) — pipe MCP stdio JSON-RPC; suitable for any MCP client
docker run -i --rm kremis
# HTTP API only — override the entrypoint
docker run -d -p 8080:8080 -v kremis-data:/data \
--entrypoint kremis kremis server -H 0.0.0.0 -D /data/kremis.dbコンポーネント | 説明 |
kremis-core | 決定論的なグラフエンジン（純粋なRust、非同期なし） |
apps/kremis | HTTPサーバー + CLI (tokio, axum, clap) |
apps/kremis-mcp | AIアシスタント用MCPサーバーブリッジ (rmcp, stdio) |
内部構造（データフロー、ストレージバックエンド、アルゴリズム、エクスポート形式）については、アーキテクチャドキュメントを参照してください。
完全なリファレンスは kremis.mintlify.app にあります：
トピック | リンク |
はじめに | |
インストール | |
クイックスタート | |
設定 | |
CLIリファレンス | |
APIリファレンス | |
MCPサーバー | |
哲学 |
cargo test --workspace
cargo clippy --all-targets --all-features -- -D warnings
cargo fmt --all -- --checkCIランナー上で自動生成 — 2026-05-10
操作 | Linux | Windows | macOS |
ノード挿入 (100K) | 21.30 ms | 22.06 ms | 18.67 ms |
信号インジェスト (10Kバッチ) | 6.98 ms | 9.78 ms | 8.12 ms |
グラフ走査 (深さ50, 1Kノード) | 2.6 µs | 3.1 µs | 2.3 µs |
最強パス (1Kノード) | 7.6 µs | 8.7 µs | 6.1 µs |
カノニカルエクスポート (1Kノード) | 68.2 µs | 74.4 µs | 56.6 µs |
カノニカルインポート (10Kノード) | 3.09 ms | 3.97 ms | 3.38 ms |
Redbノード挿入 (1K) | 358.19 ms | 14.6 s | 489.02 ms |
docs/logo/ 内のブランド資産（ロゴ、アイコン、ファビコン）はプロプライエタリであり、Apache 2.0ライセンスの対象外です。docs/logo/LICENSE を参照してください。
ガイドラインについては CONTRIBUTING.md を参照してください。アーキテクチャは現在も進化中です。PRを提出する前に issue を開いてください。
このプロジェクトはAIの支援を受けて開発されました。
Produce a Verifiable Query Certificate for an entity lookup: a reproducible proof of a fact, or a proof of absence when the entity is not in the graph
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | The entity ID to certify (proves a fact, or proves absence) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the output (certificate) but does not disclose whether the operation is read-only, if it requires special permissions, or what happens on concurrent requests. More detail is needed for a production tool.
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 a single, well-structured sentence that conveys all essential information without unnecessary words. It efficiently defines the tool's purpose and functionality.
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 has only one parameter, no output schema, and no annotations, the description adequately covers the purpose and two main outcomes. However, it could benefit from clarifying what a 'Verifiable Query Certificate' is for users unfamiliar with the concept.
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% for the single parameter 'entity_id', and its schema description aligns with the tool description. The main description adds minimal extra meaning beyond the schema, so baseline 3 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 produces a 'Verifiable Query Certificate' for entity lookup, specifying two use cases: proof of fact or proof of absence. This distinguishes it from sibling tools like kremis_lookup which likely perform simple data retrieval.
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?
The description implies usage for obtaining verifiable certificates but does not explicitly state when not to use it or mention alternative tools (e.g., kremis_lookup for non-certified data). The context is clear but lacks explicit exclusions or guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the canonical BLAKE3 hash of the current graph state
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read operation but does not disclose performance, determinism, or any constraints beyond the obvious. Minimal behavioral context for a zero-parameter tool.
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?
Single sentence, no wasted words, front-loaded with the key action and result. Ideal conciseness for such a simple tool.
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 tool with zero parameters and no output schema, the description fully covers what it does and what it returns. No additional context is needed for safe invocation.
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?
No parameters; schema coverage is 100%. Description adds value by specifying the hash algorithm (BLAKE3) and its scope ('canonical' and 'current graph state'), which goes beyond the empty schema.
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?
Clearly states the verb 'Get', the specific resource 'canonical BLAKE3 hash', and the context 'current graph state'. Distinguishes from all sibling tools, which perform other operations.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions. The description is only a single purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an entity or relation to the Kremis knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value for this attribute | |
| attribute | Yes | The attribute name (e.g. 'name', 'type', 'connected_to') | |
| entity_id | Yes | The entity ID (numeric identifier) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description provides minimal behavioral info. 'Add' implies mutation but doesn't explain idempotency, error handling, or effects on existing data. Entity creation vs property addition is unclear.
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?
Single sentence is concise but lacks necessary detail. Not an example of effective compression; under-specification reduces utility.
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 mutation tool with 3 params and no output schema, description fails to cover behavior like upsert semantics, attribute validation, or relation handling. Sibling tools suggest distinct operations but no context is provided.
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% with descriptions, so baseline is 3. Tool description adds no extra meaning beyond schema. Could explain valid attributes or value formats.
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?
Description states verb 'Add' and resource 'entity or relation' to knowledge graph, distinguishing it from sibling tools like lookup or traverse. However, it's ambiguous whether this creates entities or just adds properties to existing ones.
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?
No guidance on when to use this tool vs alternatives. No explicit context or exclusion criteria. Agent must infer usage from tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find common connections between multiple nodes
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | List of node IDs to find common connections between |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It only states the basic operation without disclosing what 'connections' means (e.g., edges, neighbors), output format, side effects, or error states. Minimal behavioral insight.
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 a single, front-loaded sentence of 8 words. No extraneous information; all words are meaningful and earn their place.
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?
Despite good schema coverage, the description lacks context about return format, what a 'common connection' resolves to, and how it integrates with sibling tools. It is insufficient for an agent to fully understand usage in the graph system.
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% with a description for the 'nodes' parameter. The tool description adds 'common connections', clarifying the operation intent, but does not provide additional parameter syntax or constraints beyond the schema. Baseline 3 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 'Find common connections between multiple nodes' uses a specific verb ('Find') and resource ('common connections'), clearly distinguishing it from sibling tools like kremis_path (path traversal) and kremis_lookup (single node retrieval).
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?
No guidance on when to use this tool versus alternatives like kremis_path or kremis_traverse. No prerequisites, exclusions, or context for when 'common connections' is the appropriate query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an entity in the graph by its entity ID
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | The entity ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'look up' without clarifying whether it is read-only, if the ID must exist, what happens on missing IDs, or any side effects. Minimal disclosure.
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 a single, clear sentence with no redundant information. It is appropriately concise for a simple tool, though it could include a brief note on output without becoming verbose.
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?
The tool has no output schema, so the description should indicate what the lookup returns (e.g., entity properties or existence). It does not mention return value, making the description incomplete for an agent to understand the full behavior.
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 input schema has 100% coverage for the single parameter 'entity_id' (described as 'The entity ID to look up'). The description adds no additional meaning beyond what the schema already provides, so it meets baseline expectations.
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 explicitly states 'Look up an entity in the graph by its entity ID,' clearly identifying the action (look up), resource (entity in graph), and key parameter (entity ID). It is distinct from siblings like 'kremis_traverse' or 'kremis_properties' which imply different operations.
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?
No guidance is provided on when to use this tool versus alternatives such as 'kremis_traverse' or 'kremis_properties'. The description merely states the function without context on limitations, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the strongest weighted path between two nodes
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Ending node ID | |
| start | Yes | Starting node ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of behavioral traits such as algorithm details (e.g., whether it handles cycles), complexity, or semantics of 'strongest' (max vs min weight).
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?
Extremely concise single sentence with no wasted words. However, it lacks structure such as examples or formatting, which could improve usability without significant bloat.
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?
Without an output schema, the description does not explain the return format (e.g., list of nodes, edges, or aggregated weight). Also missing context about graph properties like directed/undirected, making it incomplete for an agent to confidently use.
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 has 100% coverage with descriptions for both parameters, so baseline is 3. Description adds no additional meaning beyond the schema, but it does not introduce confusion.
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?
Description clearly states the tool finds a path between two nodes and specifies 'strongest weighted', indicating optimization. However, it does not differentiate from sibling tool kremis_traverse, which likely also deals with paths.
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?
No guidance on when to use this tool versus siblings like kremis_traverse or kremis_lookup. The description does not mention prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all properties (attributes and values) of a specific node
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The node ID to get properties for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool gets properties but does not mention whether it is read-only, what happens for non-existent nodes, or any side effects. Lacks detail on behavioral traits.
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 a single sentence that directly states the purpose. No unnecessary words, well structured and front-loaded.
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 simple tool with one parameter and no output schema, the description is minimally complete. It tells what the tool does but does not specify return format or behavior for edge cases, which would be helpful.
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% with a single parameter described. The description adds 'attributes and values' which clarifies what 'properties' means, adding value beyond the schema's parameter description.
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 states 'Get all properties... of a specific node', which is a clear verb+resource. However, it does not differentiate from sibling tools like kremis_lookup or kremis_traverse, so it loses some points for lack of unique differentiation.
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?
There is no guidance on when to use this tool versus others, such as when to use kremis_properties vs kremis_lookup. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decrement the weight of an edge between two entities (edge invalidation / signal retraction)
| Name | Required | Description | Default |
|---|---|---|---|
| to_entity | Yes | Target entity ID (the edge destination) | |
| from_entity | Yes | Source entity ID (the edge origin) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description lacks detail on side effects (e.g., decrement amount, behavior if edge missing or weight zero), idempotency, or required permissions.
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?
Single sentence with no wasted words; purpose is front-loaded and immediately clear.
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?
Lacks return value description, error conditions, and edge cases (e.g., what happens when weight reaches zero). More context needed for a mutation tool with no 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?
Schema already describes both parameters clearly (source/target entity IDs). Description adds context of edge invalidation but no additional parameter-level detail, meeting baseline.
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 decrements edge weight for invalidation/retraction, specific verb+resource, and distinguishes from sibling tools like kremis_ingest (add) and kremis_lookup (read).
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?
No usage guidelines provided; no mention of when to use this tool vs alternatives (e.g., deletion) or conditions like edge existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current graph statistics (node count, edge count, density)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('Get') with no destructive side effects. For a simple statistics retrieval, this is adequate, though more detail on consistency or availability could be added.
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 a single, concise sentence that front-loads the purpose and key details. Every word provides value, with no redundancy or unnecessary information.
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 simplicity of the tool (no parameters, no output schema, few siblings), the description is sufficient for an agent to understand the tool's purpose and output. It could mention scope (e.g., entire graph) but overall it is complete enough for selection.
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?
There are zero parameters, and schema coverage is 100% (trivially). The baseline for 0 parameters is 4. The description adds value by specifying the exact statistics (node count, edge count, density) that will be returned, which goes beyond the empty input schema.
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 explicitly states the verb 'Get' and the resource 'current graph statistics', listing specific outputs (node count, edge count, density). This clearly distinguishes it from sibling tools like kremis_hash, kremis_ingest, etc., which operate on different aspects.
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?
The description implicitly suggests using this tool when graph statistics are needed, but it does not explicitly state when to use or not use this tool versus siblings. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Traverse the graph from a node to discover connected entities
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Traversal depth (default: 2, max: 10) | |
| top_k | No | Return only the K highest-weight edges (optional) | |
| node_id | Yes | The starting node ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It lacks details on traversal direction (outgoing/incoming), cycle handling, result formatting, or performance implications. The minimal description 'discover connected entities' is vague.
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 a single concise sentence (9 words) with no fluff. However, given the tool's complexity, a slightly more detailed description might be warranted, but it is still efficiently written.
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?
The tool has 3 parameters, no output schema, and no annotations. The description fails to explain the return value, traversal algorithm behavior, or how depth and top_k interact. This leaves significant gaps for the agent.
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?
All parameters have descriptions in the input schema (100% coverage), so the description adds no extra semantics beyond the schema. The baseline of 3 is appropriate; no additional param context is provided.
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 uses a specific verb 'traverse' and identifies the resource 'graph from a node' and the outcome 'discover connected entities'. It clearly states the tool's function but does not differentiate from sibling tools like kremis_lookup or kremis_path.
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?
No guidance on when to use this tool versus alternatives. The description does not provide context on appropriate use cases or contrast with sibling tools.
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.
v0.19.1kremis_certifyv0.18.2kremis_hashkremis_ingestkremis_intersectkremis_lookupkremis_pathkremis_propertieskremis_retractkremis_statuskremis_traverseScored across 10 tools
Each tool has a clearly distinct purpose: ingest adds data, lookup retrieves entities, properties gets attributes, traverse explores connections, intersect finds common neighbors, path finds weighted paths, retract adjusts edge weights, status shows statistics, hash computes graph hash, and certify produces proofs. No overlapping functionality.
All tools follow the consistent pattern 'kremis_<verb>' with clear action verbs (certify, hash, ingest, intersect, lookup, path, properties, retract, status, traverse), making the naming predictable and easy to understand.
With 10 tools, the server is well-scoped for a knowledge graph management and verification system. Each tool contributes meaningfully without being excessive or insufficient.
The tool set covers essential CRUD-like operations (ingest, lookup, retract), graph traversal and analysis (traverse, intersect, path), statistics, hashing, and certification. Missing explicit update or full delete tools, but these may be intentional given the focus on verifiable proofs and immutable facts.
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.