Agentic AQUA

Official

Overview Schema Source Related Servers Discussions Admin

sideshift_send

Send funds through SideShift by fetching a fixed-rate quote, creating the shift, and broadcasting the deposit from your local Bitcoin or Liquid wallet for allowlisted pairs.

Instructions

Send funds out via SideShift. Gets a fixed-rate quote, creates the shift, and broadcasts the deposit from the local wallet. Deposit chain MUST be 'bitcoin' or 'liquid'. Both legs must be in the curated allowlist (USDt on ethereum/tron/bsc/solana/polygon/liquid, or BTC on bitcoin) — mirrors AQUA Flutter's supported pairs. Set SIDESHIFT_ALLOW_ALL_NETWORKS=1 to bypass. A refund address is set automatically (the wallet's own deposit-chain address). For non-L-BTC Liquid assets (e.g. USDt-Liquid), the Liquid asset_id is auto-resolved from deposit_coin against the known asset registry — no need to look it up first. Pass liquid_asset_id only to override the registry. ALWAYS call sideshift_quote first and confirm the price with the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "deposit_coin": "<deposit_coin>",
      "deposit_network": "<deposit_network>",
      "settle_coin": "<settle_coin>",
      "settle_network": "<settle_network>",
      "settle_address": "<settle_address>"
    },
    "name": "sideshift_send"
  }
}

Input Schema

Name	Required	Description	Default
`password`	No	Password to decrypt mnemonic (if encrypted)
`quote_id`	No	Optional fixed-rate quote id from a prior sideshift_quote call. Pass this after the user confirms the preview so the shift executes at the same rate they saw — without it, the tool fetches a fresh quote and the rate may have moved.
`refund_memo`	No
`settle_coin`	Yes
`settle_memo`	No	Required for memo networks (BNB, etc.)
`wallet_name`	No		default
`deposit_coin`	Yes	L-BTC: 'btc' (network='liquid'); BTC: 'btc'; USDt-Liquid: 'usdt'
`password_file`	No	Path to a local file containing the wallet password; keeps the password out of the conversation. Do not combine with password.
`settle_amount`	No
`deposit_amount`	No
`settle_address`	Yes	Where SideShift sends the converted asset
`settle_network`	Yes
`deposit_network`	Yes	Chain we sign on
`liquid_asset_id`	No	Optional hex asset id. When omitted and depositing a non-L-BTC Liquid asset, it's auto-resolved from `deposit_coin` against the known Liquid asset registry (USDt, DePix, JPYS, EURx, MEX). Pass explicitly only to override the registry.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden and does well: it discloses the quote-create-broadcast pipeline, that a refund address is auto-set to the wallet's own deposit-chain address, that Liquid asset ids are auto-resolved from deposit_coin, and that SIDESHIFT_ALLOW_ALL_NETWORKS=1 bypasses the allowlist. It stops short of stating irreversibility, fee handling, or what the call returns.

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?

Front-loaded with the action and the hard constraints, and the critical 'call sideshift_quote first' warning sits at the end where it will be read. It is dense with parentheticals and em-dash asides, but each clause carries operational information rather than filler.

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

Completeness3/5

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

For a 14-parameter fund-moving tool with no annotations and no output schema, the description covers the safety-critical behavior well. What is missing is how amounts are specified (settle_amount vs deposit_amount, which is required for which direction) and any hint of the return value such as shift id or deposit txid.

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 coverage is 57%, and the description adds real value on some fields (deposit_network restriction to bitcoin/liquid, liquid_asset_id override semantics, auto-resolution of the asset registry). However, several parameters remain unexplained in both places — notably settle_amount versus deposit_amount, wallet_name, and refund_memo — so it only partially compensates for the coverage gap.

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 ('Send funds out via SideShift') plus the three-step mechanics (quote, create shift, broadcast deposit). This clearly distinguishes it from sideshift_quote, sideshift_receive, and sideshift_status, which are named siblings with adjacent roles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong preconditions: deposit chain MUST be 'bitcoin' or 'liquid', both legs must be in a curated allowlist, and 'ALWAYS call sideshift_quote first and confirm the price with the user'. The only gap is that it never explicitly states when to prefer sideshift_receive or a competing exchange sibling such as changelly_send.

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

Deploy Server