Skip to main content
Glama
Sign In
Agentic AQUA

Agentic AQUA

Official
by AquaWallet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sideswap_execute_swap

Execute a SideSwap Liquid atomic swap in either direction, verifying the PSET against the agreed quote before signing to prevent hostile-server balance changes.

Instructions

Execute a Liquid atomic swap on SideSwap. Both directions are supported via send_bitcoins: True = L-BTC → asset (default), False = asset → L-BTC. The PSET returned by SideSwap is verified locally against the agreed quote BEFORE signing — the swap is aborted if the wallet's net balance change does not exactly match (refusing to sign protects against a hostile server). The fee tolerance is pinned to L-BTC, so on the asset → L-BTC direction the asset side is checked at strict equality. Order is persisted at every step for crash recovery. ALWAYS call sideswap_quote first and confirm the price with the user before invoking this tool.

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": {
      "asset_id": "<asset_id>",
      "send_amount": "<send_amount>"
    },
    "name": "sideswap_execute_swap"
  }
}

Input Schema

NameRequiredDescriptionDefault
asset_idYesNon-L-BTC Liquid asset (e.g. USDt). The L-BTC side is always the policy asset.
passwordNoPassword to decrypt mnemonic (if encrypted at rest)
send_amountYesSend amount in sats (L-BTC if send_bitcoins, else asset)
wallet_nameNoLiquid wallet to sign withdefault
password_fileNoPath to a local file containing the wallet password; keeps the password out of the conversation. Do not combine with password.
send_bitcoinsNoTrue = send L-BTC to receive asset; False = send asset to receive L-BTC
min_recv_amountNoOptional floor on the dealer's recv_amount in sats. Pass the recv_amount the user just confirmed in sideswap_quote — if the rate moved between preview and execution and the dealer offers less, the swap is rejected before signing.
flexible_small_amountNoWhen True, accept dealer-rounded send_amount up to ±3000 sats from what was requested. SideSwap's mkt::* dealer rounds internally; small swaps (e.g. 5k–25k sats) often come back at a slightly different amount. Off by default — strict equality is safer at scale.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it discloses that the returned PSET is verified locally against the quote, that the swap aborts on any net balance mismatch, that fee tolerance is pinned to L-BTC causing strict equality on the asset side, and that order state is persisted at every step for crash recovery. These are non-obvious safety and mutation behaviors an agent could not infer from the schema.

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 core action and direction semantics, then safety behavior, ending on the hard prerequisite. Dense but every sentence carries information; the only mild cost is a long middle sentence about fee tolerance that takes a second read.

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 an 8-parameter unannotated mutation tool with no output schema, the description covers safety, abort conditions, durability, and preconditions thoroughly. It omits what the call returns and that sideswap_swap_status is the follow-up for tracking, which is a real but minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds meaning by restating the send_bitcoins direction mapping with its default and by explaining the asymmetry in fee tolerance checking depending on direction. It still defers most per-parameter details (min_recv_amount, flexible_small_amount, password_file) to the schema.

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 ('Execute a Liquid atomic swap on SideSwap') and immediately clarifies the two supported directions. This distinguishes it cleanly from siblings like sideswap_quote (pricing) and sideswap_swap_status (order polling).

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?

Explicitly imposes a prerequisite workflow: 'ALWAYS call sideswap_quote first and confirm the price with the user before invoking this tool.' That is concrete routing guidance to a named sibling. It stops short of stating when-not to use the tool or naming failure alternatives, so it is strong but not exhaustive.

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

Deploy Server

Other Tools