EVIDE
← Back to API Documentation
MCP Server
Developer Preview
v1.3.0

EVIDE MCP Server

Agent-to-Evidentiary Accountability Boundary for Agentic AI Systems
v1.3.0 · Node.js · MCP Protocol · EVIDE Schema 2.1 · seven tools · August 2026
The EVIDE MCP Server connects any agentic AI system to the EVIDE evidentiary layer. It separates the accountable owner identity (DAPI-verified human or organization) from the operational execution identity (the agent), and introduces a dedicated tool for evidentiary crystallization at high-stakes governance boundaries.
API Documentation ↗ DWC / FAC Framework ↗ Request Access ↗
Contents
Live Validation May 2026
First Live AI Agent Evidentiary Crystallization
A Claude Desktop agent detected a governance uncertainty condition and independently triggered evidentiary crystallization through EVIDE via MCP. Live screenshots, real hashes, real FCC results.
View Section →
Partner Brief Confidential
Your AI agents are making decisions. Who is legally responsible?
Commercial overview for General Counsel, CRO, and Risk Management. No technical jargon. The governance case for an independent evidentiary layer.
View Section →
Section 1
1. The Identity Requirement

Before an AI agent can deposit any record into EVIDE, its owner must complete a one-time identity setup. The API key and DAPI number must belong to the human or organization responsible for the agent - not to the agent itself.

The agent produces the decision.
The owner is responsible for it.
EVIDE makes that responsibility permanent and independently verifiable.
What is DAPI?

DAPI (Digital Authentication & Personal Identity) is the identity verification layer used by EVIDE to bind API access to a real, verifiable human or organizational identity. A DAPI number is a 10-digit verified identity code issued after completing the DAPI certification process. Every record deposited through the MCP server permanently embeds the owner's DAPI identity - making responsibility attribution independently verifiable by any third party.

DAPI certification: dapi-certification.com
1
DAPI Identity Verification
Register on EVIDE with DAPI identity verification at dapi-certification.com. The DAPI number (10 digits) becomes the identity anchor for all deposits made through the agent.
2
Obtain an API Key
Request an EVIDE API key associated to your verified identity. Contact info@informaticainazienda.it. The key belongs to the owner, not to the agent.
3
Configure the MCP Server
Set environment variables before starting the server. The server validates credentials at startup and refuses to run without them.
Section 2
2. Architecture - Three Separated Layers

The MCP server introduces a clean three-layer identity separation that maps directly to the EVIDE evidentiary model:

authority - accountable human / organization (DAPI-bound) execution_identity - agent or automated system that produced the closure escalation_context - why the agent is requesting evidentiary crystallization
Full runtime architecture
SETUP (owner - one time): Owner -> DAPI verification -> API key -> configure MCP server RUNTIME (agent - automatic): AI Agent --> MCP Client --> EVIDE MCP Server (Node.js v1.3.0) // validates owner credentials // builds execution_identity from agent config // constructs EVIDE v2.1 payload --> POST /api/intake/json --> EVIDE API // validates API key + DAPI // stores execution_identity in raw_evidence_json // computes evidentiary_profile (FCC) --> returns evide_id + intake_hash + FCC state
Public release: The EVIDE MCP Server v1.3.0 is publicly available on GitHub.

Repository: github.com/emanuelcelano/evide-mcp

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

Requires Node.js >= 18. DAPI identity and active EVIDE subscription required before use.
Section 3
3. Setup
Availability
Developer Preview: The MCP Server source is public on GitHub and can be cloned freely. What is not public is access to the EVIDE API: a DAPI-verified identity and an active subscription are required before any deposit can be made. The server refuses to start without them.

