Kremis is a deterministic knowledge graph server for storing, querying, and verifying factual data without hallucination, with cryptographic audit trails.
kremis_ingest: Add entities and relations (attributes) to the knowledge graph.
kremis_lookup: Retrieve an entity by its numeric ID, returning stored facts or an explicit "not found" response.
kremis_properties: Fetch all attributes and values associated with a specific node.
kremis_traverse: Explore connected entities from a starting node, with configurable depth (up to 10) and optional top-K highest-weight edge filtering.
kremis_path: Find the strongest weighted path between two nodes.
kremis_intersect: Identify shared connections between multiple nodes simultaneously.
kremis_retract: Decrement an edge's weight to invalidate or weaken a previously ingested signal.
kremis_hash: Retrieve the canonical BLAKE3 cryptographic hash of the current graph state for integrity and provenance verification.
kremis_status: Get graph statistics including node count, edge count, and density.
Allows validating LLM-generated claims against the knowledge graph using Ollama's local LLM inference, labeling statements as fact or not found.
Alpha — Functional and tested. Breaking changes may still occur before v1.0.
Problem | How Kremis addresses it |
Hallucination | Every result traces back to a real ingested signal. Missing data returns explicit "not found" — never fabricated |
Opacity | Fully inspectable graph state. No hidden layers, no black box |
Lack of grounding | Zero pre-loaded knowledge. All structure emerges from real signals, not assumptions |
Non-determinism | Same input, same output. No randomness, no floating-point arithmetic in core |
Data loss | ACID transactions via |
Design Philosophy — why these constraints exist.
Related MCP server: Memory Store
Deterministic graph engine — Pure Rust, no async in core, no floating-point. Same input always produces the same output
CLI + HTTP API + MCP bridge — Three interfaces to the same engine: terminal, REST, and AI assistants
BLAKE3 hashing — Cryptographic hash of the full graph state for integrity verification at any point
Canonical export (KREX) — Deterministic binary snapshot for provenance, audit trails, and reproducibility
Proof-carrying knowledge (KVQC) — POST /certify returns a reproducible Verifiable Query Certificate: a portable proof of a fact, or proof of its absence
Zero baked-in knowledge — Kremis starts empty. Every node comes from a real signal
ACID persistence — Default redb backend with crash-safe transactions
Give Claude, Cursor, or any MCP-compatible assistant a verifiable memory layer. Kremis stores facts as graph nodes — the agent queries them, and every answer traces back to a real data point. No embeddings, no probabilistic retrieval.
Ingest your data, let an LLM generate claims, then check each claim against the graph. Every response carries a grounding field — fact, inference, or unknown — and POST /certify turns an unknown into a certificate bound to a BLAKE3 hash of the graph state. No confidence scores, no ambiguity.
Export the full graph as a deterministic binary snapshot, compute its BLAKE3 hash, and verify integrity at any point. Every node links to the signal that created it. Useful for compliance workflows where you need to prove what data was present and when.
A closed registry of 9 fictional services and 5 one-way dependencies. 24 questions of
the form "does A depend on B, directly or transitively?" — 8 have an answer, 16 do
not, and no answer exists for them anywhere. Nothing in the prompt asks any model to
invent: the facts are supplied and UNKNOWN is offered.
qwen3.5:4b, temperature 0, 5 runs:
System | False assertion | Answer accuracy |
Kremis ( | 0.00 % | 100 % |
LLM holding the entire registry | 0.00 % | 100 % |
LLM + naive retrieval | 0.00 % | 75 % |
LLM, no context | 0.00 % | 0 % |
On a world this small a capable model does not fabricate: given every fact it needs,
qwen3.5:4b matches the substrate here, answering all 8 answerable questions and
abstaining on the 16 that have no answer. But capability is not free with the year on the
model card — phi4-mini, a current local 4B from another lab, holds the identical
registry and still asserts marn-ledger -> quoll-auth, the reverse of a stated
dependency, on every run (12.50 %). Which model you run already decides it. Kremis stores
dependencies as one-way edges, so a reverse path is not there to find: it returns
grounding: "unknown" and /certify issues a certificate carrying no evidence, bound to
a BLAKE3 hash of the graph state. The zero is structural, not measured — and the
interesting failure is the long horizon below.
It is also not a like-for-like race, and should not be read as one. The LLM gets
English and has to find the services itself; Kremis gets strongest_path(42, 87) with
the ids already resolved. A graph of one-way edges cannot fabricate an edge — saying so
proves nothing. What is not free is the certificate: an absence bound to a hash, which
someone else can check without trusting the system that issued it.
The bottom row is the control: a model that answers UNKNOWN to everything fabricates
nothing and is useless. Abstention counts only alongside accuracy.
python benchmark/run.py --model qwen3.5:4b --runs 5
python benchmark/run.py --skip-llm # Kremis alone, no Ollama neededSo on the lookup the capable models (qwen3.5:4b, gemma4) score 0 while a weaker
current 4B (phi4-mini) still invents. The base world separates capable from weak — so
the benchmark ships a second one, where the answer no longer fits in a glance and even
the capable models start to fail.
420 services, 330 one-way dependencies, and the answer is a composition of up to 10
steps. The 60 questions with no answer come in two traps, 30 each: a chain with exactly
one link withheld (N-1 of the N links stated, one missing — no chain), and an intact
chain asked backwards (dependencies are one-way, so the reverse has no answer). The
model is handed all 330 dependencies anyway — what is missing is missing in the world,
not in the context.
Temperature 0, 60 questions with no answer, each model holding the entire registry:
Two local models you would actually run, two hosted at the extremes of the frontier:
System | False assertion | Answer accuracy |
Kremis ( | 0.00 % | 100 % |
| 0.00 % | 100 % |
| 3.33 % | 20 % |
| 1.67 % | 6.67 % |
| 61.67 % | 100 % |
Read the second row before the last. As of July 2026 a frontier model matches Kremis on every column of this benchmark — so "LLMs fabricate and Kremis doesn't" is not a claim this project makes in the present tense. What is left is narrower: that zero is one execution, and it arrives with nothing you can check. Kremis's is a property of a graph of one-way edges, and it certifies all 60 absences against a BLAKE3 state hash.
Capability is also not uniform — llama-3.3-70b (Meta, via NVIDIA) invents 37 of the
60 chains while answering every real one, and the two local 4B models fabricate less but
still fabricate (qwen3.5:4b 3.33 %, phi4-mini 1.67 %) while answering almost nothing.
None of them gives you a way to tell which answer you just got.
One caveat is ours, not theirs: 420 services is ~6.6k tokens, so the whole world fits
in the prompt. That is the single regime where an LLM can compete on this task at all.
--scale leaves it — the questions stay identical and only the prompt grows.
And it matters. At --scale 3000 (57k prompt tokens) gemma4 fabricates 1 / 60
where it fabricated 0 / 60 at the default size; the local qwen3.5:4b at
--scale 500 instead answers fewer questions (accuracy 20 % → 13.33 %) without inventing
more. The LLMs move with scale, in different directions; the parity in the table above is
a property of a small world, not of the model. Kremis is 0 / 60 with 100 % accuracy at
every scale measured.
python benchmark/run.py --world horizonCaveats, the counter-experiment, the noise in the curve, and the ground truth are in
benchmark/README.md.
Requires Rust 1.89+ and 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 serverIn a second terminal:
curl http://localhost:8080/health
curl -X POST http://localhost:8080/query \
-H "Content-Type: application/json" \
-d '{"type":"lookup","entity_id":1}'Note: CLI commands and the HTTP server cannot run simultaneously (
redbholds an exclusive lock). Stop the server before using CLI commands.
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.dbComponent | Description |
kremis-core | Deterministic graph engine (pure Rust, no async) |
apps/kremis | HTTP server + CLI (tokio, axum, clap) |
apps/kremis-mcp | MCP server bridge for AI assistants (rmcp, stdio) |
See the architecture docs for internals: data flow, storage backends, algorithms, export formats.
Full reference at kremis.mintlify.app:
Topic | Link |
Introduction | |
Installation | |
Quick Start | |
Configuration | |
CLI Reference | |
API Reference | |
MCP Server | |
Philosophy | |
The Name |
cargo test --workspace
cargo clippy --all-targets --all-features -- -D warnings
cargo fmt --all -- --checkAuto-generated on CI runners — 2026-08-24.
Operation | Linux | Windows | macOS |
Node insertion (100K) | 20.63 ms ±0.18 | 23.05 ms ±1.08 | 46.13 ms ±5.82 |
Signal ingestion (10K batch) | 8.37 ms ±0.08 | 10.79 ms ±1.31 | 16.38 ms ±2.43 |
Graph traversal (depth 50, 1K nodes) | 2.7 µs ±0.0 | 3.2 µs ±0.1 | 8.4 µs ±2.3 |
Strongest path (1K nodes) | 7.5 µs ±0.0 | 9.2 µs ±1.1 | 20.7 µs ±4.6 |
Canonical export (1K nodes) | 68.0 µs ±1.4 | 77.2 µs ±5.9 | 164.1 µs ±40.0 |
Canonical import (10K nodes) | 3.09 ms ±0.03 | 3.74 ms ±0.29 | 7.11 ms ±1.24 |
Redb node insertion (1K) | 299.46 ms ±3.77 | 16.3 s ±0.7 | 2.3 s ±0.4 |
The ± is criterion's deviation within a single run. Spread between runs on hosted CI is wider still, because the runners themselves vary: figures here have moved by tens of percent with no change to the benched code. Read them as orders of magnitude, not as a regression signal.
The brand assets in docs/logo/ (logo, icon, favicon) are proprietary and not covered by the Apache 2.0 license. See docs/logo/LICENSE.
See CONTRIBUTING.md for guidelines. The architecture is still evolving — open an issue before submitting a PR.
This project was developed with AI assistance.
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. Dates show when Glama detected each change.
v0.19.1kremis_certifyv0.18.2kremis_hashkremis_ingestkremis_intersectkremis_lookupkremis_pathkremis_propertieskremis_retractkremis_statuskremis_traverseEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Governed personal world model and memory for your AI agent. Pair once, connect over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TyKolt/kremis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
