Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO

verify_attestation

Verifies an attester's payload-hash record in a live Midnight AttestationVault without a tx hash, using attesterId + payloadHash or a bound documentId; optionally checks contentRoot/schemaId.

Instructions

Verify against LIVE Midnight contract state that an attester's record of a payload hash stands in an AttestationVault (crawler-free, no txHash needed). A record is ONE attester's attestation of ONE payload (ledger key recordKey(attesterId, payloadHash)): name it by attesterId + payloadHash, or by a bound documentId, which resolves to exactly one record and reveals its attester. Optionally also checks that the anchored content root / schema id match. Returns verified:false (not an error) when absent; the result carries attesterId, payloadHash, recordKey and documentId. bindingRegistered is only about documentId lookups: true when the vault registrar assigned that id to this attester. A record anchored without a document id reports false, and that is fine. Free: it reads the public verify service.

Input Schema

NameRequiredDescriptionDefault
networkNoRead from another network public indexer instead of the configured one
schemaIdNoOptional anchored schema id to check; the result reports schemaOk, so an examiner can pin the canonical field list
attesterIdNoThe attester whose record to check (64 hex; get_attester_identity for this server's own). Required unless documentId is given
documentIdNoA bound document id (64 hex): resolves the record through the vault's document bindings
contentRootNoOptional anchored content root to check (64 hex)
payloadHashNoThe attested payload hash (sha256, 64 hex). Required with attesterId; next to documentId it must match the bound record
contractAddressNoAttestationVault address (64 hex); default the shared sandbox vault of the network (preprod, preview)
compiledArtifactRefNoContract artifact ref, defaults to 'attestation-vault-32'; 'attestation-vault' for a 16-slot vault

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.18.3
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / attesterId
      Added value: +{
      +  "description": "The attester whose record to check (64 hex; get_attester_identity for this server's own). Required unless documentId is given",
      +  "pattern": "^[0-9a-fA-F]{64}$",
      +  "type": "string"
      +}
    • 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"
    • changedInput schema / properties / contractAddress / description
      Previous value: -"AttestationVault contract address"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}$"
    • addedInput schema / properties / documentId
      Added value: +{
      +  "description": "A bound document id (64 hex): resolves the record through the vault's document bindings",
      +  "pattern": "^[0-9a-fA-F]{64}$",
      +  "type": "string"
      +}
    • changedInput schema / properties / payloadHash / description
      Previous value: -"The attested payload hash (sha256, 64 hex)"New value: +"The attested payload hash (sha256, 64 hex). Required with attesterId; next to documentId it must match the bound record"
    • addedInput schema / properties / schemaId
      Added value: +{
      +  "description": "Optional anchored schema id to check; the result reports schemaOk, so an examiner can pin the canonical field list",
      +  "pattern": "^[0-9a-fA-F]{64}$",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "contractAddress",
      -  "payloadHash"
      -]
  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?

No annotations are provided, so the description carries the full burden and does: it discloses that a miss returns verified:false rather than an error, that it reads live on-chain state through a public service at no cost, and exactly which fields the result carries. It also preempts a likely misreading by explaining that bindingRegistered=false is normal for records anchored without a document id.

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 core action and the record-identity model are front-loaded, and every following sentence supplies decision-relevant detail: lookup modes, optional cross-checks, the not-an-error result, and the bindingRegistered caveat. Dense but with no filler.

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?

With eight optional parameters, no annotations and no output schema, the description still covers the missing pieces: the return contract (verified, attesterId, payloadHash, recordKey, documentId, schemaOk, bindingRegistered) and the failure semantics. Nothing an agent needs in order to call and interpret this tool is absent.

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 coverage is 100%, so the baseline is 3; the description goes further by stating cross-parameter rules the schema cannot express (attesterId required unless documentId is given; payloadHash must match the bound record when documentId is used) and by explaining what documentId lookup reveals. It does not elaborate on network or compiledArtifactRef beyond schema text.

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

Purpose4/5

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

States a specific verb and resource: verify an attester's record of a payload hash in an AttestationVault against LIVE contract state, with the zero-crawl/no-txHash clarification. It also defines the record identity model (one attester, one payload, recordKey(attesterId, payloadHash)), which makes the tool concrete. It does not name or differentiate from the sibling verify_predicate, which keeps it off a 5.

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?

Gives clear conditions: use name-based lookup by attesterId + payloadHash, or via a bound documentId, and optionally pin contentRoot/schemaId. The 'crawler-free, no txHash needed' and 'free, reads the public verify service' notes tell the agent when this is cheaper than transaction-based verification. No explicit exclusion relative to verify_predicate or the anchor/submit siblings.

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