Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sponsor_finalized_transaction

Submits a finalized, fee-unpaid transaction built and signed elsewhere so the sponsor pays the dust while the builder's identity remains on-chain.

Instructions

Cross-server fee sponsoring, phase 2 (NIGHTGATE 0.17.0): submit a FINALIZED, fee-unpaid transaction that was built, proven and signed elsewhere (e.g. with the @odatano/nightgate-tx txbuilder, so the caller's key never left its machine). The sponsor session pays the dust; the on-chain effect carries the BUILDER's identity, not the sponsor's. The server enforces its contract/circuit allow-list and rejects anything outside it. The transaction expires with its TTL (default 30 min), so hand it over promptly. This is the SERIAL channel (one tx per sponsor wallet at a time); for parallel submission build with bind:false and use sponsor_unbound_transaction. The server picks the wallet that pays. The tool also waits for the block (about a minute more) and then carries the instance's signed receipt; if that wait runs out, receipt is null and the same call again fetches it. 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 (bind:true) on this server; the bytes never pass through the conversation
finalizedTxB64NoBase64 of the caller-finalized, fee-unpaid transaction, only when neither txId nor file is available: long base64 copied through a model loses characters
idempotencyKeyNoDedupes retries; the request is also fingerprinted by the transaction bytes

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 so: sponsor pays dust, on-chain identity is the builder's not the sponsor's, server enforces a contract/circuit allow-list, default 30-minute TTL, server-side wallet selection, and a roughly one-minute block wait whose receipt may be null. It even documents dedup behavior on interrupted or pending calls.

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 are front-loaded and every major topic earns its place, but the waiting behavior is restated twice ('waits for the block (about a minute more)' and 'waits until the job settled (about 1 minute)'), and the return-shape sentence sits mid-paragraph rather than being grouped.

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?

There is no output schema, so the description supplies the return contract itself — { status, txHash, transactionHash, result }, the null-receipt case, and the failed -> `next` field. Combined with the retry, TTL and allow-list notes, an agent has everything needed to invoke and recover.

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 baseline is 3, but the description reinforces the parameter precedence (txId from build_sponsorable_transaction before falling back to file/base64) and adds retry semantics for idempotencyKey ('a second, separate call with the same arguments needs a new idempotencyKey') beyond the schema's terse note.

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 opens with a specific verb and resource: 'submit a FINALIZED, fee-unpaid transaction that was built, proven and signed elsewhere', and immediately names the sibling paths it is not (build_sponsorable_transaction, sponsor_unbound_transaction). An agent can distinguish it from the parallel-channel tool 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?

It states the channel explicitly ('SERIAL channel, one tx per sponsor wallet at a time') and routes parallel use to sponsor_unbound_transaction with bind:false. It also gives retry rules ('run it again with the same arguments: it picks up the job it started'), the new-idempotencyKey condition, and the TTL promptness requirement.

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