Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

call_contract

Invoke a circuit on an installed contract with JSON arguments; the call is built, proven, and signed here while a sponsor covers fees, so no NIGHT or DUST is needed.

Instructions

Call a circuit on any contract whose lineage package is installed next to this server (laid out like @odatano/contract-: contract.json, the compiled class, the proving files). The call is built, proven and signed here from the caller seed and a sponsor pays, so the caller holds neither NIGHT nor DUST. Arguments are JSON in circuit order; tagged values: {"$bytes":""}, {"$uint":""}, and {"$coin":{"tokenType","amount"}} for a shielded coin the circuit receives, funded from this wallet, the one get_swap_wallet shows (a gateway key syncs it through the gateway, a direct instance needs NIGHTGATE_INDEXER_HTTP_URL and _WS_URL; the tool waits up to 20 s for its sync, a first sync from genesis takes about 5 minutes). {"$night":""} is a NIGHT amount the circuit takes from this wallet (receiveUnshielded, a deposit or a stake): the wallet syncs its NIGHT coins and pays them in, the sponsor adds only the fee; set payUnshielded when the amount is no argument. Needs allowUnshieldedOffers on the grant; one pay-in runs at a time. A payout the circuit makes to this wallet (sendUnshielded, a claim or a refund) needs nothing extra: NIGHTGATE 0.40.0 sponsors it. A call that funds anything is bound and goes through the serial sponsor channel, one without through the parallel one. Witnesses come from the package when its contract.json names a witnesses module (createWitnesses gets a secret derived from the seed for that package; the private state they return is kept once the call landed). The contract has to be sponsorable (its address and circuit on the sponsor's policy). The answer waits for the block; a call the chain refused gives its coins back. The tool waits until the job settled (about 1 minute) and returns { status, txHash, transactionHash, result }. failed: next says what to do. 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
argsNoCircuit arguments in order, with the tagged values described above
circuitYesThe circuit to call
packageYesThe installed lineage package, for example @meridian/contract-m402
payUnshieldedNoThe circuit takes unshielded tokens from this wallet; implied by a $night argument
idempotencyKeyNoDedupes retries; an identical call without a new key returns the first job
contractAddressYesThe deployment to call

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.21.0
    • changedInput schema / properties / idempotencyKey / description
      Previous value: -"Dedupes retries"New value: +"Dedupes retries; an identical call without a new key returns the first job"
    • addedInput schema / properties / payUnshielded
      Added value: +{
+  "description": "The circuit takes unshielded tokens from this wallet; implied by a $night argument",
+  "type": "boolean"
+}
  2. Addedv0.20.3

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so richly: the caller needs neither NIGHT nor DUST, the sponsor pays, sync waits up to 20s (5 min from genesis), one pay-in runs at a time, failed calls refund coins, and it returns {status, txHash, transactionHash, result}. It also discloses the allowUnshieldedOffers grant requirement and the deduplication behavior on retry.

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?

The opening sentence is well front-loaded, but the body is a dense run-on of stacked parentheticals covering coin tagging, sync timing, sponsor channels, witnesses, and refunds. Most content is relevant, yet it is hard to parse and would benefit from structure or trimming.

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 mutation with no annotations and no output schema, it covers the return shape, blocking/settle timing (~1 minute), failure handling, retry/dedup, and funding/grant prerequisites. An agent has enough to call it correctly and interpret the outcome.

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?

Although schema coverage is 100%, the description adds substantial meaning: it documents the tagged value formats ($bytes/$uint/$coin/$night), explains that payUnshielded is implied by a $night argument, and details idempotencyKey dedup semantics. This goes well beyond the schema's field descriptions.

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 specific verb and resource ('call a circuit on any contract') with a clear precondition (the lineage package installed next to the server) and summarizes the full build/prove/sign/sponsor pipeline. This distinguishes it from siblings like build_sponsorable_transaction or submit_vault_call, which are partial steps rather than the end-to-end call.

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?

Explains the operational context clearly: it routes the agent to get_swap_wallet for the funding wallet, states retry semantics ('run it again with the same arguments'), and clarifies when a new idempotencyKey is needed. It does not explicitly name a sibling alternative or say when-not to use it, so it stops short of a 5.

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