Skip to main content
Glama

Quote a swap

quote_swap
Read-only

Ask what a swap would give, in either direction: pass amount_from to learn what the user receives, or amount_to to learn what the user must send. Returns the rate, the pair minimum and maximum, who would execute the order, and the warnings to relay. With rate_type "fixed" it also returns the rate_id that create_swap needs; that lock lasts about two minutes, so quote again right before creating the order. A fixed rate is not offered on every pair and the tool says so rather than quietly falling back to a float rate. Nothing is created and no funds move.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesAsset the user receives, canonical id, for example "usdt.trx".
fromYesAsset the user sends, canonical id, for example "btc.btc".
amount_toNoAmount the user wants to receive, as a decimal string. The answer then says how much to send.
rate_typeNofloat: the rate is settled when the deposit arrives. fixed: the rate is held until valid_until, about two minutes, and returns the rate_id create_swap needs, usually at a slightly worse rate. Ask for fixed whenever the user wants a guaranteed number; if this pair cannot hold one the answer says so instead of quietly returning a float rate.float
promo_codeNoPromo code to apply, if the user has one.
amount_fromNoAmount the user sends, as a decimal string. Pass this or amount_to, never both.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYes
fromYes
rateYes
rate_idYes
to_nameYes
providerYes
quote_idYes
warningsYes
amount_toYes
from_nameYes
limits_inYes
rate_typeYes
max_amountYes
min_amountYes
amount_fromYes
valid_untilYes
high_network_feeYes
speed_forecast_minutesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / include_providers
      Removed value: -{
      -  "default": false,
      -  "description": "Add the raw per-provider breakdown. Off by default because the summary answers the user.",
      -  "type": "boolean"
      -}
    • changedInput schema / properties / rate_type / description
      Previous value: -"float: the rate is settled when the deposit arrives. fixed: the rate is guaranteed for about ten minutes and returns a rate_id that create_swap needs, usually at a slightly worse rate. Ask for fixed whenever the user wants a guaranteed number; if this pair cannot hold one the answer says so instead of quietly returning a float rate."New value: +"float: the rate is settled when the deposit arrives. fixed: the rate is held until valid_until, about two minutes, and returns the rate_id create_swap needs, usually at a slightly worse rate. Ask for fixed whenever the user wants a guaranteed number; if this pair cannot hold one the answer says so instead of quietly returning a float rate."
    • removedOutput schema / properties / providers
      Removed value: -{
      -  "items": {},
      -  "type": "array"
      -}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds concrete behavioral traits: no funds move, fixed-rate locks expire after about two minutes, and the tool reports when a fixed rate is unavailable instead of falling back. This gives an agent a clear safety and timing model.

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

Conciseness5/5

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

Four dense sentences front-load the main behavior, then cover return value, rate selection, and safety, with no filler or repetition of schema details.

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?

Together with the rich schema and annotations, the description covers behavior, directionality, fixed-rate nuances, timing, output contents, and safety. Nothing needed for correct invocation appears missing.

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 schema carries the definitions; the description adds the complementary 'either direction' semantics and the dependency between rate_type fixed and the rate_id needed by create_swap. This extra layer justifies above baseline.

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?

The description opens with a specific verb and resource: asking what a swap would give, in either direction. It distinguishes quote_swap from creation by stating it returns the rate_id create_swap needs and that nothing is created.

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?

It gives explicit usage conditions: pass amount_from or amount_to depending on the desired direction, ask for fixed whenever the user wants a guaranteed number, and quote again right before creating the order because the lock lasts about two minutes. It also explains that unsupported fixed rates are reported rather than silently falling back.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources