SwapChan

LTC/DOGE/BCH deposit address (THORChain)

get_utxo_deposit

Read-only

Send Litecoin, Dogecoin or Bitcoin Cash through THORChain from any wallet that can add an OP_RETURN memo. Returns THORChain's vault, the exact amount, the REQUIRED memo with its byte count, the minimum (minimumDisplay: the larger of the dust threshold and practicalMinimum, which is THORChain's current estimate of its smallest swap and can change; say so, and when practicalMinimum is null only the dust threshold is known), the expiry and warnings. THORChain usually cannot fit a refund address in these memos: when refundInMemo is false (refundTo: sender), a failed swap is refunded to the address that sent the coins, so tell the user plainly to send only from a wallet address they control, never from an exchange. Always: the memo is mandatory, send exactly this amount once before expiry, and show every warning. Nothing is sent by this call. For an unsigned PSBT instead, use get_quote then build with the sender as taker. How to combine this with the other tools: swapchan_playbook (workflows: find-money, best-swap, rebalance, revoke-approvals, bridge-stuck, token-safety, recover-old-wallet).

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": {
      "fromChainId": "<fromChainId>",
      "fromToken": "<fromToken>",
      "toChainId": "<toChainId>",
      "toToken": "<toToken>",
      "amount": "<amount>",
      "recipient": "<recipient>"
    },
    "name": "get_utxo_deposit"
  }
}

Input Schema

Name	Required	Description
`amount`	Yes	Base units (1e8 per coin)
`refund`	No	Optional: the user's own address on the sending chain. Put in the memo only if THORChain fits it (see refundInMemo); otherwise refunds go to the sending address
`toToken`	Yes
`fromToken`	Yes	The chain's native coin address from get_supported_tokens
`recipient`	Yes	Payout address on toChainId
`toChainId`	Yes	Chain id: 1 Ethereum, 8453 Base, 42161 Arbitrum, 10 Optimism, 137 Polygon, 56 BNB Chain, 43114 Avalanche, 59144 Linea, 534352 Scroll, 792703809 Solana, 8253038 Bitcoin, 728126428 Tron, plus THORChain-only 2000000002 Litecoin, 2000000003 Dogecoin, 2000000145 Bitcoin Cash (either side, THORChain only; sending them needs the native coin and returns an unsigned PSBT on /build or a deposit address from POST /utxo/deposit with the required memo). Non-EVM chains route via Relay, LI.FI and THORChain.
`fromChainId`	Yes	2000000002 Litecoin, 2000000003 Dogecoin or 2000000145 Bitcoin Cash
`slippageBps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / refund / description

Previous value: -"The user's own address on the sending chain, for refunds"New value: +"Optional: the user's own address on the sending chain. Put in the memo only if THORChain fits it (see refundInMemo); otherwise refunds go to the sending address"

changedInput schema / required

Previous value: -[
-  "fromChainId",
-  "fromToken",
-  "toChainId",
-  "toToken",
-  "amount",
-  "recipient",
-  "refund"
-]New value: +[
+  "fromChainId",
+  "fromToken",
+  "toChainId",
+  "toToken",
+  "amount",
+  "recipient"
+]

AddedOct 27, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description confirms 'Nothing is sent by this call', then goes well beyond by disclosing the mandatory memo, single-send-before-expiry rule, refund-to-sender semantics when refundInMemo is false, and the mutability of practicalMinimum. That is exactly the extra context annotations cannot convey.

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?

One dense paragraph that front-loads the purpose and return contents before warnings and alternatives. The nested parenthetical explaining minimumDisplay is heavy but each clause carries operative instruction; only the closing playbook pointer feels bolted on.

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?

With no output schema, the description enumerates the returned fields and their meaning, including the tricky minimumDisplay/practicalMinimum distinction. An agent has enough to call the tool and to relay correct instructions to the user.

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 75%, and the description adds genuine meaning for `refund` (only used if THORChain fits it in the memo, otherwise refunds go to the sending address) and for the amount field ('send exactly this amount once'). It does not explain fromToken/toChainId choices, but the schema already does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (a THORChain UTXO deposit address/instructions for LTC/DOGE/BCH) and the exact return contents (vault, amount, memo, minimum, expiry, warnings). The opening 'Send ... through THORChain' is slightly at odds with the later 'Nothing is sent by this call', but the tool's role is still recoverable and it is clearly distinguished from get_quote/build_swap_link.

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?

It gives a real routing rule: use this when the wallet can add an OP_RETURN memo, and 'For an unsigned PSBT instead, use get_quote then build with the sender as taker.' It also points to swapchan_playbook workflows. No explicit when-not-to-use beyond the PSBT branch, so not a 5.

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

All SwapChan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.