Skip to main content
Glama
g-digital-by-Garrigues

EAD Factory MCP Server

Official

evidence_group_evidence_register

Register a new evidence in an open evidence group to initiate the two-step upload process and obtain the upload URL for the file bytes.

Instructions

Register a new evidence in a group — the first step of a 2-step upload (register, then PUT the file bytes to the returned upload URL). Use for each file you want to add to an OPEN evidence group. Requires: evidence_group_create → evidenceGroupId, evidence_case_file_create → caseFileId, and the file's SHA-256 hash (compute it before calling, or use the evidence_create_sealed composite tool which does this for you). Do not call evidence_group_close until every registered evidence's bytes have been uploaded. 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
NameRequiredDescriptionDefault
hashYes
typeNo
titleNo
fileNameNo
fileSizeNo
metadataNo
createdByNo
testimonyYes
capturedAtYes
caseFileIdYesMANDATORY. UUID of the parent case file. Obtain from evidence_case_file_create.
evidenceIdYesMANDATORY. UUID of the evidence record. Obtain from evidence_group_evidence_register or generate_evidence.
custodyTypeYes
deletionDateNo
deletionTypeNo
evidenceGroupIdYesMANDATORY. UUID of the evidence group. Obtain from evidence_group_create.
requiredTestimonyProvidersYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
expirationNo
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, etc.), the description reveals the 2-step upload flow, defines custodyType INTERNAL/EXTERNAL, explains testimony providers TSP/DLT, and notes prerequisites for hash computation. This provides rich behavioral context the annotations do not capture.

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

Conciseness5/5

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

The description is dense yet organized, front-loading the core purpose and then using pipes and clear separators for enum semantics. Every sentence adds non-redundant, actionable information, making the length justified for the tool's complexity.

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

Completeness5/5

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

For a tool with 16 parameters and critical workflow interactions, the description covers prerequisites, the 2-step upload process, custody/proof semantics, and a warning about evidence_group_close. Combined with an output schema for return values, this is complete for correct invocation.

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

Parameters5/5

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

Schema description coverage is only 19%, but the description compensates by defining the hash as SHA-256, explaining custodyType enum meanings, and detailing testimony provider options. It also clarifies how to obtain key IDs (evidenceGroupId, caseFileId, evidenceId), adding meaning beyond the spartan 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 states 'Register a new evidence in a group' with a specific verb and resource, and clarifies it is the first step of a 2-step upload. This clearly distinguishes it from siblings like evidence_group_evidence_get/delete and evidence_create_sealed.

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?

Explicitly says 'Use for each file you want to add to an OPEN evidence group' and names an alternative (evidence_create_sealed composite tool). Also warns not to call evidence_group_close until uploads complete, giving clear when-to-use and constraint information.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/g-digital-by-Garrigues/EAD-Factory-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server