Skip to main content
A transaction moves through up to 4 stages, each controlled by a different band. Configure MCP_BANDS to activate only the stages you need.

​
Stages

​
1. Query (read band)

Check balances, prices, and fees before deciding to transact.
ToolWhat It Returns
get_balanceNative token balance for one address on one chain
get_all_balancesAll token balances with fiat valuations
get_priceCurrent market price for a token
get_fee_quoteEstimated network fee for a transfer
resolve_assetToken contract address from a symbol or name
get_tx_statusStatus of a submitted transaction
get_tx_historyRecent transactions for an address
No keys involved. No state modified.

​
2. Prepare (prepare band)

Construct an unsigned transaction payload. The blockchain is not touched — this builds the data structure you or the agent will later sign.
ToolOutputUse Case
prepare_transferUnsigned payload (nonce, fee params, calldata)External BYO signing - you route the payload to your own signer
prepare_serialized_unsigned_txSigning-ready hex + human-readable reviewFeed directly into sign_transaction
prepare_onrampMoonPay widget URLFiat on-ramp to fund a wallet
Token transfers are two-step: First call resolve_asset to get the token contract address, then call the prepare tool with that contract. WalletSuite does not guess token contracts from symbols. Amount handling: Provide either amount (human-readable, e.g., "1.5") or amountWei (smallest units, e.g., "1500000000000000000"). Never both — the server rejects ambiguous input.

​
3. Sign (sign band)

Sign the prepared transaction. Signing runs through MPC 2-of-2 (DKLS23) - both shares required, no full key ever assembled. See Key Management.
ToolWhat It Does
sign_transactionTakes unsigned tx hex, returns the signature
get_wallet_addressResolves the wallet address for a chain
Policy gates are evaluated before any signature is produced. Signing is idempotent - signing the same payload produces the same signature.

​
4. Broadcast (broadcast band)

Submit the signed transaction to the blockchain. Once confirmed it cannot be undone.
ToolWhat It Does
send_transactionSigns and broadcasts in one step, returns tx hash
Requirements:
  • confirmBroadcast: true (explicit confirmation)
  • Broadcast band enabled (MCP_BANDS=full or MCP_BANDS=read,prepare,sign,broadcast)
After broadcast, use get_tx_status to monitor confirmation.

​
MPC Signing Flow

The end-to-end sequence that step 3 follows in a single MCP session: 
1. get_fee_quote                    → estimate the cost
2. prepare_serialized_unsigned_tx   → build signing-ready hex + review
3. (Agent presents review to user, or auto-confirms within policy)
4. sign_transaction                 → MPC co-sign (WalletSuite share + customer share)
   OR
   send_transaction                 → MPC co-sign + broadcast
5. get_tx_status                    → confirm on-chain
No signing infrastructure for your team to operate. The customer-side share is stored with the MCP server runtime, encrypted at rest, off WalletSuite infrastructure. Self-host the MCP server when you need it to run on your own infrastructure - the customer share never leaves it. The full flow stays within the MCP session. No browser extension, no QR code, no external wallet. Example conversation: 
User: "Send 1 ETH to 0xdef"

Agent: Prepares the transfer, shows review:
  "Send 1.0 ETH to 0xdef... Estimated fee: 0.002 ETH ($5.40)"

User: "Confirm"

Agent: Signs and broadcasts via send_transaction
  "Sent 1 ETH to 0xdef. Tx: 0xabc... confirmed in block 19234567."

​
Data Flow Diagram

User intent ("Send 1 ETH to 0xdef")
  |
  v
MCP Server
  |
  |-- [1] prepare_serialized_unsigned_tx
  |         |-- POST /api/txs/prepare-sign (backend)
  |         \-- tx-compiler -> unsigned hex + review
  |
  |-- [2] send_transaction
  |         |-- Signing layer: evaluate policy
  |         |-- MPC co-sign across two shares (no full key assembled)
  |         |-- Broadcast to chain RPC
  |         \-- return tx hash
  |
  \-- [3] get_tx_status
            |-- GET /api/txs/status/{hash} (backend)
            \-- return confirmed / pending / failed