guide · 11 min read · 2026-06-14

How AI agents swap crypto across chains: a guide to the Ropil MCP server

AI agents can now do more than talk. Through the Model Context Protocol (MCP), an assistant like Claude or ChatGPT can call real tools — query a live API, read structured data, and act on it. Ropil exposes its cross-chain swap engine as a set of MCP tools, so an agent can find the best route to move crypto across chains and prepare the transaction for you. The boundary that makes this safe is simple and absolute: the agent quotes and prepares, but it never holds your keys. A human or a wallet signs. This guide covers what MCP is, the six tools the Ropil server exposes, how to connect an agent, and a worked example of an agent finding the best BTC → ETH route without ever touching custody.

What MCP is, briefly

The Model Context Protocol is an open standard for connecting AI models to external tools and data. Instead of an assistant guessing at facts from its training data, an MCP server advertises a list of callable tools — each with a name, a description, and a typed input schema. The model picks a tool, fills in the arguments, and the server runs real code and returns a real result. It is the difference between an assistant that describes an API and one that can actually use it.

That distinction matters more in crypto than almost anywhere else. Ask a raw language model "what's the best route to swap 0.1 BTC to ETH right now?" and it will happily invent a price, a fee, and a slippage number — none of them real, all of them confidently wrong. Quotes age in seconds and depend on live pool depth, bridge liquidity, and solver inventory that no model can know from memory. An MCP tool closes that gap: the agent doesn't hallucinate a price, it calls for one. The number it shows you came from the same engines that quote the Ropil web app a moment earlier.

The six Ropil MCP tools

The ropil-mcp-serverexposes six tools. Each one fans out across the three swap engines Ropil aggregates — LiFi (bridge + DEX aggregator), Relay (intent / solver network), and THORChain (native L1 liquidity pools) — and returns a single normalized shape. Crucially, none of them execute a swap; execution happens in your wallet, against each engine's audited contracts.

• ropil_list_chains — enumerates every chain Ropil can route to or from, each tagged with per-engine support flags (supportedByLifi, Relay, Thorchain). The agent calls this first to learn what is even possible.
• ropil_list_tokens — returns the per-chain token list (symbol, address, decimals, USD price), backed by the LiFi token registry. Supports search and limit so the agent can find the right USDC on the right chain.
• ropil_get_quote — the workhorse. Fires a parallel quote at every supporting engine and returns up to three quotes (one per engine) plus a best_providertag. This is how the agent gets a single answer to "what's the best route for X?"
• ropil_compare_routes — when you want alternatives, not just the winner. Returns multiple route options per engine, auto-tagged highest-output / fastest / cheapest / simplest, so the agent can explain a trade-off rather than make the choice for you.
• ropil_get_thorchain_deposit — prepares a native-L1 swap on THORChain. Returns the inbound vault address, the exact OP_RETURN memo, and the expected receive amount. This is the tool that makes real-BTC-to-real-ETH possible without a wrapper token — and the user broadcasts the Bitcoin transaction themselves.
• ropil_track_swap — polls swap status by source-chain tx hash and normalizes the answer to pending | completed | failed | refunded | unknown across LiFi, Relay, and THORChain (via Midgard). The agent uses this to answer "did my swap go through?" after you sign.

Connecting an agent

The hosted server speaks the streamable HTTP transport at https://mcp.ropil.xyz/mcp and authenticates with a bearer token. Every request carries an Authorization: Bearer $MCP_AUTH_TOKEN header; the token is compared in constant time on the server, and a missing or wrong token is rejected before any engine is queried. There is also an unauthenticated GET /health endpoint for liveness checks, but every /mcp call is gated.

For local agents the server also runs over stdio — the same code, launched as a subprocess instead of a hosted service. To wire it into Claude Desktop, add an entry to claude_desktop_config.json pointing at the built server:

{
  "mcpServers": {
    "ropil": {
      "command": "node",
      "args": ["/absolute/path/to/ropil-mcp-server/dist/index.js"]
    }
  }
}