To request API access, contact: info@informaticainazienda.it
VariableRequiredDescription
EVIDE_API_KEY✅API key (starts with evd_). Belongs to agent owner.
EVIDE_DAPI_NUMBER✅DAPI number (10 digits). Verified identity of agent owner.
EVIDE_OWNER_ID✅Owner identifier in source system. Embedded in every deposit.
EVIDE_OWNER_ROLEDeclared role. Default: AI System Operator.
EVIDE_AGENT_SYSTEMName of the agent system (e.g. CLARIXO). Used in execution_identity.
EVIDE_AGENT_IDSpecific agent identifier within the system. Used in execution_identity.
EVIDE_API_ENDPOINTOverride API endpoint. Default: production.
The server checks for required credentials at startup and refuses to run if EVIDE_API_KEY, EVIDE_DAPI_NUMBER, or EVIDE_OWNER_ID are missing. Active key validity is verified at first deposit. An agent without owner-bound identity cannot deposit into EVIDE.
Section 4
4. evide_intake - Standard Decision Deposit
evide_intake
Deposits a finalized AI decision into EVIDE as an independently verifiable evidentiary record. Use for standard decision deposits where the agent has produced a final outcome. For high-stakes or contestable states, use evide_escalate.
Required: source_reference, decision_type, decision_summary

Optional:
classification_status - stable | provisional | contested (default: stable)
threshold_status - met | not_met | unknown | not_defined (default: not_defined)
boundary_status - candidate | verified | verified_partial | unverifiable (default: candidate)
unresolved_signals - required for verified_partial and unverifiable
human_oversight_level - L1 | L2 | L3 (default: L2)
rationale, trace_reference, fedis_requested

Evidentiary Continuity:
parent_evide_id - EVIDE ID of a previously deposited record this one continues from
chain_type - free text describing the continuation (max 50 chars)
matter_reference - matter this lineage belongs to; inherited from the parent when omitted

External artifacts:
evidence_references - array of declared external artifacts. Per item: artifact_type, pointer, declared_origin, declared_relationship, declared_description, declared_retention_status, and optionally hash_algorithm + hash_value + hash_scope + hashed_by

Operational perimeter declarations (EVIDE ANCHOR): NEW in v1.3.0
declarations - array of 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. Per item: declaration_type, declared_value, declarant, declared_at, and optionally declared_description + declared_attribution_status
Chaining a decision to a previous record

The natural use of parent_evide_id in an agent workflow is to pass the evide_id returned by an earlier evide_escalate to the evide_intake that resolves it. The result is a declared lineage from the agent stopped here to this is how it was closed - two records, each independently verifiable, bound in a stated order.

Chain validation refuses; it does not degrade. If the parent does not exist, belongs to another evidentiary domain, is in a non-chainable status, or declares a different matter_reference, the entire deposit fails rather than silently starting a new chain. The refusals are chain_parent_not_found (422), chain_parent_not_owned (403), chain_parent_invalid_status (422) and chain_matter_mismatch (422). The 403 is the only one in the family that is an authorization decision rather than a payload error: an agent cannot correct it by changing what it sends.
Declaring external artifacts

EVIDE anchors the declaration that an artifact exists. The file itself is never uploaded, and EVIDE never computes or verifies its integrity hash - it anchors the digest exactly as the submitter declared it.

Why hashed_by is mandatory whenever a hash is declared. A digest that EVIDE does not verify is worth only as much as its stated provenance. The MCP server validates this before the request leaves, so a missing field produces a message naming it rather than a server rejection after the round trip - and it never fills the field in with the agent's own identity. An agent that merely relayed a hash computed elsewhere would otherwise be recorded as having computed it, which is precisely the kind of inference this layer exists to prevent.
Declaring evidence_references automatically sets the required extensions registry entry. 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 MCP server keeps the two aligned by construction and the agent cannot get it wrong.
Declaring the operational perimeter (EVIDE ANCHOR)

A Declaration is an explicit, attributable, time-bound statement 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.

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 are accepted by the schema (it is free text by design) but discouraged: a merged declaration cannot later be superseded, clarified, or revoked independently from the facts it bundles together.
Declaring declarations automatically sets the required extensions registry entry, using the same opt-in mechanism as evidence_references - both can be declared together in the same deposit. This MCP-level schema is deliberately simplified relative to the full API: nested subject_references, authority_source.references and declared_relations are not exposed here - they remain available through the direct intake API for callers who need the nested form.
Section 5
5. evide_escalate - Evidentiary Crystallization
evide_escalate NEW in v1.1.0
Called when an agent enters a high-stakes, contestable, legally ambiguous, or governance-sensitive state and needs to anchor the current condition independently before proceeding. Creates an independent, timestamped, owner-attributed proof that the agent recognized and documented the boundary condition at that exact moment.
Required: source_reference, agent_state_summary, escalation_trigger, escalation_reason

