Skip to main content
Glama
Sign In
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

anchor_document

Anchors a document's SHA-256 hash on the Midnight blockchain in one call, with a sponsor paying the fee and a check that the attestation record landed on-chain.

Instructions

Anchor a document hash on Midnight in one call: builds the attest transaction here with the caller seed, a sponsor pays the fee, and the tool waits until it landed (about 1 to 2 minutes; the first call also downloads the prover keys). The record belongs to this seed (attesterId). Only the hash and the hash of the metadata go on-chain; keep the document yourself. With contentRoot and schemaId from prepare_document_proof it also anchors the content root, which the field claims of submit_vault_call need. Returns { status, attesterId, payloadHash, contractAddress, metadataJson, txHash, transactionHash, timings, check }; check is the verify_attestation call that shows the record on-chain. If the call was cut off or came back pending, run it again with the same arguments: it picks up the job it started and submits nothing new (the answer says deduplicated). A second, separate call with the same arguments needs a new idempotencyKey.

Input Schema

NameRequiredDescriptionDefault
sha256Yessha256 of the document (64 hex); it becomes the payloadHash
metadataNoPublic metadata; its sha256 is anchored with the hash. Default none
schemaIdNoSchema id from prepare_document_proof (64 hex); needs contentRoot
contentRootNoContent root from prepare_document_proof (64 hex); needs schemaId
idempotencyKeyNoDedupes retries of the same anchor
contractAddressNoAttestationVault address (64 hex); default the shared sandbox vault of the network (preprod, preview)
compiledArtifactRefNoVault lineage, default 'attestation-vault-32' (the sandbox vaults); 'attestation-vault' for a 16-slot vault

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 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: +"Vault lineage, default 'attestation-vault-32' (the sandbox vaults); 'attestation-vault' for a 16-slot vault"
    • addedInput schema / properties / compiledArtifactRef / enum
      Added value: +[
+  "attestation-vault",
+  "attestation-vault-32"
+]
    • addedInput schema / properties / contentRoot
      Added value: +{
+  "description": "Content root from prepare_document_proof (64 hex); needs schemaId",
+  "pattern": "^[0-9a-fA-F]{64}$",
+  "type": "string"
+}
    • removedInput schema / properties / contentType
      Removed value: -{
-  "description": "MIME type, informational",
-  "type": "string"
-}
    • changedInput schema / properties / contractAddress / description
      Previous value: -"AttestationVault deployment to anchor into"New value: +"AttestationVault address (64 hex); default the shared sandbox vault of the network (preprod, preview)"
    • removedInput schema / properties / contractAddress / minLength
      Removed value: -1
    • addedInput schema / properties / contractAddress / pattern
      Added value: +"^[0-9a-fA-F]{64}$"
    • changedInput schema / properties / idempotencyKey / description
      Previous value: -"Dedupes retries of the same anchor request"New value: +"Dedupes retries of the same anchor"
    • changedInput schema / properties / metadata / description
      Previous value: -"Public metadata object; its hash is anchored alongside"New value: +"Public metadata; its sha256 is anchored with the hash. Default none"
    • addedInput schema / properties / metadata / propertyNames
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / schemaId
      Added value: +{
+  "description": "Schema id from prepare_document_proof (64 hex); needs contentRoot",
+  "pattern": "^[0-9a-fA-F]{64}$",
+  "type": "string"
+}
    • removedInput schema / properties / sessionId
      Removed value: -{
-  "description": "Wallet session id that signs and submits",
-  "format": "uuid",
-  "type": "string"
-}
    • changedInput schema / properties / sha256 / description
      Previous value: -"sha256 of the document content (64 hex), becomes the on-chain payload hash"New value: +"sha256 of the document (64 hex); it becomes the payloadHash"
    • removedInput schema / properties / size
      Removed value: -{
-  "description": "Content size in bytes, informational",
-  "minimum": 0,
-  "type": "integer"
-}
    • removedInput schema / properties / sponsorSessionId
      Removed value: -{
-  "description": "Optional second session that pays the dust fee",
-  "format": "uuid",
-  "type": "string"
-}
    • removedInput schema / properties / storageRef
      Removed value: -{
-  "description": "Where the bytes live, e.g. file://, s3://, ipfs://",
-  "minLength": 1,
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "sha256",
-  "storageRef",
-  "sessionId",
-  "contractAddress"
-]New value: +[
+  "sha256"
+]
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well. It discloses sponsor fee payment, wait time, first-call prover-key download, on-chain data limits, seed ownership via attesterId, return fields, retry deduplication behavior, and that a separate same-argument call requires a new idempotencyKey.

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 but front-loaded, starting with the core action and then covering return shape, timing, on-chain visibility, and retry semantics. Every sentence adds operational information needed to invoke or safely retry the tool.

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 complex, multi-step anchoring operation with no annotations and no output schema, the description is highly complete. It explains asynchronous timing, sponsor mechanics, return fields, verification linkage, and idempotency behavior, leaving little an agent needs to infer before calling it.

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

Parameters4/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 defines each parameter. The description adds useful cross-parameter meaning: schemaId and contentRoot come from prepare_document_proof, the content root is needed by submit_vault_call field claims, and idempotencyKey governs retry versus new-call semantics.

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: anchoring a document hash on Midnight in a single call. It also clarifies the end-to-end scope—building the attest transaction, sponsor-paid fee, waiting for landing—and names related tools such as prepare_document_proof and submit_vault_call, so the agent can distinguish it from siblings.

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 provides clear usage context: call this to anchor a document hash, optionally anchor a content root when schemaId and contentRoot came from prepare_document_proof, and retry with the same arguments if interrupted or pending. It does not explicitly state when not to use it, but the pipeline relationships with prepare_document_proof, submit_vault_call, and verify_attestation are clear.

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