Evidra

What the Evidra MCP server does

The Evidra MCP server proxies one upstream MCP server and keeps three evidence streams separate. Before an operational call, an agent can record a declared objective. During execution, the proxy records boundaries such as start and finish events, status, timing metadata, upstream tool metadata, and bounded keyed fingerprints. Afterward, the agent can record a terminal status and explanation.

This separation matters when reviewing an operation. A declaration describes the agent's stated intent, an observation describes traffic visible at the MCP boundary, and a report is an agent-provided account of the result. Evidra reconciles these records without treating any source as independent proof of what happened in an external system.

The upstream tools remain available through the endpoint. Evidra adds evidra_prescribe and evidra_report; it does not provide its own catalogue of Kubernetes, Terraform, Helm, or Argo CD tools.

How it works

An MCP client starts the Evidra endpoint as a single stdio process. Evidra launches the supplied upstream command and forwards MCP traffic between the client and that process. Each endpoint process creates a recorder directory under the configured evidence root.

Stored records use signed, hash-linked ordering. The reader CLI can summarize recorder directories and verify their chains:

./bin/evidra summarize --dir ./evidence
./bin/evidra verify --dir ./evidence

Verification checks chain integrity and signatures against the public key stored with the recorder. It does not establish an organizational identity, confirm that an external system reached an intended state, or prove side effects beyond the MCP boundary. Summaries keep declarations, observations, and reports distinct and identify execution starts without matching finish events. Evidence coverage also reports known degraded windows after persistence failures; a complete result does not prove that unknown loss never occurred.

Setup and configuration

To run the Evidra MCP server from source, use Go 1.26 or later and build the binaries with make build. The documented quick-start flow also builds the fixture upstream server, creates a local evidence directory, and starts the proxy with a server name and command after --:

./bin/evidra-mcp --proxy \
  --evidence-dir ./evidence \
  --server-name fixture \
  -- ./bin/evidra-fixture

In normal use, an MCP client owns this process and supplies its configuration. The endpoint supports MCP protocol versions 2025-06-18, 2025-03-26, and 2024-11-05. Evidence is written locally, with one recorder directory per endpoint process, and no hosted service is required.

Enforcement defaults to --enforce=all, which enables protocol enforcement. Use --enforce=off for observe-only operation. Evidra starts the wrapped command with the caller's operating-system authority, so the command and its configuration must be reviewed as if launched directly.

Limitations and notes

The Evidra MCP server supports one stdio upstream MCP server per endpoint process. It does not sandbox that process, and raw upstream request and response bodies are not retained as observed payloads; only bounded fingerprints and execution metadata are recorded.

A valid local signature shows that records match the recorder's stored public key, not who controls that key. Proxy observations cover execution boundaries visible to Evidra, while declarations and reports remain attributed claims. The project describes its relaunched Core line as an unreleased preview built from the main branch. Go applications can import the public evidence and reconciliation packages, but the endpoint implementation package is not a supported integration API.