Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sponsor_unbound_transaction

Sponsors an unbound, proven and signed caller transaction by locking one dust backing, binding and submitting it, letting one sponsor wallet sponsor multiple transactions in parallel.

Instructions

Cross-server fee sponsoring, PARALLEL channel (NIGHTGATE 0.18.0): submit an UNBOUND (pre-binding) proven+signed caller transaction, built with the @odatano/nightgate-tx txbuilder's buildSponsorable({ bind: false }) (the caller's key never left its machine). The sponsor locks one free dust backing, merges its dust spend, binds and submits; only the dust build takes the per-wallet lock, so ONE sponsor wallet sponsors N transactions at once (N = its registered dust backings; live: several in the same block). Same allow-list policy and grant surface as sponsor_finalized_transaction; do not mix both channels on one sponsor wallet. Contract state is account-style: two sponsored calls against the SAME contract in one block conflict, the loser lands on-chain but its call does not apply and the job ends failed with errorCode CHAIN_EXECUTION_FAILED (the transaction hash is in the error); then REBUILD the transaction against the current contract state and sponsor again (never resubmit the same bytes). 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
fileNoPath of a file holding the transaction, as base64 text or raw bytes (outFile of a build tool, or written by the txbuilder)
txIdNotxId returned by build_sponsorable_transaction on this server; the bytes never pass through the conversation
unboundTxB64NoBase64 of the caller-built, proven and signed UNBOUND transaction, only when neither txId nor file is available: long base64 copied through a model loses characters
idempotencyKeyNoDedupes retries of the SAME bytes; a rebuilt transaction is a new key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.3

TDQS

A4.6/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: it discloses the per-wallet lock scope, the one-minute wait-until-settled semantics, the exact return shape, and the failed-job path including the CHAIN_EXECUTION_FAILED errorCode and recovery procedure. The conflict/loser-lands-on-chain behavior for account-style contract state is exactly the kind of hidden trait annotations would never have conveyed.

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?

Purpose and channel identity are front-loaded in the first clause, and the trigger/conflict/retry information follows in a defensible order. It is dense and crammed with run-ons and version jargon (NIGHTGATE 0.18.0, "N = its registered dust backings"), which slightly hurts scannability, but no sentence is pure 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?

For a complex asynchronous mutation with no annotations and no output schema, the description supplies everything an agent needs: the return object fields, the settle-wait expectation, the two distinct failure modes (conflict vs. cutoff/pending) and their remedies. Nothing material about calling it correctly is left to inference.

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 explains file/txId/unboundTxB64 precedence and idempotencyKey dedup semantics, establishing a baseline of 3. The description reinforces idempotency behavior but adds no selection guidance between the three input routes beyond what the schema states.

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 verb+resource (submit an unbound proven+signed transaction for cross-server fee sponsoring) and pins down the exact build mode (buildSponsorable({ bind: false })). It explicitly names the sibling sponsor_finalized_transaction and explains the distinction (parallel vs. serialized channel), so an agent can pick between them 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?

Gives explicit when-to-use (transaction built with bind:false), an explicit when-not ("do not mix both channels on one sponsor wallet"), and names the alternative channel. It also covers operational edge cases: retry with identical args is deduplicated, a genuine second call needs a new idempotencyKey, and a conflicting call must be rebuilt rather than resubmitted.

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