Skip to main content
Glama
Sign In

SwapChan

by io.github.TSavo
OverviewDiscussionsAdmin

Broadcast an already-signed transaction

broadcast_tx

Relay a transaction the user's wallet already signed, unchanged, to 51 chains. SwapChan never signs, never holds keys and cannot alter signed bytes; it only relays. 51 chains. EVM (23): Ethereum, Base, Arbitrum One, OP Mainnet, Polygon PoS, BNB Smart Chain, Avalanche C-Chain, Linea, Scroll, zkSync Era, Gnosis, Mantle, Celo, Blast, Berachain, Sonic, Unichain, Fantom, Monad, Katana, HyperEVM, Ethereum Classic, EthereumPoW; Bitcoin and Bitcoin-family/old coins (18): Bitcoin, Bitcoin Cash, Bitcoin Gold, Litecoin, Dogecoin, Feathercoin, Dash, DigiByte, Ravencoin, Vertcoin, Viacoin, Groestlcoin, Reddcoin, Peercoin, Zcash (transparent), Bitcoin SV, Monacoin, Terracoin; Other ledgers (10): Solana, Tron, XRP Ledger, Stellar, Algorand, Cosmos Hub, Polkadot relay chain, Polkadot Asset Hub, TON, Cardano. Formats: EVM signed raw hex with an EIP-155 chainId matching the chain (pre-EIP-155 txs are refused on the added chains), Solana base64, Tron JSON, Bitcoin-family raw tx hex (not a PSBT), XRP tx_blob hex, Stellar envelope XDR base64, Algorand signed msgpack base64, Cosmos Hub TxRaw base64, Polkadot extrinsic 0x hex, TON BoC base64, Cardano CBOR hex. verify_tx checks run first on the 9 core EVM chains, Solana and Tron (warnings only unless strict=true). verify_tx cannot decode Bitcoin or any of the other chains, so strict=true refuses Bitcoin and every other chain outside that core set. Bitcoin-family transactions are not checked against the network: sign for the correct coin; BCH, BSV and other forks can share pre-split coins, so one transaction may be valid on both. Optional private submission via Flashbots Protect on Ethereum mainnet. Any chain not listed: broadcast from the coin's own wallet. Returns hash + statusUrl/explorer. Result includes display markdown with chan images: show it to the user. 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": {
      "chainId": "<chainId>",
      "tx": "<tx>"
    },
    "name": "broadcast_tx"
  }
}

Input Schema

NameRequiredDescriptionDefault
txYesAlready-signed tx bytes / JSON
strictNoRefuse to broadcast when verify_tx verdict is danger
chainIdYesChain to relay to: an EVM chain id or one of these keys: 1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, solana, bitcoin, tron, 324, 100, 5000, 42220, 81457, 80094, 146, 130, 250, 143, 747474, 999, 61, 10001, bch, btg, ltc, doge, ftc, dash, dgb, rvn, vtc, via, grs, rdd, ppc, zec, bsv, mona, trc, xrp, xlm, algo, atom, dot, dot-assethub, ton, ada (names like eth, base, solana, bitcoin, tron also work).
privateNoEthereum: submit via Flashbots Protect

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / chainId / description
      Previous value: -"Chain id (1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, 792703809 Solana, 8253038 Bitcoin, 728126428 Tron) or name (eth, base, arbitrum, optimism, polygon, bnb, avalanche, linea, scroll, solana, bitcoin, tron)."New value: +"Chain to relay to: an EVM chain id or one of these keys: 1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, solana, bitcoin, tron, 324, 100, 5000, 42220, 81457, 80094, 146, 130, 250, 143, 747474, 999, 61, 10001, bch, btg, ltc, doge, ftc, dash, dgb, rvn, vtc, via, grs, rdd, ppc, zec, bsv, mona, trc, xrp, xlm, algo, atom, dot, dot-assethub, ton, ada (names like eth, base, solana, bitcoin, tron also work)."
  2. Added

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the mutation and non-idempotency profile is structured. The description nonetheless adds real value the annotations cannot: verification runs first on only a core set unless strict, Bitcoin-family txs are not network-checked and fork replay is possible, and Flashbots Protect is Ethereum-mainnet only. That is solid supplemental disclosure, but the description stops short of saying what happens to a rejected relay or how partial failures surface across 51 chains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded well, with the immutable-relay contract stated first and the operational details after. But it is bloated: '51 chains' is asserted twice, and the full 51-chain enumeration largely restates the chainId value list already present in the schema, crowding out more useful content.

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?

No output schema exists, yet the description still names the return payload (hash plus statusUrl/explorer) and instructs the agent to surface the `display` markdown to the user. Combined with format requirements per chain and the verify/private submission behavior, an agent has everything needed to invoke this correctly.

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, and the description earns above that: it specifies the exact serialization format expected in `tx` per chain family (raw hex with matching EIP-155 chainId, Solana base64, Tron JSON, XDR, BoC, CBOR, etc.), which the schema does not. It also explains that `strict` both refuses danger verdicts and refuses chains verify_tx cannot decode, extending the schema's one-line 'danger' definition.

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?

First sentence gives a precise verb+resource ('Relay a transaction the user's wallet already signed, unchanged') plus the critical constraint that SwapChan never signs or holds keys. It is immediately distinguishable from siblings like build_swap_tx (which constructs) and verify_tx (which checks).

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?

Explicitly states when-not: 'Any chain not listed: broadcast from the coin's own wallet,' and carries exclusion rules such as PSBTs being rejected and pre-EIP-155 txs refused on added chains. It also names the interaction with verify_tx and routes to swapchan_playbook for workflows.

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

All SwapChan toolsInspect
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.

Resources