# Knolo [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/HiveForensics-AI/knolo-core  
**GitHub Stars:** 56  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/knolo

## Description
Verified, local-first retrieval over pinned Knolo Knowledge Images.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "knolo": {
    "command": "npx",
    "args": ["-y","create-knolo-app"]
  }
}
```

## Documentation

## What Knolo MCP server does

The Knolo MCP server is intended for retrieval from pinned Knolo Knowledge Images, which package organizational knowledge as portable runtime artifacts. The repository describes these images as bounded byte artifacts that can be mounted, inspected, verified, copied, and compared across runtimes.

Knolo separates knowledge storage, verification, retrieval, policy, and agent execution. This makes it possible to use the knowledge layer independently from a model provider or chat application. The host owns model execution; Knolo supplies the knowledge and evidence runtime rather than performing model inference.

The Knolo MCP server fits workflows where retrieved material must remain connected to its source, chunk, claim, citation, and evidence identity. It is also relevant when a team needs deterministic behavior, migration records, runtime diagnostics, or receipts that can be reviewed after retrieval.

## How it works

A V5 Knowledge Image contains immutable object and event segments, a commit record, section bounds, digests, and roots. Dual superblocks support generation-based recovery and an active commit pointer. Validation fails closed for malformed required sections, overlapping or duplicated sections, invalid offsets, integer overflow, and digest mismatches. Unknown optional sections can be handled for forward compatibility.

KAR works from a Committed Evidence Graph compiled from editable CEG Source. A declared plan determines the minimum applicable evidence set for a proposition. Support, opposition, qualification, temporal applicability, and authority remain typed by that plan. Evaluation is replayable and distinguishes unmet evidence requirements from a conclusion that a claim is false.

The repository also describes deterministic EQL query planning, result receipts, query indexes, history, policy evaluation, authority sessions, signed envelopes, key rotation, synchronization summaries, merge planning, replay, durable agent runs, and runtime diagnostics. These capabilities form the runtime foundation around retrieval and verification.

## Tools and capabilities

The documented TypeScript KAR surface includes:

- `createKarSession` for creating a KAR evaluation session.
- `evaluateKar` for evaluating a proposition against the declared evidence plan.
- `verifyKar` for verifying KAR results or related integrity conditions.
- `explainKarResult` for producing an explanation of a KAR result.
- `createKarDossier` for creating a dossier from KAR evaluation material.
- `createKarCoverage` for reporting satisfied requirements, gaps, and plans that did not decide.

The repository states that `SATISFIED` means the declared evidence requirements were met; it does not mean the claim is proven. Likewise, `UNSATISFIED_EVIDENCE_REQUIREMENTS` means the requirements were not met, not that the claim is false.

## Limitations and notes

The provided material does not document an MCP transport, installation command, configuration file, environment variables, or named client integrations. It also does not establish that every Knolo runtime capability is exposed as an MCP tool. The repository identifies the current tree as version 6.2.0, while some Rust, Python, and ICP components remain at 5.5.1 and do not implement KAR, composition, or Cortex.

The host controls model execution. Verification provides inspectable evidence and integrity checks, but does not establish that an answer is true. Domain Packs for contracts, policy, and operations are marked `review-required`, so human review is needed before their proposed semantics are treated as validated. Transactions, authority mutation workflows, network orchestration, model inference, and the Studio UI or service are described as follow-on layers rather than current capabilities.

_Full upstream README: https://allmcps.com/mcp/knolo/readme_