escalation_trigger values:
high_stakes_decision - contestable_state - legal_ambiguity
regulatory_threshold - governance_uncertainty - semantic_instability
human_review_required - authority_incoherence

Optional: trace_reference, boundary_status - candidate | verified | verified_partial | unverifiable (default: candidate), readiness_gate_id + readiness_gate_scope - required for any status other than candidate, unresolved_signals - identifiers a gate could not resolve; only with a non-candidate status, and never invented by the client

Also accepts the same parent_evide_id / chain_type / matter_reference, evidence_references, and declarations parameters as evide_intake - for an escalation that continues from an earlier record, that points at the artifacts which triggered it, or that declares the operational perimeter in effect at the moment of escalation.
Escalation use cases
🏦
Financial agent - regulatory threshold
Transaction approaches regulatory reporting threshold. Agent crystallizes state before proceeding, creating an independent record that the threshold condition was detected and documented.
⚕️
Healthcare AI - diagnosis boundary
Diagnostic confidence falls below threshold requiring human confirmation. Agent anchors the state before escalating to clinician, creating a tamper-evident record of what the system knew at that moment.
⚖️
Legal workflow agent - clause ambiguity
Contract analysis encounters an ambiguous clause. Agent crystallizes the ambiguity state before requesting human review, documenting that the uncertainty was recognized and not silently resolved.
🛡️
Moderation system - edge case
Content moderation AI encounters a boundary case. Rather than deciding silently, the agent anchors the context and flags for human judgment with an independent evidentiary record of the conditions at detection time.
🤖
Procurement agent - authority incoherence
Autonomous procurement system detects that approval authority is unclear or contested. Agent crystallizes the authority incoherence state before proceeding, creating a defensible record that the governance gap was identified, not ignored.
Example escalation call
{ "tool": "evide_escalate", "arguments": { "source_reference": "escalation-2026-tx-88291", "agent_state_summary": "Transaction TX-88291 triggers dual-authority requirement. Approval chain ambiguous.", "escalation_trigger": "authority_incoherence", "escalation_reason": "Conflicting approval policies detected. Cannot proceed without independent crystallization.", "unresolved_signals": ["approval_authority_ambiguous", "policy_conflict_detected"], "boundary_status": "verified_partial", "readiness_gate_id": "gate-compliance-v1", "readiness_gate_scope": "https://example.com/compliance-gate-v1" } }
Escalation response
EVIDE escalation successful. evide_id: f4a12bc3-... intake_hash: a7f39e... intake_timestamp_utc: 2026-05-22T11:30:00Z status: RECEIVED profile_version: 1.1 Forensic Cross-Check: DEGRADED classification: provisional runtime_visibility: partial boundary_readiness: verified_partial Decision Wave Compression: DETECTED Formal Accountability Collapse: DETECTED Inferred governance signals, not judicial determinations. Evidentiary Continuity: chain_position: 2 chain_type: escalation_resolution chain_root_evide_id: bf1b0cfd-... Owner (accountable): owner_id (AI System Operator) Agent (execution): agent_xyz / MyAgentSystem Escalation trigger: authority_incoherence Crystallization: independent evidentiary record created Agent may proceed: with documented boundary state on record
Section 6
6. Epistemic Stabilization Buffer

Three 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.

evide_intake_esb
Deposits the closure and opens a buffer over it. Accepts the same parameters as evide_intake, including evidence_references, declarations, and the chain fields. Returns evide_id, the evidentiary profile, and a buffer_id.
evide_buffer_observe
Records an intermediate observation while the buffer is open. Callable more than once.

