Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

build_sponsorable_transaction

Build, prove and sign an AttestationVault call locally, then return fee-unpaid transaction bytes for a sponsor to submit, keeping the caller seed and witness secret on this machine.

Instructions

Build, prove and sign an AttestationVault call LOCALLY and hand back the bytes, for a sponsor on another server or a later hand-over; submit_vault_call does build and submit in one go. The caller seed (NIGHTGATE_SEED_HEX, else the seed file) stays here, the attestation secret is derived from it, nothing secret leaves this machine. The fee-unpaid transaction stays in this process under the returned txId (its sha256; characters and bytes alongside), or is written to outFile: UNBOUND by default (hand the txId to sponsor_unbound_transaction, parallel channel) or bound with bind:true (sponsor_finalized_transaction). The on-chain effect carries the attester id of THIS builder (returned). Proving takes 20-60 s in-process (the first call also fetches the prover keys from the NIGHTGATE /zk-config); NIGHTGATE_PROOF_SERVER_URL switches to a proof server. Needs @odatano/nightgate-tx installed next to the MCP server. params by call: attest {payloadHash, metadataHash}; anchorContentRoot {payloadHash, contentRoot, schemaId}; grantDisclosure {payloadHash, grantee, level 0|1|2}; revokeDisclosure {payloadHash, grantee}; registerPassport {passportId, ownerId}; bindPassport {passportId, payloadHash}. The owner-gated calls address THIS builder's own record of the payload (the circuit derives recordKey(attesterId, payloadHash) from the caller). ZK CLAIMS, proven here with no wallet on the server and no witness ever sent to it, address a record explicitly: pass payloadHash (this builder's record) or payloadHash + attesterId (another attester's record) or recordKey directly: proveFieldPredicate {payloadHash, fieldKey, threshold, op 0=lessOrEqual|1=greaterOrEqual} plus merkleProof {fieldValue, fieldSalt, siblings, dirs}; proveFieldEquality {payloadHash, fieldKey, expectedDigest} plus merkleProof {fieldSalt, siblings, dirs}; proveFieldMembership {payloadHash, fieldKey, setRoot} plus merkleProof {fieldDigest, fieldSalt, siblings, dirs, setProof}; proveFieldsUnchangedExcept {payloadHashA, payloadHashB, allowedMask} and proveFieldsDiffer {payloadHashA, payloadHashB, k} (optionally attesterIdA / attesterIdB, or recordKeyA / recordKeyB), both plus docPair {schema, openingA, openingB}. Every witness field comes straight out of prepare_document_proof. All hashes 64 hex. The built bytes are valid for the transaction TTL (~30 min) and against the contract state at build time: if the sponsor job ends CHAIN_EXECUTION_FAILED, build again.

Input Schema

NameRequiredDescriptionDefault
bindNofalse (default): unbound for sponsor_unbound_transaction; true: finalized for sponsor_finalized_transaction
callYesWhich circuit to call
paramsYesThe call parameters (see the per-call list in the description)
docPairNoWITNESS bundle { schema, openingA, openingB } for proveFieldsUnchangedExcept / proveFieldsDiffer; both documents must be prepared with the same ordered field list
outFileNoAlso write the built bytes as base64 to this path, for a sponsor tool on another server (its file argument)
merkleProofNoWITNESS material for the proveField* calls, as prepare_document_proof returns it for that field (fieldValue/fieldDigest, fieldSalt, siblings, dirs, setProof). It is consumed by the local prover and never sent to NIGHTGATE
contractAddressNoAttestationVault address (64 hex); default the shared sandbox vault of the network (preprod, preview)
compiledArtifactRefNoVault lineage to build against, defaults to 'attestation-vault-32' (the hosted sandbox vaults). Use 'attestation-vault' for a 16-slot vault: it has its own circuits, so the builder loads that contract class and fetches ITS prover keys from the server's /zk-config. The address must belong to the lineage named here

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.3

TDQS

A4.8/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: nothing secret leaves the machine, the seed stays local, the fee-unpaid tx is held in-process under txId (its sha256) or written to outFile, proving takes 20-60 s with a first-call /zk-config key fetch, NIGHTGATE_PROOF_SERVER_URL switches to a proof server, and the @odatano/nightgate-tx dependency is declared. The TTL (~30 min) and build-time-state caveat are exactly the operational facts an agent needs before spending a minute on a proof.

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

Conciseness3/5

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

Nearly every clause earns its place, but it is delivered as one dense semicolon-chained paragraph rather than front-loaded sections, so the per-call param catalog and the ZK-claim addressing rules are hard to scan. A few facts are duplicated from the schema (bind, contractAddress default). Appropriate length for the complexity, poor structure.

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?

Covers the operation, the secrecy model, output handling, downstream hand-off, timing, dependencies, error recovery, and return values (txId as sha256, the returned attester id) despite no output schema. For an 8-param, nested-object, multi-circuit tool with no annotations, nothing material is missing.

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 coverage is 100%, so baseline is 3, but the description adds semantics the schema does not carry: the schema defers to the description for per-call params, and the description supplies the full per-circuit param list plus the three record-addressing modes (payloadHash, payloadHash+attesterId, recordKey) and the recordKey(attesterId, payloadHash) derivation rule. That is substantive value beyond the structured fields.

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?

States a precise compound verb+resource: build, prove and sign an AttestationVault call locally and return the bytes. It immediately distinguishes itself from the sibling that does build+submit in one go (submit_vault_call), so an agent can route without opening either schema.

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 names the alternative (submit_vault_call) and the condition that selects it, then routes onward by output mode: sponsor_unbound_transaction by default, sponsor_finalized_transaction with bind:true. It also names prepare_document_proof as the source of every witness field and gives a retry rule (rebuild if the sponsor job ends CHAIN_EXECUTION_FAILED).

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