Against the hosted HTTP endpoint, the first thing any MCP client does is ask the server what it can do — a tools/list JSON-RPC call:

curl -sX POST https://mcp.ropil.xyz/mcp \
  -H "Authorization: Bearer $MCP_AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

The server replies with the six tools above, each carrying its input schema, and the agent can immediately start calling them with tools/call. Because the server is stateless — each HTTP request gets a fresh instance — there is no session to manage and no affinity to worry about; you can point as many agents at it as you like.

A worked example: agent finds the best BTC → ETH route

Suppose you tell your agent: "I have 0.1 BTC and I want ETH on Ethereum — what's the best non-custodial route, and set it up for me." Here is what happens, step by step, and where the custody line sits.

1. The agent compares routes. It calls ropil_compare_routes with from_chain: "bitcoin", to_chain: "ethereum", from_token: "BTC", to_token: "ETH", and amount: "0.1". LiFi and Relay can't move real Bitcoin from a Bitcoin address, so for this pair the only engine that returns a real route is THORChain, holding native BTC and ETH in its pooled vaults. The agent now knows— from a live tool call, not a guess — that the honest answer is "one route, THORChain, and here is the expected output."

2. The agent prepares the deposit. It calls ropil_get_thorchain_deposit with the same pair and your Ethereum destination_address. The tool returns three things: the THORChain inbound vault address, the exact OP_RETURNmemo that encodes "swap to ETH, send to this address," and the expected receive amount. The agent presents this to you clearly — it does not move anything.

3. You sign and broadcast. The agent cannot send Bitcoin; it has no keys. Youopen your wallet, send 0.1 BTC to the inbound vault address with that memo attached, and broadcast the transaction. Minutes later THORChain's validators release the equivalent ETH to your Ethereum address. This is the non-custodial boundary in its starkest form: every value-moving action was performed by you, with your keys, in your wallet. The agent only read quotes and assembled instructions.

4. The agent confirms. Once you hand it the BTC tx hash, the agent calls ropil_track_swap and watches the status move from pending to completed. It tells you when the ETH has landed — again, by polling a real status endpoint, not by inferring.

Why this is safe (and where it isn't)

The architecture is deliberately narrow. The MCP server reads quotes and prepares deposit instructions. It does not hold keys, cannot sign, and cannot broadcast. It does not move funds — every example above ends with a human signing in their own wallet. That single constraint is what lets you put an agent in the loop at all: the worst a misbehaving or jailbroken agent can do is show you a bad quote, and a bad quote that you decline costs nothing.

The two real risks are worth naming plainly:

• Hallucinated prices. A language model left to its own devices will invent numbers. The defense is the entire point of this design: the agent gets prices from ropil_get_quote and ropil_compare_routes, not from its imagination. If an agent ever quotes you a routewithout citing a tool result, treat the number as fiction.
• Phishing the deposit address. The most dangerous moment in any THORChain swap is the inbound address. Always verify the vault address and memo that ropil_get_thorchain_depositreturns before you sign — cross-check it against THORChain's own published inbound addresses if the amount is large. An agent that prepares the transaction is convenient; it is not a substitute for your eyes on the final destination.

And the standing rule for any cross-chain swap still applies: take a small test swap before a large one, and never move funds you can't afford to wait on. The agent makes the route obvious; the chains still execute on their own clock.

Try it

The MCP server lives at mcp.ropil.xyz — point any MCP-compatible client at https://mcp.ropil.xyz/mcp with a bearer token and start asking it cross-chain swap questions. If you want to see the same engine without an agent, the /compare page runs the identical three-engine comparison in the browser, and the Ropil homepage embeds the live quoting widget.

For the bigger picture on how these three engines differ and when each one wins, read the pillar overview on cross-chain swaps without a CEX. And before you sign anything an agent prepares, read the risk disclosure — the MCP server is informational; the chains and validators are what actually execute, and the keys are always yours.

Questions or feedback? hello@ropil.xyz