buffer_id, stability_trend (improving | degrading | oscillating | static), continuity_state (coherent | partially_coherent | fragmented | unverifiable), causal_persistence_signal (present | attenuated | absent | inconclusive), stabilization_source, signal_count_total, buffer_notes
evide_buffer_close
Closes the buffer with a verdict.

buffer_id, buffer_verdict (stable | unstable | deferred), closure_trigger, stabilization_score, instability_reason, buffer_notes, unresolved_at_close
A real observation window is required. The server refuses a close occurring less than two seconds after the open: a buffer that closes instantly observed nothing. The measured window comes back as window_seconds. A close by timeout is forensically distinct from a close by convergence, and closure_trigger records which one it was.
stabilization_score is declared, never computed. Neither EVIDE nor the MCP client calculates it — it is a statement by whoever observed the window. Out-of-range values are rejected rather than clamped, because clamping would hide a client error. If an agent has no basis for a score, it omits the field: the client does not supply one on its behalf. Same principle as hashed_by and readiness_gate.
Phase fields are enforced before the request leaves. 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.
Lifecycle
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"
The verdict states whether the closure stabilized sufficiently to cross the boundary — not whether it is true. The server returns that distinction alongside every close, so it lives in the record and not only in this page.
Section 7
7. execution_identity and escalation_context

Every deposit made through the MCP server includes an execution_identity block. This separates the accountable identity (owner) from the operational identity (agent) in a way that is preserved in the evidentiary record.

