Skip to main content
Glama
szhygulin

recon-crypto-mcp

by szhygulin
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

preview_send

Read-onlyIdempotent

Pin nonce, EIP-1559 fees, and gas limit to compute a deterministic pre-sign RLP hash for Ledger blind-sign. Returns the hash block for user confirmation before sending the 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?

Annotations provide readOnlyHint, idempotentHint, openWorldHint. Description adds behavior: server-side pinning, hash computation, block return, handle expiration (15 min), re-call behavior (with/without refresh), deterministic forwarding to send_transaction. Rich context beyond 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?

Five sentences, each adding critical info: purpose, why surface now, stashing mechanism, refresh behavior, exclusions and error. No fluff, front-loaded with key constraint 'EVM-only'.

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?

Given no output schema but 2 parameters, description thoroughly covers all behavioral aspects, lifecycle, error conditions, and alternatives. No missing information for an AI agent.

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 covers both parameters (handle, refresh) with descriptions, but description adds significant meaning: handle's lifecycle (from prepare_*, link to send_transaction, expiration, refresh behavior), refresh semantics (re-pin vs return existing). No gaps.

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?

Description clearly states 'EVM-only: finalize an already-prepared transaction for signing by pinning the nonce, EIP-1559 fees... and computing the EIP-1559 pre-sign RLP hash'. It uses specific verbs and resources, and distinguishes from siblings like preview_solana_send and send_transaction.

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 states when to use: before send_transaction, and why (Ledger blocks tool call). Provides exclusions: not for TRON or Solana, and directs to preview_solana_send for Solana. Covers edge cases like re-calling to refresh and error if no prior call.

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/recon-crypto-mcp'

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