EVIDE MCP Server v1.4.0

MCP server connecting AI agents to the EVIDE External Evidentiary Deposit API.

EVIDE crystallizes AI agent decisions, escalations, and governance states into independently verifiable forensic records -- anchored to a verified human identity, timestamped server-side in UTC, and externalized before consequence propagation begins.

> EVIDE is not an execution-control layer. It is an external evidentiary crystallization layer operating at the responsibility closure boundary.

What's New in v1.4.0

• Expanded `execution_identity`. Three new deployment-level descriptors (`model_reference`, `agent_name`, `deployment_id`) and two new execution-specific, call-time identifiers (`session_id`, `run_id`). All five are optional.
• `session_id` and `run_id` are call-time only. They are accepted as optional arguments directly on `evide_intake`, `evide_escalate` and `evide_intake_esb` -- there is no environment-variable equivalent for them, by design, because they vary per call rather than per deployment.
• Software-generated placeholders removed. `agent_unspecified` and `Unknown Agent System` no longer appear inside `execution_identity`. An unset optional field is now omitted, not filled in -- absence remains absence.
• `accountability_model: "owner_bound"` unchanged. Still hardcoded, still never derived from any `execution_identity` field. See `execution_identity` -- Declared Execution Context below for the full boundary.
• Dedicated regression test suite. New tests cover minimal/expanded/legacy-style records, whitespace-only rejection, call-time propagation, and backward compatibility with historical records.
• Documentation and request-view boundary hardening. Clarified, across this README and the EVIDE application, that declared execution-context identifiers are not verified agent identity and do not alter who is accountable for a deposit.
• Fully backward-compatible. A record built exactly as under v1.3.0 remains valid under v1.4.0 without modification.

What's New in v1.3.0

• EVIDE ANCHOR. `declarations` on `evide_intake`, `evide_escalate` and `evide_intake_esb`: explicit, attributable, time-bound statements of the operational perimeter (environment, privileges, purpose, tools, prohibited operations, agent configuration) the agent was authorized within, before it acted. EVIDE preserves the declaration only -- it never verifies its correctness, applies it as policy, or compares it against observed behavior.
• EVIDE Schema 2.1. Previous versions declared `evide_schema: 2.0` and were rejected by production with `unsupported_schema` on every deposit. If you cloned before July 2026, your copy could not deposit at all.
• Evidentiary Continuity. `parent_evide_id`, `chain_type` and `matter_reference` on both deposit tools, with the four refusal codes documented.
• External Artifacts. `evidence_references` with structured hash declaration; the `extensions` registry is kept aligned by the client.
• Epistemic Stabilization Buffer. Three new tools: `evide_intake_esb`, `evide_buffer_observe`, `evide_buffer_close`.
• Boundary Readiness aligned with independent gate declaration. `candidate` is now the default for both tools, and the client no longer fabricates a `readiness_gate`.
• The client no longer completes declarations that belong to someone else. `hashed_by`, `readiness_gate`, `unresolved_signals` and `stabilization_score` are never filled in on the caller's behalf: a missing one fails the call rather than being invented.

Prerequisites -- Read Before Installing

> Both prerequisites are mandatory. The server will not start without them.

1. DAPI -- Verified Identity

EVIDE does not accept anonymous deposits. Every record must be attributable to a verified human identity.

DAPI (Digital Attestation of Personal Identity) is the identity layer that binds every deposit to a verified, attributable identity. The DAPI number belongs to the human or organization responsible for the AI agent -- not to the agent itself. The agent cannot self-certify.

> **EVIDE does not determine whether the decision itself was correct.

> It preserves the externally reconstructable responsibility and governance conditions present at closure time, making them independently examinable.**

How to obtain a DAPI: dapi-certification.com

DAPI verification requires: 1 valid identity document, 1 facial photo, 1 audio file with voice, 1 short video. Processing is manual. Allow time before planning your integration.

2. EVIDE API Key -- Active Subscription

Access to the EVIDE intake API requires an active plan and a dedicated API key (`evd_...`).

Plans and pricing: app.certifywebcontent.com/pricing

Available plans: Entry (10 intakes/month), Starter (75), Professional (200), Enterprise (500). For volumes above 500 intakes/month, dedicated infrastructure is required -- contact us before activating.

What EVIDE Deposits

Each record anchors:

• the identity of the accountable authority (DAPI-bound owner)
• the execution identity of the agent (architecturally separated from the owner)
• the classification state and operational stability at closure
• the boundary readiness and gate visibility surface
• the human oversight level declared at closure
• unresolved signals that could not be confirmed at crossing time

