EAD Factory MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

generate_evidence

Register a new evidence (legacy top-level name; not scoped to a specific evidence group at creation time, unlike evidence_group_evidence_register).

Instructions

Register a new evidence (legacy top-level name; not scoped to a specific evidence group at creation time, unlike evidence_group_evidence_register). Use for standalone evidence outside the group-based flow, or for continuity with the legacy EAD-Factory-MCP integration. Requires the file's SHA-256 hash. Prefer evidence_create_sealed for a new, complete evidence group + evidence + seal flow. Custody type: INTERNAL = EAD Factory stores and custodies the file itself. | EXTERNAL = The file lives outside EAD Factory — you attest to its hash only, EAD Factory never stores the bytes. Testimony (qualified proof) provider family: TSP = Trusted Service Provider — eIDAS-qualified electronic timestamp; the legally strongest proof tier. | DLT = Distributed Ledger Technology — blockchain-anchored proof; immutable and independently verifiable.

Input Schema

TableJSON Schema

Name	Required	Description
`hash`	Yes
`type`	No
`title`	No
`fileName`	No
`fileSize`	No
`metadata`	No
`createdBy`	No
`testimony`	Yes
`capturedAt`	Yes
`evidenceId`	Yes	MANDATORY. UUID of the evidence record. Obtain from evidence_group_evidence_register or generate_evidence.
`custodyType`	Yes
`deletionDate`	No
`deletionType`	No
`requiredTestimonyProviders`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No
`expiration`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.0Sep 14, 2026

changedInput schema / properties / capturedAt / pattern

Previous value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$"New value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"

changedInput schema / properties / deletionDate / anyOf

Previous value: -[
-  {
-    "format": "date-time",
-    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv1.3.1Aug 5, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only convey readOnly/idempotent/destructive hints; the description goes further by explaining custody behavior (INTERNAL stores/custodies the file, EXTERNAL never stores bytes) and the legal weight of TSP vs DLT testimony. It also discloses the legacy/group-scoping constraint. Minor gaps remain, such as how file bytes are supplied for INTERNAL custody, but the description adds substantive behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with purpose and usage, then uses compact labeled blocks for custody and testimony. The pipe-separated definitions are dense but each earns its place given the semantic complexity; it could be tightened slightly but is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter registration tool with only 7% schema description coverage, the description covers the two hardest decision areas: when to use it vs evidence_create_sealed, and what custody/testimony values mean. The output schema covers the return shape. It is not fully complete, since capturedAt and requiredTestimonyProviders are not addressed in prose, but the remaining gaps are partially bridged by schema names and formats.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 7%, so the description must compensate. It adds real meaning for hash (SHA-256), custodyType (INTERNAL vs EXTERNAL semantics), and testimony provider families (TSP/DLT). However, it never explains required params like capturedAt or requiredTestimonyProviders, and optional fields such as metadata, deletionDate, deletionType, and fileSize are left entirely to their names and schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair ('Register a new evidence') and immediately clarifies it is the legacy top-level registration, not group-scoped, explicitly distinguishing it from evidence_group_evidence_register. This makes the tool's role unambiguous against a large sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the exact conditions for using this tool ('standalone evidence outside the group-based flow' or 'continuity with legacy EAD-Factory-MCP integration') and explicitly tells the agent to prefer evidence_create_sealed for a complete group+evidence+seal flow. This is explicit routing with a named alternative, not just implied context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server