MCP Server

Developer Preview

v1.1.0

EVIDE MCP Server

Agent-to-Evidentiary Accountability Boundary for Agentic AI Systems

v1.1.0 · Node.js · MCP Protocol · EVIDE Schema 2.0 · May 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

1. The Identity Requirement
2. Architecture - Three Separated Layers
3. Setup
4. evide_intake - Standard Decision Deposit
5. evide_escalate - Evidentiary Crystallization
6. execution_identity and escalation_context
7. Boundary Readiness - Automatic Handling
8. Claude Desktop Configuration
9. The Governance Principle

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

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.

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.

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 v1.1.0 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.1.0) // validates owner credentials // builds execution_identity from agent config // constructs EVIDE v2.0 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.1.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 EVIDE MCP Server is currently available to API partners under the Developer Preview program. Distribution is managed directly - no public npm package or repository is available at this stage.

To request access to the MCP Server source and setup guide, contact: info@informaticainazienda.it

Variable	Required	Description
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_ROLE		Declared role. Default: `AI System Operator`.
EVIDE_AGENT_SYSTEM		Name of the agent system (e.g. `CLARIXO`). Used in `execution_identity`.
EVIDE_AGENT_ID		Specific agent identifier within the system. Used in `execution_identity`.
EVIDE_API_ENDPOINT		Override 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

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: unresolved_signals (auto-populated if empty), boundary_status (verified_partial | unverifiable), trace_reference

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" } }

Escalation response

EVIDE escalation successful. evide_id: f4a12bc3-... intake_hash: a7f39e... intake_timestamp_utc: 2026-05-22T11:30:00Z status: RECEIVED Forensic Cross-Check: DEGRADED classification: provisional runtime_visibility: partial boundary_readiness: verified_partial 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. 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.

Section 7

7. Boundary Readiness - Automatic Handling

The server automatically constructs a valid boundary_readiness object for any status value. This prevents validation errors when passing non-candidate states.

buildBoundaryReadiness logic

// candidate: no gate, no visibility { "status": "candidate", "readiness_gate": null, "visibility_surface": null, "unresolved_signals": [] } // verified: gate auto-built, declared_complete visibility { "status": "verified", "readiness_gate": { "identifier": "CLARIXO_boundary_gate", "scope_reference": "evide:mcp:intake:CLARIXO" // governance namespace }, "visibility_surface": "declared_complete", "unresolved_signals": [] } // verified_partial -> visibility: partial, signals required // unverifiable -> visibility: insufficient, signals required

On scope_reference: the auto-generated scope_reference follows an evide:mcp:intake:{agent_system} namespace pattern. This introduces governance namespace and gate provenance tracking - making clear that the gate is the MCP server acting on behalf of the agent system.

Section 8

8. 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/.

Section 9

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

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
Both bound to the owner. Both independently verifiable.

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

API access: info@informaticainazienda.it