The server-computed evidentiary profile (profile_version: 1.1) includes:

• Dim 9 -- Forensic Cross-Check -- continuity inference (classification x runtime_visibility) -- anti-Synthetic-Coherence sensor
• Dim 10 -- Decision Wave Compression (DWC) -- oversight throughput boundary detection
• Dim 11 -- Formal Accountability Collapse (FAC) -- authority fragmentation detection

> Important: The evidentiary profile contains inferred governance signals.

> These signals are probabilistic governance indicators, not judicial determinations or accusations of misconduct.

> A `detected` or `critical` state for DWC or FAC indicates a structural condition present at closure time -- it does not constitute a finding of wrongdoing by any party.

Installation

git clone https://github.com/emanuelcelano/evide-mcp
cd evide-mcp
npm install

Node.js >= 18 required.

Configuration

Add to your MCP client configuration (`claude_desktop_config.json` or equivalent):

{
  "mcpServers": {
    "evide": {
      "command": "node",
      "args": ["/path/to/evide-mcp/index.js"],
      "env": {
        "EVIDE_API_KEY":      "evd_your_key_here",
        "EVIDE_DAPI_NUMBER":  "0123456789",
        "EVIDE_OWNER_ID":     "your_owner_id",
        "EVIDE_OWNER_ROLE":   "AI System Operator",
        "EVIDE_AGENT_SYSTEM": "MyAgentSystem",
        "EVIDE_AGENT_ID":     "agent_xyz"
      }
    }
  }
}

Environment Variables

`session_id` and `run_id` are not environment variables. They vary per call and are accepted as optional call-time arguments on the deposit tools themselves -- see `execution_identity` -- Declared Execution Context below.

Tools

`evide_intake`

Deposit a finalized AI decision as an evidentiary record.

{
  "source_reference": "CDR-2026-00421",
  "decision_type": "candidate_evaluation",
  "decision_summary": "Candidate approved for second round interview.",
  "classification_status": "stable",
  "threshold_status": "met",
  "boundary_status": "candidate",
  "human_oversight_level": "L2"
}

Keep `decision_summary` short - it becomes the record's title. It is stored and displayed as-is, with no length management on the server side: a paragraph-length `decision_summary` becomes a paragraph-length title, and very long values may be truncated by the underlying storage in ways that cut a title off mid-word. Treat it as a one-line label, not a narrative.

For the fuller explanation - why the decision was made, what was ambiguous, what evidence was weighed - use the optional `rationale` field instead. It exists exactly for this purpose and has no practical length expectation the way a title does.

{
  "decision_summary": "Clause 8.3 - liability scope ambiguous, Rossi Manufacturing contract",
  "rationale": "The limitation-of-liability clause's scope is ambiguous relative to a recent similar dispute, decided differently by two lower courts. Final assessment is on hold pending internal legal opinion and updated case law."
}

Optional external artifacts (`evidence_references`):

{
  "source_reference": "CDR-2026-00423",
  "decision_type": "claim_assessment",
  "decision_summary": "Claim rejected: documentation inconsistent with policy terms.",
  "evidence_references": [
    {
      "artifact_type": "document",
      "pointer": "s3://evidence-store/claim-8812/policy.pdf",
      "declared_origin": "policy_management_system",
      "declared_relationship": "supporting_document",
      "declared_retention_status": "persistent_storage",
      "hash_algorithm": "sha256",
      "hash_value": "9f2c7a1b4e6d...",
      "hash_scope": "full_file",
      "hashed_by": "policy_management_system"
    }
  ]
}

EVIDE anchors the declaration that an artifact exists — the file itself is never uploaded, and EVIDE never computes or verifies its hash. That is why `hashed_by` is mandatory whenever a hash is declared: an anchored digest with no stated provenance would be worthless. The client validates this before the request leaves, so a missing field produces a message naming it rather than a generic server rejection. Nothing is inferred: `hashed_by` is never filled in with the agent identity, because claiming the agent computed a digest it merely relayed would be a false provenance claim.

Declaring the array automatically sets `extensions: ["evidence_references"]`. That registry is opt-in in both directions — a block present but undeclared is rejected, and a declaration with no content is rejected too — so the client keeps the two aligned by construction.

Optional operational perimeter declarations (`declarations`, EVIDE ANCHOR):

{
  "source_reference": "CDR-2026-00424",
  "decision_type": "operational_perimeter_declaration",
  "decision_summary": "Environment classification declared before agent action.",
  "declarations": [
    {
      "declaration_type": "environment_classification",
      "declared_value": "production",
      "declarant": "devops-lead",
      "declared_at": "2026-08-03T16:30:00Z",
      "declared_attribution_status": "attributed"
    }
  ]
}