execution_identity - included in every deposit
{ "authority": { // accountable identity - DAPI-bound "id": "owner_id", "role": "AI System Operator", "dapi_number": "0123456789", "authority_type": "accountable_identity" // explicit role in accountability chain }, "execution_identity": { // operational identity - agent "type": "agent_identity", "agent_id": "agent_xyz", "agent_system": "CLARIXO", "accountability_model": "owner_bound" } }
escalation_context - added by evide_escalate only
{ "escalation_context": { "type": "legal_crystallization", "trigger": "authority_incoherence", "reason": "Conflicting approval policies detected." } }
accountability_model: "owner_bound" declares that all responsibility for this agent's outputs converges on the DAPI-verified owner. This prevents agents from self-certifying and ensures that even fully autonomous agent populations remain bound to a finite, attributable accountability structure.
EVIDE anchors the declared application event, never the internal state of the agent that produced it. The execution_identity block identifies which agent is accountable for a deposit - it does not expose model weights, reasoning chains, confidence scores, or internal decision alternatives. What EVIDE anchors is the declared outcome, the declared authority, and the declared boundary condition at the moment of deposit, not the agent's internal cognitive process.
Section 8
8. Boundary Readiness - The Gate Is Never Fabricated

boundary_readiness declares whether an independent gate assessed the boundary at the moment of crossing. A depositing agent is not that gate: it cannot attest to its own readiness any more than a system can self-certify. The intake schema states it directly — a system cannot self-certify boundary_readiness.status = verified; that evaluation must come from an independent gate declared in readiness_gate.identifier.

Changed in v1.2.0. Earlier versions of this server built the gate automatically from the agent's own identity, producing entries such as MyAgentSystem_boundary_gate with scope evide:mcp:intake:MyAgentSystem. That was self-certification wearing the shape of a convenience: the agent declaring that the agent had verified the boundary it was itself crossing. The client no longer constructs a gate under any circumstance.
The contract
candidate // no gate required. Upstream declares readiness; no independent // assessment took place. This is the normal, honest state for an // agent deposit, and the default for both intake and escalation. { "status": "candidate", "readiness_gate": null, "visibility_surface": null, "unresolved_signals": [] } verified | verified_partial | unverifiable // readiness_gate REQUIRED and declared by the caller, through // readiness_gate_id and readiness_gate_scope. Missing either one // fails in the client, before any network call. { "status": "verified_partial", "readiness_gate": { "identifier": "gate-compliance-v1", "scope_reference": "https://.../compliance-gate-v1" }, "visibility_surface": "partial", "unresolved_signals": ["aml_flag_status"] }
Why the client refuses instead of guessing. EVIDE anchors the declaration; it cannot prove from a name that a gate is genuinely independent. That is exactly why the value must come from the caller: the only thing the system can guarantee is that somebody declared it. A fabricated gate would make that guarantee meaningless while looking identical in the record.
What this means in practice. An agent deposit will normally carry candidate, and its Forensic Cross-Check, DWC and FAC dimensions will read unknown. That is an evidentiary result, not a processing failure: with no independent assessment there is nothing to cross-check against. If a gate — a human supervisor, an orchestrator, an external governance component — later assesses the boundary, it can declare its own verified_partial with its own gate identity. The agent never has to impersonate it.
unresolved_signals belongs to the gate, not to the agent: it carries the identifiers a gate could not resolve during its assessment. With candidate the array is empty by definition rather than by restriction, because no assessment took place. What the agent could not decide is a different thing, and lives in escalation_reason and agent_state_summary.
Section 9
9. Claude Desktop Configuration
claude_desktop_config.json
{ "mcpServers": { "evide": { "command": "node", "args": ["/absolute/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" } } } }
File location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
evide_owner_info
Returns the configured identity separation for this instance - showing accountable identity (owner) and execution identity (agent) separately. Does not expose the full API key. Useful for verifying configuration before running live deposits.
evide_check
Returns verification guidance for a previously deposited record. Provides instructions for verifying intake_hash against the live EVIDE registry using the canonicalization algorithm at docs/payload-canonicalization/.
Scope of the Current Abstractions

The MCP server does not expose the full EVIDE intake schema. It exposes the subset an autonomous agent can declare truthfully about its own closure, and fixes the rest.

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 the server always sends as true. This is not a shortcut. The server refuses to 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 or L3 — and only the existence of a declared authority is fixed, because the transport itself guarantees it.

A hardcoded value seen from outside is indistinguishable from a shortcut. Stating which values are fixed, and why, is the difference between a documented boundary and an apparent limitation — the same discipline the evidentiary layer applies to its own records: declare the decision rather than leave it to be inferred from an absence.
Section 10
10. The Governance Principle
The agent produces.
The owner is responsible.
EVIDE makes that responsibility permanent.
Across machine-scale decision environments. Converging on a DAPI-verified identity.

As agent populations grow and decision velocity increases, the accountability structure remains anchored at the owner level. One human or organization can own many agents. All their deposits converge on a single DAPI-verified accountability identity.

This is where the Decision Wave Compression (DWC) framework becomes relevant: as aggregate agent throughput grows, the pressure on the owner's accountability capacity may itself become a governance signal. The MCP server's accountability_model: owner_bound declaration is what makes that signal computable.

EVIDE MCP is not a logging tool. It is an agent-to-evidentiary accountability boundary - the layer that transforms agent outputs into independently verifiable, owner-attributed, timestamped evidentiary records that can survive regulatory review, legal dispute, or audit without requiring access to the agent's internal systems.
EVIDE anchors the declared application event,
never the internal state of the system that produced it.
This is what separates an evidentiary boundary from a debugging or observability tool.
References

EVIDE API Documentation: app.certifywebcontent.com/docs/evide-intake-schema/

Payload Canonicalization: app.certifywebcontent.com/docs/payload-canonicalization/

DWC / FAC Framework: Decision Wave Compression - Technical Note v0.1

EVIDE Framework: certifywebcontent.com - Evidentiary Deposit

DAPI Identity Certification: dapi-certification.com

GitHub Repository: github.com/emanuelcelano/evide-mcp

Pricing & Service Conditions: app.certifywebcontent.com/pricing

API access: info@informaticainazienda.it

Any agent. Any system. One accountability boundary.

evide_intake - deposit a finalized decision
evide_escalate - crystallize a high-stakes boundary state
evide_intake_esb + observe + close - observe stabilization over a real window
All bound to the owner. All independently verifiable.

"The agent produces. The owner is responsible.
EVIDE makes that responsibility permanent."

API access: info@informaticainazienda.it