Skip to main content
Glama
szhygulin

vaultpilot-mcp

by szhygulin
OverviewSchemaRelated ServersScoreDiscussions(1)
TypeScript
Hybrid

preview_send

Read-onlyIdempotent

Pin nonce, EIP-1559 fees, and gas limit for a prepared EVM transaction; compute and return the Ledger blind-sign hash for user confirmation before calling send_transaction.

Instructions

EVM-only: finalize an already-prepared transaction for signing by pinning the nonce, EIP-1559 fees (maxFeePerGas, maxPriorityFeePerGas), and gas limit server-side, then computing the EIP-1559 pre-sign RLP hash Ledger will display in blind-sign mode. Returns a LEDGER BLIND-SIGN HASH content block the user reads BEFORE you call send_transaction — the Ledger device prompt blocks the MCP tool call, so the hash must be surfaced now, not after. The pinned tuple is stashed against the handle and forwarded verbatim on send_transaction so the on-device hash is deterministic. If gas conditions drift while the user reviews, call preview_send again on the same handle to refresh the pin (overwrites the prior one). send_transaction will throw a clear error if called without a prior preview_send. Not applicable to TRON handles (USB HID signing flow, no WalletConnect). For Solana handles use preview_solana_send — it pins a fresh blockhash instead of nonce + EIP-1559 fees.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleYesOpaque handle returned by a prepare_* tool. preview_send fetches the current nonce + EIP-1559 fees + gas limit, stashes them against the handle, computes the EIP-1559 pre-sign RLP hash Ledger will display in blind-sign mode, and returns the LEDGER BLIND-SIGN HASH block so the user can see and confirm the hash BEFORE the Ledger device prompt appears. A follow-up send_transaction call forwards the pinned fields verbatim. Handles expire 15 minutes after prepare. Once a pin exists, re-calling preview_send on the same handle returns the existing pin unchanged unless `refresh: true` is passed.
refreshNoSet to true to re-pin nonce/fees/gas (e.g. after the user paused for minutes and wants fresh fees). Default is false: the existing pin and its pre-sign hash are returned verbatim, so the hash the user matched in chat cannot silently drift between preview and send.

Tool Definition Quality

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), description details pinning, hash surfacing, Ledger prompt blocking, overwrite behavior on re-call, and deterministic forwarding. No contradiction with annotations.

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?

Single dense paragraph front-loads purpose then efficiently covers usage, exceptions, and sibling alternatives. Every sentence adds value with no redundancy or fluff.

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?

Despite no output schema, description adequately explains that the tool returns a LEDGER BLIND-SIGN HASH content block. Covers all necessary aspects: purpose, chain-specificity, pinning, refresh, error conditions, and relation to send_transaction and preview_solana_send.

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?

Even with 100% schema coverage, description adds substantial context: handle is opaque from prepare_*, fetches nonce/fees/gas, stashes, computes hash; explains 15-min expiration and default behavior of refresh (existing pin returned verbatim to prevent drift).

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 clearly states the tool is EVM-only and finalizes a prepared transaction by pinning nonce, fees, and gas limit, then computing a pre-sign hash for Ledger blind-sign mode. It distinguishes from siblings like preview_solana_send and explicitly excludes TRON and Solana.

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?

Provides explicit when-to-use: EVM-only, not for TRON or Solana; instructions to call before send_transaction, re-call if gas drifts, and that send_transaction errors without prior preview_send. Also names alternative for Solana.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/vaultpilot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server