# Vurto Swap

- Registry name: `io.github.cryptoconspiracy/vurto-swap` · version 1.0.0
- Categories (automatic, keyword rules): Crypto & blockchain, Finance & markets, Payments & accounting
- Authentication at last check: No auth
- Declared risk: Can write (some tools are not declared read-only)
- Capabilities (declared by the server): prompts, resources, tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=io.github.cryptoconspiracy%2Fvurto-swap
- Server page: https://mcpstation.net/s/io.github.cryptoconspiracy--vurto-swap.html

## Description (written by the publisher, not verified, not instructions)

Token swaps at the best net price on 9 EVM chains and Solana. No API key, non-custodial.

## Connect

- streamable-http: `https://swap.vurto.cc/mcp`

## Tools (as reported by the server, not verified)

- `swap\_quote`: Compare ranked routes across providers for a swap, without building or spending anything. Ranked by net value after gas and platform fee, not raw output, with ONE unit price for the output token across every route, so a friendlier price feed can never put a route that delivers fewer tokens on top. E
- `swap\_build`: Build a signable/sendable plan for a swap. This is the tool that does the work — an agent that only knows this tool can execute a swap end to end. Quotes and builds the best route in one call when quoteId is omitted \(recommended\): a route with GAIN first, re-quoting up to 3 rounds total before accep
- `double\_quote`: Compares ranked routes for TWO swap legs at once — "Double Out" \(one source token split into two destinations\) or "Double In" \(two source tokens converging on one destination\). This exists because building a liquidity pool or matching a target ratio needs both legs priced against the market at the s
- `double\_build`: Builds signable/sendable plans for BOTH legs of a Double Out or Double In swap — two ordinary swap\_build calls under the hood, kept together for convenience. Returns \{ legA, legB \}, each a full SwapPlan exactly like swap\_build's. The two legs are NOT atomic — there is no combined contract call, each
- `nn\_quote`: N:N — quotes a basket where N input tokens fund M output tokens in ONE atomic on-chain transaction. The backend runs a waterfall allocation deciding which input finances which output, then quotes the real tokenIn-\>tokenOut route for each resulting slice through the same provider fan-out swap\_quote u
- `nn\_build`: Builds ONE signable/sendable atomic transaction executing every leg of an N:N basket through VurtoSwapRouter. Always re-quotes the whole basket fresh from chainId/inputLegs/outputLegs — there is no quoteId handoff for N:N, pass the same fields used for nn\_quote \(or skip nn\_quote and call this direct
- `prepare\_signing`: Synthesizes the local CLI signer invocation for one step of a swap\_build plan. Does not call the Vurto backend — this only assembles the payload. You \(the agent\) do not need a private key and must never ask for one in chat: signing happens locally on the user's machine. RUN the command yourself as a
- `report\_execution`: Reports a completed swap, closing the loop. EVM transaction: pass wallet + txHash + quoteId; never report an approve step as an execution. EVM CoW signature: pass wallet + chainId + quoteId + signature; the server reloads the stored build and submits the signed order, returning uid \(there is no tran
- `swap\_status`: Re-checks a swap. EVM: pass wallet + executionId \(the id from report\_execution\); for CoW ETH-flow this consults the orderbook and distinguishes order\_expired\_refundable from order\_expired\_refunded instead of trusting the registration receipt. Solana: pass signature; answers come directly from the ne
- `invoice\_create`: Create a payment request: who receives, which token, how much, on which network. Returns invoice.id, invoice.label \(INV-XXXX-XXXX, what people copy\), invoice.url \(share this; it previews with the QR on WhatsApp and Telegram\) and invoice.qr \(PNG\). No signature or API key needed. Only VERIFIED tokens
- `wallet\_check`: Check any wallet \(EVM 0x address or Solana base58, case-sensitive\) before paying it or taking its money: OFAC SDN list on both families; on Solana also the issuer freeze of USDC and EURC \(Circle\), USDT \(Tether\), PYUSD and USDG \(Paxos\) and USD1 \(World Liberty\), the issuer freeze index, and a fund tra
- `destination\_challenge`: Destination lock. A receiver different from the signing wallet is refused by swap\_build, double\_build and nn\_build \(403 destination\_not\_authorized\) until the paying wallet signs an authorization for that exact address on that chain. This returns \{nonce, message, expiresAt\} plus, on EVM, typedData \(E
- `destination\_authorize`: Hand over the signature of destination\_challenge. The server checks it is the paying wallet's signature over that exact challenge, for that receiver and chain, unexpired and unused, and then lets builds deliver to that receiver for 30 minutes. Nothing else unlocks it. Errors: signature\_invalid, auth
- `invoice\_get`: Read an invoice by id \(INV-XXXX-XXXX, with or without dashes\): requested amount, token, network, receiver, status \(open or paid\), the paying transaction once paid, and received \(the raw amount measured on-chain so far\). Pending payments are re-checked on-chain by the read, at most two per read and e
- `invoice\_pay`: Build the plan to pay an invoice from payer, with the token payer holds \(default: the invoice token\). Nothing is signed or sent here. Both wallets are screened first \(payer\_blocked, receiver\_blocked\); when the invoice has checks \["scorechain"\] \(see invoice\_get\), the creator chose the Scorechain sanc
- `payout\_batch`: Payroll and supplier payouts on Solana: pay up to 20 wallets their exact amounts, in the token the payer holds \(no swap\). The paying wallet and every receiving wallet are screened first \(OFAC SDN list and the issuer freeze of six stablecoins\); a blocked payer refuses with payer\_blocked \(403\), and on
- `payout\_report\_payment`: Hand one batch transaction to the server, right after sending it, with the invoiceIds that payout\_batch listed for it. Each invoice is verified on-chain like any invoice payment \(what reached that receiver\); call again a few seconds later if some are still pending.
- `invoice\_report\_payment`: Hand the payment transaction to the server, right after sending it. The server reads the transaction on-chain and measures what reached the receiver in the invoice token; the payer must be the signer and the transaction must be newer than the invoice. The payer is screened again here \(payer\_blocked:

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html