A Declaration is an explicit, attributable, time-bound statement of the operational perimeter (environment, privileges, purpose, tools, prohibited operations, agent configuration) an agent was authorized within, before it acted. EVIDE preserves the declaration only — it never verifies its correctness, applies it as policy, or compares it against observed behavior. This is the primitive behind the incident that motivated it: an agent that mistakes a production database for a disposable test environment is exactly the case a declared `environment_classification` makes independently reconstructable after the fact.

This MCP-level schema is deliberately simplified relative to the full API: `declaration_type`, `declared_value`, `declarant`, `declared_at`, `declared_description` and a flattened `declared_attribution_status` are exposed here. Nested `subject_references`, `authority_source.references` and `declared_relations` (declaring that one Declaration supersedes, clarifies, or revokes another) are not — they remain available through the direct intake API for callers who need the nested form.

`declaration_digest` is computed server-side, not by this client. For each Declaration, the API computes `SHA-256("EVIDE_DECLARATION_V1:" + canonical_json(Declaration))` at intake time and returns it as part of the stored record. The MCP client never calculates or sends this value — it has no `declaration_digest` field in the tool schema above. This gives each Declaration its own tamper-evidence independent of the intake's overall `intake_hash`, and is what `declared_relations` on the full API reference when one Declaration supersedes another.

Declaring the array automatically sets `extensions: ["declarations"]`, using the same opt-in registry as `evidence_references` — both can be declared together in the same deposit.

Atomic Declaration Rule

Each Declaration should represent a single attributable statement. When a request describes multiple independent facts -- for example, both an environment classification and a privilege scope -- each should be preserved as its own Declaration, not merged into one.

Composite `declaration_type` values (e.g. `environment_and_privilege`) are accepted by the schema -- `declaration_type` is free text by design -- but discouraged: a merged declaration cannot later be superseded, clarified, or revoked independently from the facts it bundles together. If the environment classification changes but the privilege scope does not, only the `environment_classification` Declaration should be superseded -- that becomes impossible once the two are combined into one.

Optional chain parameters (Evidentiary Continuity):

{
  "source_reference": "CDR-2026-00422",
  "decision_type": "candidate_evaluation",
  "decision_summary": "Escalation resolved: candidate approved after compliance review.",
  "parent_evide_id": "aed9e966-6f25-4358-b784-b06eff939e91",
  "chain_type": "escalation_resolution",
  "matter_reference": "MATTER-2026-4471"
}

The natural use is to pass the `evide_id` returned by an earlier `evide_escalate` as `parent_evide_id` on the deposit that resolves it — producing a declared lineage from "the agent stopped here" to "this is how it was closed".

Chain validation is strict and has no silent fallback. If the parent does not exist, belongs to another evidentiary domain, is in a non-chainable status, or declares a different `matter_reference`, the whole deposit is refused rather than silently starting a new chain. The refusals are `chain_parent_not_found` (422), `chain_parent_not_owned` (403 — an authorization decision, not a payload error), `chain_parent_invalid_status` (422) and `chain_matter_mismatch` (422).

Returns: `evide_id`, `intake_hash`, `intake_timestamp_utc`, `profile_version`, Forensic Cross-Check state, DWC and FAC states when present, and — when the record continues from another — `chain_position`, `chain_type` and `chain_root_evide_id`.

`evide_escalate`

Crystallize the agent state before proceeding at a high-stakes or contestable boundary.

{
  "source_reference": "ESC-2026-00089",
  "agent_state_summary": "Transaction exceeds regulatory threshold. Human review required.",
  "escalation_trigger": "regulatory_threshold",
  "escalation_reason": "Amount exceeds €50,000 -- requires compliance officer approval.",
  "boundary_status": "verified_partial",
  "unresolved_signals": ["compliance_officer_availability", "aml_flag_status"]
}

`evide_escalate` accepts the same optional chain, `evidence_references` and `declarations` parameters as `evide_intake`, for the case where one escalation continues from another.

`agent_state_summary` feeds the same title field as `decision_summary` above - keep it short for the same reason. The fuller picture belongs in `escalation_reason`, which already exists for exactly that.

Available triggers: `high_stakes_decision` · `contestable_state` · `legal_ambiguity` · `regulatory_threshold` · `governance_uncertainty` · `semantic_instability` · `human_review_required` · `authority_incoherence`

`evide_owner_info`

Returns the configured owner and agent identity. Does not expose the full API key.

`evide_check`

Returns verification guidance for a previously deposited record.

