Skip to main content
Glama

dex_tx_transfer_preview

Destructive

Build a transfer summary (sender, recipient, amount, gas). Does not broadcast. Solana native: returns key_info only — after the user confirms, call dex_tx_get_sol_unsigned and sign that result immediately. Do not sign a Solana transaction built before confirmation. EVM: returns unsigned_tx_hex and txBundle. → swap_quote/swap_prepare for token exchange.

Input Schema

NameRequiredDescriptionDefault
toYesRecipient address
fromYesSender (your wallet) address
chainNoChain name or alias (default ETH). Resolved to canonical name from chain config; downstream sign/broadcast should use the same logical chain.
nonceNoTransaction nonce. Omit to use current chain nonce (eth_getTransactionCount), ensuring tx can be mined and found on explorer; wrong nonce causes tx to fail or not appear.
tokenNoToken symbol for display (default USDT). Use ETH/NATIVE for native; USDT for USDT; or use token_contract/token_mint for any token.
amountYesAmount in token units. Precision depends on token/decimals. Examples: '1', '0.5', '0.000001'
mcp_tokenNoMCP session token obtained from login (dex_auth_google_login_poll or dex_auth_gate_login_poll). MUST be provided in every call to this tool after login; omitting it will result in 403
token_mintNoSolana: SPL token mint address for SPL transfer. When set, token_decimals is required. EVM: unused.
token_contractNoEVM: ERC20 contract address for arbitrary token. When set, token_decimals is used (default 18). Solana: unused.
token_decimalsNoToken decimals (e.g. 6, 18). Required when using token_contract (EVM) or token_mint (Solana); default 18 for ERC20, 9 for SOL.
max_fee_per_gasNoEVM only: override max fee per gas (wei). Use when replacing a pending tx: set ≥1.1× the previous max_fee_per_gas to fix replacement transaction underpriced.
max_priority_fee_per_gasNoEVM only: override max priority fee per gas (wei). When replacing, set ≥1.1× previous max_priority_fee_per_gas.
priority_fee_micro_lamportsNoSolana only: optional priority fee (micro-lamports per compute unit). Use 1000-10000 if broadcast returns replacement transaction underpriced.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations carry the safety profile (destructiveHint, openWorldHint), and the description usefully adds that nothing is broadcast plus chain-specific return shapes (Solana key_info only vs EVM unsigned_tx_hex/txBundle). It also discloses an important timing constraint about signing. It does not fully reconcile the destructive annotation with the non-broadcast preview semantics, but the added behavioral context is substantial.

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?

Dense but front-loaded: the core action and non-broadcast scope come first, followed by chain-specific branches and an alternative route. Every clause carries information, though the arrow shorthand and multiple nested conditionals make it slightly hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter transaction-preparation tool with no output schema, the description helpfully explains the chain-dependent return shapes and the required follow-up signing step. Auth requirements and per-parameter detail are delegated to the schema's strong coverage, leaving little an agent needs that is missing.

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 documents all 13 parameters including chain, nonce, token, and fee overrides in detail. The description mentions fields only in passing and adds no format or value semantics beyond what the schema provides, matching the baseline for full coverage.

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 ('Build a transfer summary') and enumerates the covered fields (sender, recipient, amount, gas). It immediately distinguishes itself from siblings by routing token exchange to swap_quote/swap_prepare, so an agent can tell it apart without opening another 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?

Explicit 'Does not broadcast' scope, a when-to-use flow (after user confirms, call dex_tx_get_sol_unsigned and sign immediately), an explicit prohibition ('Do not sign a Solana transaction built before confirmation'), and a named alternative for token swaps. When/when-not/alternatives are all present.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.