Skip to main content
Glama
Sign In
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

prepare_document_proof

Computes canonical JSON, payloadHash, Merkle contentRoot, and per-field inclusion paths from a structured document, so you can anchor it and generate field proofs without storing data server-side.

Instructions

Turn a structured document into everything the proof tools need: canonical JSON and its payloadHash (what anchor_document anchors), a Merkle contentRoot over an ORDERED list of up to 16 proof fields, and per-field inclusion paths ready for the proveField* calls of submit_vault_call. kind "uint" (default) scales a numeric value; kind "bytes" (NIGHTGATE >= 0.16.0) enters a STRING field as the digest of the exact string, feeding the equality/membership proofs. Keep the field order stable across anchor and proof: it is part of the tree identity. Compute-only and synchronous, nothing is stored server-side. Leaves are SALTED: the response carries a per-field salt (feed it back as fieldSalt / claim salt), the full opening (salt seed + all 16 slots, needed for the cross-root proofs) and schemaId (anchor it alongside the root). STORE the opening with the document: losing the salt seed makes the anchored root unprovable, publishing it makes leaf hashes guessable. Pass saltSeed to reproduce an EXISTING anchored root byte-for-byte; omit it for a fresh document. The returned fields carry witness material (scaled values / digests / salts): treat as sensitive. Store canonicalDocument at your storageRef; re-serializing with different key order will not re-hash equal.

Input Schema

NameRequiredDescriptionDefault
documentYesThe full document as a JSON object; all of it goes into payloadHash
saltSeedNoReuse a stored salt seed to reproduce an already-anchored root; omit for a fresh document (random seed)
proofFieldsYesORDERED list of fields to make provable (leaf index = position). Up to 16 on the default vault, up to 32 with compiledArtifactRef attestation-vault-32
compiledArtifactRefNoContract artifact ref, defaults to 'attestation-vault-32'; 'attestation-vault' for a 16-slot vault

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.18.3
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / compiledArtifactRef / description
      Previous value: -"Contract artifact ref, defaults to 'attestation-vault'"New value: +"Contract artifact ref, defaults to 'attestation-vault-32'; 'attestation-vault' for a 16-slot vault"
    • addedInput schema / properties / document / propertyNames
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / proofFields / description
      Previous value: -"ORDERED list of fields to make provable (leaf index = position)"New value: +"ORDERED list of fields to make provable (leaf index = position). Up to 16 on the default vault, up to 32 with compiledArtifactRef attestation-vault-32"
    • removedInput schema / properties / proofFields / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / proofFields / items / properties / kind
      Added value: +{
+  "description": "Leaf kind: 'uint' (default, numeric scaled value) or 'bytes' (string value entered as digest of the exact string)",
+  "enum": [
+    "uint",
+    "bytes"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / proofFields / items / properties / scale / description
      Previous value: -"Value scale (default 1000: milli-units)"New value: +"Value scale (default 1000: milli-units); only valid for kind 'uint'"
    • changedInput schema / properties / proofFields / maxItems
      Previous value: -16New value: +32
    • addedInput schema / properties / saltSeed
      Added value: +{
+  "description": "Reuse a stored salt seed to reproduce an already-anchored root; omit for a fresh document (random seed)",
+  "pattern": "^[0-9a-fA-F]{64}$",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden and does so well: compute-only, synchronous, nothing stored server-side, salted leaves, returned witness material treated as sensitive, and a strong warning that losing the salt seed makes the anchored root unprovable while publishing it makes leaf hashes guessable. It also discloses the re-serialization caveat for canonicalDocument.

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 dense and lengthy, but the core purpose is front-loaded before the operational caveats. The length is justified by the cryptographic and storage risks being communicated, though the single-paragraph structure could be easier to scan with clearer separation of input guidance, output artifacts, and storage requirements.

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?

This is a complex, nested, no-output-schema tool, and the description still explains the returned artifacts (payloadHash, contentRoot, inclusion paths, salt, opening, schemaId), their downstream consumers, storage obligations, sensitivity, and reproducibility via saltSeed. An agent has enough context to invoke it correctly and handle its outputs safely.

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 100%, so the schema already documents document, saltSeed, proofFields, kind, scale, field, and compiledArtifactRef in detail. The prose reinforces the kind and saltSeed semantics and adds that field order is part of the tree identity, but most parameter meaning is already in the schema, making 3 the appropriate baseline.

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 and resource: "Turn a structured document into everything the proof tools need," then enumerates canonical JSON, payloadHash, contentRoot, and inclusion paths. It distinguishes this preparatory tool from anchor_document and submit_vault_call by naming both and explaining what each downstream step consumes.

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?

It clearly positions the tool as a pre-anchoring/pre-proof preparation step and names the siblings that consume its output. It also gives a concrete when-to-use rule for saltSeed: pass it to reproduce an existing anchored root, omit it for a fresh document. It stops short of explicit "do not use this when..." guidance or a full decision tree among alternatives.

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