Skip to main content
Glama
Sign In

Vurto Swap

by io.github.cryptoconspiracy
OverviewDiscussionsAdmin

swap_quote

Read-only

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. Each quote also carries estimatedGas, the gas in units behind the same gasUsd, if you would rather rank against a gas price you read yourself. A quote is only usable by swap_build for about 10-12 seconds — do not hold onto a quoteId and build it later, quote again instead.

Input Schema

NameRequiredDescriptionDefault
amountNoHuman decimal amount, e.g. "100". Use this OR amountRaw, not both.
walletNoWallet that will sign. Required for builds and EVM execution/history calls. On an anonymous EVM quote, pass it to make the returned quoteId executable; without it the quote is indicative.
chainIdYesEVM: integer from GET /v1/chains (1, 10, 56, 100, 137, 8453, 42161, 43114, 130). Solana: string from GET /v1/svm/chains ("solana-mainnet").
tokenInYesContract address (Solana: mint), or symbol (case-insensitive). A symbol matching more than one token on this chain fails with ambiguous_token and every candidate — pick the address you meant and retry. On Solana only VERIFIED tokens resolve by symbol, because there anyone can mint a token using another one's symbol; an unverified token has to be named by its mint.
receiverNoOptional: deliver the output to this address instead of the signing wallet. Only providers with supportsReceiver true on the resulting quote honor it — others are left out of quotes[] entirely rather than risk sending to the wrong address. supportsReceiver is present on Solana quotes too, so read it instead of assuming. On Solana, selling into native SOL with a separate destination is refused on every provider (receiver_native_sol_unsupported): closing the wrapped-SOL account sends balance and rent to whoever signs. Ask for wSOL instead. Building with a receiver needs the paying wallet's signed authorization first (destination_challenge, then destination_authorize), or the build fails with destination_not_authorized.
tokenOutYesContract address, or symbol.
amountRawNoRaw integer string in tokenIn's smallest unit.
slippageBpsNoOptional, a sane per-pair default applies when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / receiver / description
      Previous value: -"Optional: deliver the output to this address instead of the signing wallet. Only providers with supportsReceiver true on the resulting quote honor it — others are left out of quotes[] entirely rather than risk sending to the wrong address. supportsReceiver is present on Solana quotes too, so read it instead of assuming. On Solana, selling into native SOL with a separate destination is refused on every provider (receiver_native_sol_unsupported): closing the wrapped-SOL account sends balance and rent to whoever signs. Ask for wSOL instead."New value: +"Optional: deliver the output to this address instead of the signing wallet. Only providers with supportsReceiver true on the resulting quote honor it — others are left out of quotes[] entirely rather than risk sending to the wrong address. supportsReceiver is present on Solana quotes too, so read it instead of assuming. On Solana, selling into native SOL with a separate destination is refused on every provider (receiver_native_sol_unsupported): closing the wrapped-SOL account sends balance and rent to whoever signs. Ask for wSOL instead. Building with a receiver needs the paying wallet's signed authorization first (destination_challenge, then destination_authorize), or the build fails with destination_not_authorized."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations: discloses the ~10-12 second quote TTL and the non-persistable quoteId, the ranking basis (net value after gas and platform fee, single unit price for the output token), the estimatedGas/gasUsd pairing for self-sourced gas prices, and provider filtering when a receiver is set. The idempotentHint=false annotation is corroborated by the ephemeral-quote behavior.

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?

Purpose and the 'no build, no spend' guarantee are front-loaded, and the operational caveat (quote expiry) closes the entry. It is dense and mostly earns its length, though the ranking rationale sentence is wordier than needed.

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?

With no output schema and eight parameters, the description covers what matters: return concepts (quotes[], quoteId, estimatedGas, gasUsd, supportsReceiver), key error paths (ambiguous_token, receiver_native_sol_unsupported, destination_not_authorized), and cross-tool linkage to destination_challenge/authorize. It stops short of describing the full quote payload shape, but nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including the subtle wallet/receiver semantics is already documented structurally. The description restates the wallet executability rule and receiver provider-filtering rather than adding syntax or constraints the schema lacks, so it lands at the baseline 3.

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 ('Compare ranked routes across providers for a swap') plus an explicit negative scope ('without building or spending anything'), which cleanly separates it from swap_build. An agent can pick this over its siblings without reading either schema.

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?

Clear when-to-use context (pre-build comparison) and a routing hint to swap_build as the consumer of a quoteId, including the advice to re-quote rather than hold a stale id. It does not, however, differentiate itself from other quote siblings such as double_quote or nn_quote, so the alternative-selection guidance is incomplete.

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

All Vurto Swap 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