`execution_identity` -- Declared Execution Context

Every deposit made through `evide_intake`, `evide_escalate` and `evide_intake_esb` includes an `execution_identity` block. It separates the accountable owner identity (under `authority`, DAPI-bound) from the declared execution context (agent, model, session, run -- as supplied). Only `type` and `accountability_model` are always present; every other field is optional and simply omitted when not available.

Deployment-level execution context

Static per client configuration, set once via the environment variables above and unchanged across every call from that deployment:

• `agent_id`
• `agent_system`
• `model_reference`
• `agent_name`
• `deployment_id`

Execution-specific call-time identifiers

Dynamic, accepted as optional arguments directly on `evide_intake`, `evide_escalate` and `evide_intake_esb`:

• `session_id`
• `run_id`

`session_id` and `run_id`:

• are optional;
• are caller-supplied;
• enter through the tool call itself, in this MCP client -- there is no environment-variable equivalent for them;
• are not generated by EVIDE;
• are not authenticated by EVIDE;
• do not constitute verified agent identity.

Minimal record (no optional context declared):

{
  "execution_identity": {
    "type": "agent_identity",
    "accountability_model": "owner_bound"
  }
}

Fully declared record, including call-time context:

{
  "execution_identity": {
    "type": "agent_identity",
    "agent_id": "legal-intake-agent",
    "agent_system": "CLARIXO",
    "model_reference": "claude-sonnet-4-6-20260514",
    "agent_name": "Legal Intake Agent",
    "deployment_id": "legal-intake-prod-eu-2026-07",
    "session_id": "sess_8f21c",
    "run_id": "run_3af90d",
    "accountability_model": "owner_bound"
  }
}

Boundary

> `execution_identity` preserves declared or externally supplied execution-context identifiers. Their presence does not independently verify the identity, authenticity, provenance, or control of the referenced agent, model, session, or run.

> `accountability_model: "owner_bound"` remains hardcoded and records that, within the EVIDE evidentiary model, accountability for the deposit remains associated with the DAPI-verified owner rather than being transferred to the referenced agent.

No optional field is ever populated with a placeholder. If a value is unavailable, it is omitted -- absence remains absence.

Epistemic Stabilization Buffer

Three additional tools let an agent drive the full ESB lifecycle:

The closure is anchored immediately, exactly as with `evide_intake`: the buffer opens alongside it, it does not delay or replace it. What the buffer adds is the trajectory — how the conditions settled over a real window, rather than only what they were at the crossing.

A real observation window is required. The server refuses a close occurring less than two seconds after the open, because a buffer that closes instantly observed nothing. The measured window comes back as `window_seconds`. `test_mode: true` bypasses this, and is exposed only because the server accepts it: a buffer closed in test mode did not observe a real window, and the record will not pretend otherwise.

`stabilization_score` is declared, never computed. Neither EVIDE nor this client calculates it. Out-of-range values are rejected rather than clamped, because clamping would hide a client error. If you have no basis for a score, omit it — the client does not supply one on your behalf. Same principle already applied to `hashed_by` and `readiness_gate`.

Phase fields are enforced client-side. `buffer/update` and `buffer/close` accept different key sets. Sending `stabilization_score` to an observation, or `stability_trend` to a close, is refused with a message naming the tool it belongs to — rather than being silently discarded, which is what the API itself did until July 2026.

evide_intake_esb        → closure anchored, buffer_id returned, buffer OPEN
      ↓
evide_buffer_observe    → stability_trend, continuity_state,
      ↓                   causal_persistence_signal, stabilization_source
evide_buffer_close      → verdict + window_seconds
                          "crossing-sufficient, NOT absolute epistemic truth"

Boundary Readiness and the Independent Gate

Agent-originated intakes default to `boundary_readiness: candidate`. In the absence of an independently declared readiness gate, FCC, DWC and FAC may remain `unknown`. This is an evidentiary result, not a processing failure.

`boundary_readiness` declares whether an *independent* gate assessed the boundary. A depositing agent is not that gate: it cannot attest to its own readiness at a boundary any more than a system can self-certify. The client therefore never fabricates one — `readiness_gate_id` and `readiness_gate_scope` must come from the caller, and any status other than `candidate` is refused without them.

The same applies to `unresolved_signals`, which carries the identifiers a gate could not resolve during its assessment. With `candidate` the array is empty by definition, not by restriction: no assessment took place, so nothing could have been left open. What the *agent* could not decide is a different thing, and lives in `escalation_reason` and `agent_state_summary`.

This is the intended lifecycle, and it is already how independent integrations use the schema in production:

agent
  ↓  evide_escalate / evide_intake  →  boundary_readiness: candidate
  ↓                                    FCC / DWC / FAC: unknown
independent gate (human supervisor, orchestrator, external governance component)
  ↓  assessment                      →  boundary_readiness: verified_partial
                                       with its own readiness_gate

The agent never has to impersonate the gate. Same principle already applied to `hashed_by`: the client does not invent a declaration that belongs to someone else.

Scope of the Current Abstractions

Current MCP abstractions intentionally expose only the intervention types required by the implemented tools (`approval` for `evide_intake`, `escalation` for `evide_escalate`). Additional intervention semantics — for example `override` or `rejection` — will be introduced only when a concrete agent workflow requires them, rather than speculating about future use cases.

The same reasoning applies to `human_oversight.is_declared`, which is always `true`. This is not a shortcut: the server cannot start without a DAPI number, so every deposit made through it is by construction attributable to a declared accountable human. There is no anonymous path to leave open. The oversight *level* remains the caller's choice (`L1` / `L2` / `L3`); only the existence of a declared authority is fixed, because the transport itself guarantees it.

Architectural Principle

authority          = accountable human / organization (DAPI-bound)
execution_identity = declared execution context associated with the closure
escalation_context = why crystallization was requested

Accountability is owner-bound: it remains associated, within the EVIDE evidentiary model, with the DAPI-verified owner rather than being transferred to the referenced agent. The agent cannot self-certify.

Live Validation

The two rounds below are the current reference for what has actually been exercised end-to-end. A historical note on the first live deposit, May 2026, follows at the end of this section.

End-to-end validation, August 2026 (EVIDE ANCHOR)

v1.3.0 was exercised through five natural-language scenarios given to a real MCP client (Claude Desktop), each producing a genuine deposit and a downloaded Evidentiary Artifact Record -- not a re-run of the builders in isolation.

FCC read `unknown` on every scenario, including the one intended to show a stable state. None of the five prompts declared an independently verified boundary (`boundary_status: verified` with a real `readiness_gate`) -- without one, `runtime_visibility` stays null and FCC cannot read anything but `unknown`. This is the model working as designed, not a defect: it reflects the absence of an independently declared readiness gate in the test scenarios, not an issue in the code.

One agent, in one combined scenario, merged two independent facts into a single Declaration (`declaration_type: "environment_and_privilege"`) instead of two separate ones. Accepted by the schema -- `declaration_type` is free text by design -- but it is exactly the case the Atomic Declaration Rule above exists to discourage: a merged Declaration cannot later be superseded or corrected independently for just one of the facts it bundles. This observation is reported as an implementation note, not as a general property of LLMs.

This was one agent (Claude, via Claude Desktop) run once through each scenario -- not a claim about how any LLM would behave in general. Within that scope, the agent populated every optional field correctly, including nested objects (`authority_source`, `hash`), without requiring a predefined payload template.

End-to-end validation, July 2026

v1.2.0 was exercised through a real MCP client along the complete path -- client, JSON-RPC over stdio, payload builders, HTTP transport, EVIDE Intake API -- rather than by re-running the builders in isolation.

Not yet exercised along that path: `evide_escalate`, `evide_owner_info`, `evide_check`, and the chain parameters. A defect in the `evide_escalate` handler -- the tool's own default silently overrode `boundary_status` to `verified_partial`, so any escalation without an explicit status failed for want of a readiness gate -- was found by code review immediately afterwards, precisely because it was not part of this run. It was fixed the same month, July 29 2026 (commit `f4d0481`): the handler now defaults to `candidate`, matching the builder, and the tool schema exposes all four boundary states. The distinction between what has been executed and what has only been read is kept here for the same reason it is kept in the evidentiary records themselves.

First live crystallization, May 2026 (historical)

First live agent evidentiary crystallization, via Claude Desktop + MCP -- superseded by the two validation rounds above, kept here for the record.

continuity.state:    degraded
boundary_readiness:  verified_partial
unresolved_signals:  8
FCC:                 DEGRADED

The record preserved a degraded governance state without flattening instability into false certainty.

LinkedIn -- First Live Agent Evidentiary Crystallization

Documentation

• EVIDE JSON Schema
• API Documentation
• Payload Canonicalization
• Closure Layer
• EVIDE vs Execution Certification
• Pricing & Service Conditions

Author

Dott. Emanuel Celano -- Informatica in Azienda

info@informaticainazienda.it

Bologna, Italy

License

MIT

> Use of this server requires a valid DAPI identity and an active EVIDE subscription.

> Service conditions: app.certifywebcontent.com/pricing#service-conditions