Evr MCP server

evidence-readiness

Checks whether an agent execution trace contains the evidence a post-hoc causal reconstruction would require.

When an AI agent causes a loss — a bad config change, a cross-session data leak, contaminated output cascading between agents, a prompt injection — someone eventually has to reconstruct why from the trace. Traces from general-purpose agent instrumentation cannot support that reconstruction: the evidence was never recorded. This repository contains the evidence-readiness specification (SPEC.md), a checker that evaluates a trace against it, and reference fixtures showing what conformant instrumentation looks like.

What this is — and is not

fabricated-but-internally-consistent trace passes. This tool authenticates nothing, and its result must never be relayed as "this agent is safe."

• It checks that evidence is present, not that it is true. A

trace contain what a reconstruction of class X would require," never "did class X occur." It contains no detection or scoring logic.

• It never determines whether a failure occurred. It answers "does this

specification is published so the method is assessable; the engine is available for inspection under the terms in SOURCE_AVAILABILITY.md.

• This repository does not contain the reconstruction engine. The

sessionisolationfailure, cascadecontamination, promptinjection. A fifth (tool_misuse) was investigated and declined for stated structural reasons — a documented negative result, not a gap (SPEC.md §8).

• Four failure classes are covered: config_drift,

plus documented extensions** (SPEC.md §2). It carries no standards-body endorsement.

• The spec is **a profile of the OTel GenAI semantic conventions: core OTel

Who it is for

reconstructable after the fact — diff your trace against a conformant fixture and see what to add.

• Engineers instrumenting agents who want incidents to be

agent system's telemetry would support retrospective loss adjudication.

• Reviewers (insurers, auditors, counterparties) evaluating whether an

spec export, generated — never hand-maintained), and the MCP server in src/evidencereadiness/mcpserver.py (configuration below).

• Coding agents: see llms.txt, spec.json (the machine-readable

Quickstart (60 seconds)

# from a clone of this repository
pip install .
evr check path/to/trace.json        # or a directory of traces
evr check --json path/to/traces/    # machine-readable report
evr check --require-class prompt_injection path/to/trace.json

The package has zero runtime dependencies; pip install . in any Python ≥3.10 environment is the whole setup. Equivalent uvx forms, both exercised: uvx --from . evr check ./traces from a clone, and uvx --from evidence-readiness evr check ./traces from the package index.

Both need --from, and the trailing evr is not optional. A bare uvx evidence-readiness ... runs the console script named for the distribution, and that script is the MCP server (below), not the checker — it reads standard input, ignores the arguments, and exits successfully without checking anything.

Exit codes carry no reconstruction vocabulary: 0 all requirements met · 1 one or more requirements partially met · 2 one or more requirements unmet · 3 malformed input (SPEC.md §9 is the source of record). Universal requirements (EVR-R1..R6) drive the exit code; per-class evidence readiness is reported separately, and --require-class folds a named class's readiness into the exit code. For every failed requirement the output names the specific missing field and the span kind it belongs on.

Every run ends with the same statement this README opened with: presence, not truth — evidence being present does not make it authentic, and a passing trace is not a safe agent.

CI: check every PR (GitHub Action)

Shortened. The full README is on GitHub.