Skip to main content
Glama

arcgate

tradeSwap

Turns a stored quote into unsigned transactions for the taker to sign and send. arcgate never signs, broadcasts or holds funds.

  • Cost: 0.01 USDC under $1,000; 0.05 USDC from $1,000 to $10,000; above that 0.05 USDC plus 0.5 bps of the amount over $10,000, capped at 5 USDC, size-tiered by the quote's USD notional (the USDC side for a USDC pair, or a token-to-token quote's USD valuation; a quote with no valuation prices at tier 1), over x402 (402 with PAYMENT-REQUIRED, retry with PAYMENT-SIGNATURE). Charged once per quote: POST /trade/v1/swap/tx, the Permit2 second round below, is free.

  • Key inputs: quoteId (from POST /trade/v1/quote), taker; optional recipient (defaults to taker), deadlineSec, approval. Never permit - that belongs to POST /trade/v1/swap/tx; sending one here is 400 invalid_request (the strict schema rejects the unknown key).

  • Every quote executes through ArcgateRouter: it is always the Permit2 spender and the ERC-20 approve spender below. When every source pool of the route being executed trades native USDC, the swap is funded by value instead - no approval transaction and no signature at all.

  • Permit2 (default, one or two calls):

    • Returns transactions - an unlimited ERC-20 approve(Permit2, type(uint256).max) first, if the token's ERC-20 allowance to Permit2 is below the amount, then the swap, which carries an empty Permit2 signature and is only directly sendable as-is when a Permit2 allowance to ArcgateRouter already covers the amount, in which case signatures is empty too. Otherwise it also returns signatures: [{ kind: "permit2", typedData }]; sign typedData with the taker's key (EIP-712, e.g. viem's signTypedData).

    • Sign, then call POST /trade/v1/swap/tx with the same quoteId, taker and recipient, and permit: { message: typedData.message, signature }, while the quote is live: free, because this call already paid the swap fee. The first call to it that succeeds uses the round up; a failed one doesn't.

    • Send that response's transactions in order.

  • approval: "approve" (one call): returns at most one ERC-20 approve(ArcgateRouter, amountIn) transaction instead of a permit to sign - an exact amount, never Permit2, never a signature - and only when the taker's current allowance is below it.

  • Freshness: the quote lives for the ttlSec the quote call asked for (default/max 120s); after that quoteId is 410 quote_expired. Every call re-quotes and re-simulates at the current block and returns 409 quote_stale when the fresh re-quote fails or falls below the stored minAmountOut, when the pre-flight simulation reverts on slippage, or when the simulated delivery is below minAmountOut. A 409 or 410 carries a free fresh quote in quote, with next: "requote": the original quote request (same amount, tokens, side, slippageBps and venues, default ttlSec) quoted again through the same pipeline, exactly as POST /trade/v1/quote answers it; when the original named a taker, the fresh quote is for this call's taker, the wallet swapping now. Nothing executes on it: check its price, safety.verdict and readiness, then swap its quoteId. When the fresh quote can't be traded (no_route, insufficient_liquidity, unsupported_venue or buy_reverts, a cannot_sell or illiquid verdict, not executable, or the taker isn't ready) the answer is next: "stop" with no quote, and error.hint says why. One fresh quote per paid quote: a second 409/410 for the same quoteId, a quote that itself came from a 409/410, or a quote expired over 5 minutes ago gets plain requote with no quote, as does one whose re-quote couldn't run or failed on the server's side; then quote again yourself.

  • Fallback: A stored route on a disabled/undeployed venue falls back to the best executable candidate the quote already priced (warning route_not_executable), or 422 not_executable when no such candidate exists, none re-quotes, or no ArcgateRouter is configured at all.

  • Attempts: a quote gets at most 5 failed calls here; the next call on that quoteId is 429 swap_attempts_exhausted (next: "requote"), answered without running the swap pipeline. A failed call is a 409, a 410 (its fresh quote may run), a 422, 500 or 503, or a successful pipeline whose payment settlement or delivery fails. An attempt stays reserved until its 200 is delivered (after settlement when paid); that delivery, a 404, or a 400 (at parse, or a reserved taker/recipient) uses none. A delivered 200 does not reset this quote's previous failures. POST /trade/v1/swap/tx counts its own, per permit round.

  • Next: a 200 with signatures non-empty needs POST /trade/v1/swap/tx before sending anything (next: "sign_permit"); otherwise sign and send transactions in order, then confirm the fill with POST /trade/v1/receipt (free). Costs 0.01 USDC under $1,000; 0.05 USDC from $1,000 to $10,000; above that 0.05 USDC plus 0.5 bps of the amount over $10,000, capped at 5 USDC; the exact amount for your quoteId comes back in the payment-required result. Payment goes in params._meta["x402/payment"]; use an x402-aware MCP client (see https://docs.arcgate.dev/#arcgate/description/mcp-for-agents).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
takerYes
quoteIdYes
approvalNopermit2
recipientNo
deadlineSecNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the entire behavioral burden and does so thoroughly: fee tiers and x402 payment handshake, quote TTL/default/max, 409/410/422/429/400/404 error semantics, attempt reservation rules, and the fact that 200 responses require downstream signing/sending. This is well beyond what structured fields supply.

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

Conciseness3/5

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

The opening sentence is front-loaded and bold section headers aid scanning, but the fee block is duplicated almost verbatim in the opening and the closing 'Next:' paragraph, and the Permit2 bullet is a dense wall of text. For a tool this complex some length is warranted, yet the redundancy costs it.

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?

With no annotations and no output schema, the description is the sole source of truth and covers return shape (`transactions`, `signatures`), next-step guidance (`sign_permit`, `requote`, `stop`), and failure modes. Nothing an agent needs to call this correctly appears to be 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 description coverage is 0%, so the description must compensate, and it does for most inputs: `quoteId` origin (POST /trade/v1/quote), `recipient` defaulting to `taker`, and the `approval` enum's two modes are each explained with concrete behavior. `deadlineSec` is listed as optional but its meaning and the schema's 10-600 bounds are never elaborated, leaving one gap.

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 first sentence states a specific verb and resource ('Turns a stored quote into unsigned transactions for the taker to sign and send') and immediately distinguishes the tool's role from siblings by noting arcgate never signs, broadcasts or holds funds. An agent can tell this apart from tradeQuote and tradeSwapTx without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to POST /trade/v1/swap/tx when a permit must be signed, explains the `approval: "approve"` alternative path, and describes fallback, retry and requote conditions in detail. When-not-use cases (never send `permit` here) and the 5-attempt limit are also stated, leaving little to inference.

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