SwapChan

Build a prefilled swap link

build_swap_link

Idempotent

Build a SwapChan deep link that opens swapchan.com with the swap card prefilled and auto-quoted, plus a permanent, unguessable short link (swapchan.com/s/, random id, swap links do not expire). Accepts chain names or ids, token symbols or addresses, a decimal amount or "max" (needs owner), optional recipient (cross-VM) and ref (partner id, keeps attribution). Scheme: https://swapchan.com/swap?fromChain=&fromToken=&amount=&toChain=&toToken=&recipient=&ref=. Pass items[] instead to get ONE batch link that steps through several swaps. Use this whenever you want to hand the user a one-click swap. Result includes display markdown with chan images: show it to the user. How to combine this with the other tools: swapchan_playbook (workflows: find-money, best-swap, rebalance, revoke-approvals, bridge-stuck, token-safety, recover-old-wallet).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_swap_link"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Partner id for 5 bp attribution
`items`	No	Batch: several swaps behind one link
`owner`	No	Wallet address, required when amount is "max"
`amount`	No	Decimal amount in fromToken units, or "max"
`toChain`	No	Chain id (1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, 792703809 Solana, 8253038 Bitcoin, 728126428 Tron) or name (eth, base, arbitrum, optimism, polygon, bnb, avalanche, linea, scroll, solana, bitcoin, tron).
`toToken`	No
`fromChain`	No	Chain id (1, 8453, 42161, 10, 137, 56, 43114, 59144, 534352, 792703809 Solana, 8253038 Bitcoin, 728126428 Tron) or name (eth, base, arbitrum, optimism, polygon, bnb, avalanche, linea, scroll, solana, bitcoin, tron).
`fromToken`	No
`recipient`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds context beyond annotations: swap links are random, unguessable, and never expire; amount "max" requires owner; recipient is cross-VM; result includes a `display` markdown field the agent should surface. No contradiction with readOnlyHint=false/openWorldHint=true/idempotentHint=true (a persistent short link is a side effect, consistent with non-readOnly).

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?

Dense but front-loaded: the core purpose and short-link behavior come first, then parameter forms, then the URL scheme, then batch, then the playbook pointer. The literal scheme string is somewhat verbose but does convey the exact link shape; otherwise little waste.

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?

No output schema exists, and the description partially fills that gap by noting the result contains a `display` markdown field with chan images to show the user. Combined with the param form guidance, this is near-complete for a link-builder tool; it could note whether short-link creation is idempotent across repeated calls, but the essentials are covered.

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 67%, and the description compensates by explaining accepted forms (chain names or ids, token symbols or addresses, decimal amount or 'max'), the owner requirement for 'max', the cross-VM nature of recipient, and the attribution role of ref. The items[] batch semantics are also clarified, which the bare schema does not convey.

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+resource: builds a SwapChan deep link with a prefilled swap card plus a permanent short link. It describes the artifact produced and contrasts implicitly with build_swap_tx (which constructs a transaction) by ending in 'hand the user a one-click swap.'

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?

Explicitly says 'Use this whenever you want to hand the user a one-click swap,' and distinguishes the items[] path ('Pass items[] instead to get ONE batch link'). It routes to swapchan_playbook for workflows but does not explicitly state when to prefer build_swap_tx or simulate_swap over this.

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

All SwapChan tools Inspect

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.