# INVARA [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/Jujitae/invara  
**GitHub Stars:** 1  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/invara

## Description
Independent verification that a change kept its declared constraints. No model in the verdict path.

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

```json
"mcpServers": {
  "invara": {
    "command": "uvx",
    "args": ["--from","invara==0.3.0","invara"]
  }
}
```

## Documentation

## What INVARA MCP server does

The INVARA MCP server connects coding agents to INVARA's local verification workflows. INVARA checks a task contract against evidence produced after an agent changes a repository. The contract can protect named paths and define completion checks as commands with expected exit codes. Before work starts, sealing records digests of protected files. Afterward, judging compares those digests and runs the declared checks.

The verdict is deliberately bounded. PASS means the declared checks returned their expected results and protected paths remained byte-identical. BLOCK indicates a changed protected path or a failed check. UNVERIFIABLE means a check could not run, while HUMAN_REVIEW records that machine checks passed but a human decision was requested. These outcomes are not reinterpreted as success.

INVARA does not inspect code quality, determine whether a contract is adequate, find bugs beyond the declared checks, or prove correctness. It also does not act as a sandbox, authorization system, compliance control, code generator, or language-model reviewer.

## How it works

A typical workflow has three stages:

1. Create a `task.json` contract containing an identifier, intent, protected paths, and one or more completion checks.
2. Run `invara seal task.json` before the change so protected-path digests are captured.
3. Run `invara judge <task_id>` to preview the result, or add `--commit` to append the verdict to the task history.

The local history is stored in `.runtime/verify.db`, unless another database path is supplied with `--db`. A contract may be judged repeatedly. Verdict history is append-only and chained, and `invara replay` recomputes a recorded verdict from stored observations to test reproducibility. `invara chain` rebuilds the hash chains.

The transformation-assurance workflows add two local patterns: `invara assure` compares an existing before-and-after pair using an Equivalence Manifest, and `invara repair` accepts a repair one unit at a time only when its declared checks pass. These checks cover only the inputs, observations, policies, and claims declared in the manifest.

## Setup and configuration

The INVARA MCP server runs locally with Python 3.12 or newer and uv. No account, API key, or external service is required, and the package declares no runtime dependencies beyond the standard library. A temporary execution can use `uvx --from invara==0.3.0 invara list`; a persistent installation can use `python -m pip install invara==0.3.0`.

Claude Code can install the bundled plugin through its marketplace and plugin commands. Codex and other shell-capable agents can use the CLI directly or follow the repository's AI Agent Quickstart. The package also provides an MCP server over standard input/output, allowing compatible agents to invoke the packaged workflows.

Commands include `init` for a task template, `list` for sealed tasks and current verdicts, `log` for a task's verdict history, `show` for the sealed contract, and `replay` for reproducibility checks. The database location is configurable with `--db`; no environment variables are required by the documented setup.

## Tools and capabilities

The INVARA MCP server supports the same verification surface as the local package, including:

- Creating and sealing task contracts before implementation work.
- Checking protected paths against their pre-work digests.
- Running user-declared completion commands and evaluating expected exits.
- Recording and listing verdicts with their deciding evidence.
- Replaying stored observations and rebuilding verification chains.
- Comparing transformation states or governing incremental repairs through the Gen 1 assurance workflows.

Commands run with the user's permissions. An HTTP probe, when declared, may connect only to a loopback service started for that session; the workflows make no outbound network calls.

## Limitations and notes

A PASS covers only the contract's declared envelope. It is not a general proof that software is correct, secure, bug-free, or appropriately tested. A weak or incomplete contract can therefore produce a weak PASS. The `intent` field is descriptive prose and is not independently checked.

The project labels the current public release, 0.3.0, as Alpha. INVARA Free is publicly distributed, while INVARA Pro is a separate paid product. INVARA is not autonomous authorization and should not be treated as an enterprise compliance control. Read completion commands before sealing because they execute with the permissions of the invoking user.

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