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

EAD Factory MCP Server

Official
by g-digital-by-Garrigues
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

evidence_update

Updates a single evidence's editable metadata (e.g. name, description) by evidenceId. The file content and hash are immutable — re-register a new evidence for changed files.

Instructions

Updates a single evidence's editable metadata (e.g. name, description) by evidenceId. The file content and hash are immutable — re-register a new evidence for changed files. Requires: evidence_group_evidence_register or generate_evidence → evidenceId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
custodyNo
metadataNo
createdByNo
evidenceIdYesMANDATORY. UUID of the evidence record. Obtain from evidence_group_evidence_register or generate_evidence.
deletionDateNo
deletionTypeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / deletionDate / anyOf
      Previous value: -[
-  {
-    "properties": {
-      "provided": {
-        "type": "boolean"
-      },
-      "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": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "properties": {
+      "provided": {
+        "type": "boolean"
+      },
+      "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": "object"
+  },
+  {
+    "type": "null"
+  }
+]
  2. First observedv1.3.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only indicate a non-read-only, non-idempotent operation, so the description carries most of the burden. It adds meaningful behavioral context: file content and hash are immutable, changed files require re-registration, and evidenceId is mandatory and must come from two named tools. This exceeds simple annotations and clarifies update boundaries without contradicting destructiveHint=false.

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 two sentences with zero waste: the first sentence gives the main action and scope, the second adds the critical immutability constraint and prerequisite. It is front-loaded and easy to scan. It could have been slightly more explicit about which metadata fields are editable, but overall it is concise and readable.

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

Completeness2/5

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

The tool has 7 parameters, nested objects, and no output schema, yet the description covers only the general purpose and identity requirement. It omits field-level semantics (e.g., how custody, deletionDate, and deletionType are used) and whether unprovided fields are ignored or reset. An agent assembling a correct call would still have to inspect the schema heavily to understand editing behavior.

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

Parameters2/5

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

Schema description coverage is only 14%, with only evidenceId described in the schema, so the description needs to compensate. It only gives examples ('name, description') and says the target is editable metadata, but does not explain custody, metadata, createdBy, deletionDate, deletionType, or whether updates are partial vs full. Most parameters remain ambiguous from both schema and description.

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 a specific verb and resource ('Updates a single evidence's editable metadata by evidenceId') and explicitly scopes the tool to one evidence, distinguishing it from sibling evidence_update_bulk. The mention of immutability for content/hash prevents confusion with file-modifying tools. An agent can immediately tell what this tool is for.

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

Usage Guidelines4/5

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

The description provides a clear when-to-use context and a strong when-not: if the file content or hash changes, the agent should re-register a new evidence instead of using this tool. It also states the prerequisite chain (evidence_group_evidence_register or generate_evidence → evidenceId), which routes the agent to correct predecessor tools. It does not explicitly name evidence_update_bulk as the alternative for multiple records, but the 'single' wording conveys that.

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

Deploy Server

Other Tools