Skip to main content
Glama

Get Swap Quote

get_quote
Read-onlyIdempotent

Fetch a token swap price quote without a wallet or session to check expected output, exchange rate, and route before swapping on Base, HyperEVM, or Monad.

Instructions

Get a price quote for a token swap without authentication. Shows expected output amount, exchange rate, and route info. No wallet or session required — use this to check prices before committing to a swap. Supported chains: Base, HyperEVM, Monad. Returns both a readable summary and a quote object carrying the route's hops, the exact output, the slippage floor and a derived price impact — computed from the tokens' spot prices, not reported by the router, so treat it as an estimate. In a host that renders UI, prefer open_fibx, which shows the route and lets the user swap from it.

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": {
      "amount": "<amount>",
      "from_token": "<from_token>",
      "to_token": "<to_token>"
    },
    "name": "get_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNoTarget blockchain networkbase
amountYesAmount to quote (e.g. '0.1', '100')
slippageNoSlippage tolerance percentage (0.01-50, default: 0.5)
to_tokenYesDestination token symbol
from_tokenYesSource token symbol (e.g. 'ETH', 'USDC', 'MON')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.10.2
    • changedInput schema / properties / chain / enum
      Previous value: -[
      -  "base",
      -  "citrea",
      -  "hyperevm",
      -  "monad"
      -]New value: +[
      +  "base",
      +  "hyperevm",
      +  "monad"
      +]
    • changedInput schema / properties / slippage / description
      Previous value: -"Slippage tolerance percentage (default: 0.5)"New value: +"Slippage tolerance percentage (0.01-50, default: 0.5)"
    • addedInput schema / properties / slippage / maximum
      Added value: +50
    • addedInput schema / properties / slippage / minimum
      Added value: +0.01
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds genuinely non-redundant behavior: no authentication or wallet needed, and the important caveat that price impact is derived from spot prices rather than reported by the router and should be treated as an estimate. A 4 would fit better than 3 here given that router-vs-derived disclosure, but it stops short of describing rate limits or failure modes.

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?

Front-loaded with the core purpose and the key no-auth constraint before drilling into return shape and the open_fibx alternative. Every sentence carries information, though the return-shape sentence is dense enough that the definition runs slightly long for a read-only quote tool.

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, so the description carries the burden of explaining returns, and it does so precisely: readable summary plus a quote object with hops, exact output, slippage floor and derived price impact, plus the accuracy caveat. Combined with the chain list and the open_fibx routing hint, an agent has everything needed to call it correctly.

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 coverage is 100%, so amount, slippage, chain and both tokens are already documented in the schema, and the description's chain list merely restates the enum. It adds no syntax or format detail for parameters beyond what structured data provides, so the baseline 3 applies.

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 ('get a price quote for a token swap') and scopes it as a pre-swap price check, which cleanly separates it from the swap_tokens executor and other siblings. Supported chains are enumerated so the agent knows where it applies.

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?

Gives explicit when-to-use guidance ('check prices before committing to a swap') and names a concrete alternative for UI hosts ('prefer open_fibx, which shows the route and lets the user swap from it'). The selection condition between the two tools is stated, not left to inference.

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