Alpha — Funcional y probado. Aún pueden ocurrir cambios importantes antes de la v1.0.
Problema | Cómo lo aborda Kremis |
Alucinación | Cada resultado se remonta a una señal real ingerida. Los datos faltantes devuelven un "no encontrado" explícito; nunca se fabrican |
Opacidad | Estado del grafo totalmente inspeccionable. Sin capas ocultas, sin caja negra |
Falta de fundamentación | Cero conocimiento precargado. Toda la estructura surge de señales reales, no de suposiciones |
No determinismo | Misma entrada, misma salida. Sin aleatoriedad, sin aritmética de punto flotante en el núcleo |
Pérdida de datos | Transacciones ACID a través de la base de datos embebida |
Filosofía de diseño — por qué existen estas restricciones.
Related MCP server: tero-mcp-lite
Motor de grafo determinista — Rust puro, sin async en el núcleo, sin punto flotante. La misma entrada siempre produce la misma salida
CLI + API HTTP + puente MCP — Tres interfaces para el mismo motor: terminal, REST y asistentes de IA
Hashing BLAKE3 — Hash criptográfico del estado completo del grafo para la verificación de integridad en cualquier momento
Exportación canónica (KREX) — Instantánea binaria determinista para procedencia, pistas de auditoría y reproducibilidad
Cero conocimiento integrado — Kremis comienza vacío. Cada nodo proviene de una señal real
Persistencia ACID — Backend redb por defecto con transacciones a prueba de fallos
Proporciona a Claude, Cursor o cualquier asistente compatible con MCP una capa de memoria verificable. Kremis almacena hechos como nodos de grafo: el agente los consulta y cada respuesta se remonta a un punto de datos real. Sin embeddings, sin recuperación probabilística.
Ingesta tus datos, deja que un LLM genere afirmaciones y luego valida cada afirmación contra el grafo. Kremis etiqueta cada declaración como [FACT] o [NOT IN GRAPH] — sin puntuaciones de confianza, sin ambigüedad.
Exporta el grafo completo como una instantánea binaria determinista, calcula su hash BLAKE3 y verifica la integridad en cualquier momento. Cada nodo enlaza con la señal que lo creó. Útil para flujos de trabajo de cumplimiento donde necesitas probar qué datos estaban presentes y cuándo.
Ingesta algunos hechos, deja que un LLM genere afirmaciones y Kremis valida cada una:
[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/6Tres hechos fundamentados. Tres fabricados. Sin ambigüedad.
python examples/demo_honesty.py # mock LLM (no external deps)
python examples/demo_honesty.py --ollama # real LLM via OllamaRequiere Rust 1.89+ y 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 serverEn una segunda terminal:
curl http://localhost:8080/health
curl -X POST http://localhost:8080/query \
-H "Content-Type: application/json" \
-d '{"type":"lookup","entity_id":1}'Nota: Los comandos CLI y el servidor HTTP no pueden ejecutarse simultáneamente (
redbmantiene un bloqueo exclusivo). Detén el servidor antes de usar comandos 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.dbComponente | Descripción |
kremis-core | Motor de grafo determinista (Rust puro, sin async) |
apps/kremis | Servidor HTTP + CLI (tokio, axum, clap) |
apps/kremis-mcp | Puente de servidor MCP para asistentes de IA (rmcp, stdio) |
Consulta los documentos de arquitectura para conocer los aspectos internos: flujo de datos, backends de almacenamiento, algoritmos, formatos de exportación.
Referencia completa en kremis.mintlify.app:
Tema | Enlace |
Introducción | |
Instalación | |
Inicio rápido | |
Configuración | |
Referencia CLI | |
Referencia API | |
Servidor MCP | |
Filosofía |
cargo test --workspace
cargo clippy --all-targets --all-features -- -D warnings
cargo fmt --all -- --checkGenerado automáticamente en ejecutores de CI — 10-05-2026.
Operación | Linux | Windows | macOS |
Inserción de nodo (100K) | 21.30 ms | 22.06 ms | 18.67 ms |
Ingesta de señal (lote 10K) | 6.98 ms | 9.78 ms | 8.12 ms |
Recorrido de grafo (profundidad 50, 1K nodos) | 2.6 µs | 3.1 µs | 2.3 µs |
Camino más fuerte (1K nodos) | 7.6 µs | 8.7 µs | 6.1 µs |
Exportación canónica (1K nodos) | 68.2 µs | 74.4 µs | 56.6 µs |
Importación canónica (10K nodos) | 3.09 ms | 3.97 ms | 3.38 ms |
Inserción de nodo Redb (1K) | 358.19 ms | 14.6 s | 489.02 ms |
Los activos de marca en docs/logo/ (logotipo, icono, favicon) son propiedad exclusiva y no están cubiertos por la licencia Apache 2.0. Consulta docs/logo/LICENSE.
Consulta CONTRIBUTING.md para conocer las directrices. La arquitectura aún está evolucionando: abre un issue antes de enviar un PR.
Este proyecto fue desarrollado con asistencia de IA.
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.