Skip to main content
Glama

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 accepting one without gain, the same rule as Invoice; pass quoteId from a prior swap_quote to build exactly that route instead. No API key required: pass the wallet that will sign. A machine credential is optional and only raises your limit from the per-IP cap to the credential budget. Four things to hold onto: 1. steps[] are ORDERED and REQUIRED. Skipping an approve step guarantees a revert. 2. If simulation.status is "approval_required", sign/send only the approve step(s), do not report them as the swap execution, then call swap_build again with quoteId set to the quote.id of that build (the approved route; without it a fresh quote may pick another provider whose spender you never approved). If it is "incomplete", do not sign anything: the transaction was never independently verified. 3. If a step has type "signature", there is no transaction and never will be one for that step — what exists afterward is the uid from report_execution, not a hash. 4. If the provider is cowswap and the token sold is the chain's native asset, the transaction only REGISTERS the order — a successful receipt is not a successful swap. Use swap_status, not the receipt, to know what actually happened. 5. routeSwitch, when present, means the route you asked for refused to build (it hit its request limit) and the plan was built with another provider instead: {from, to, reason}. The quote in the plan is the route that will actually be signed. If the user picked that route themselves, say which provider replaced it before they sign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountNoHuman decimal amount, e.g. "100". Use this OR amountRaw, not both.
walletYesWallet 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").
quoteIdNoOptional: build exactly this route from a prior swap_quote, instead of quoting fresh.
tokenInNoContract 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.
tokenOutNoContract address, or symbol.
amountRawNoRaw integer string in tokenIn's smallest unit.
slippageBpsNoOptional, a sane per-pair default applies when omitted.
maxSlippageBpsNoOptional ceiling, 0-10000, enforced on every future refresh of this build — once set it never loosens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Discloses behavioral traits far beyond the annotations: ordered/required steps, revert risk from skipping an approve, simulation.status handling for approval_required and incomplete, signature-step semantics, cowswap order-registration caveat, and routeSwitch replacement. These are critical execution details the annotations (readOnlyHint, destructiveHint, etc.) do not convey.

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?

The description is long but front-loads purpose and organizes the remaining material into five numbered, scannable behavioral points. Each sentence carries a necessary warning for a complex execution tool, though the overall length sits near the upper bound.

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?

Given the complexity of a multi-step swap execution, rich schema coverage (100%), and no output schema, the description covers the critical edge cases: simulation statuses, ordered steps, cowswap registration, and route switching. An agent has enough information to invoke and sequence the tool 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 description coverage is 100%, and the schema already documents every parameter in detail. The description reinforces quoteId and wallet behavior but adds no new syntax, constraints, or parameter meaning beyond what the structured schema provides. Baseline 3 is appropriate.

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 (build a signable/sendable swap plan) and explicitly distinguishes itself from swap_quote by describing when it quotes fresh versus building a prior route. An agent can tell this is the end-to-end execution builder, not just a quoting tool.

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: omit quoteId to quote-and-build in one call (recommended), pass quoteId from swap_quote to pin a route, and call swap_build again with quoteId after an approval_required result. It also names swap_status as the way to learn what actually happened, covering when not to rely on a receipt.

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