Skip to main content
Glama

evm_swap

Build a non-custodial swap across 7 EVM chains via KyberSwap aggregator. Returns unsigned calldata for you to sign with your wallet.

Instructions

Build a NON-CUSTODIAL EVM DEX swap via KyberSwap aggregator on eth/base/bsc/arbitrum/polygon/optimism/avax: returns UNSIGNED calldata {to,data,value} — sign with YOUR OWN wallet. Server never touches funds. 0.3% routing fee. ERC20 input needs prior approval.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesEVM chain
amountNoHuman amount (native only)
accountYesYour 0x wallet address
tokenInYes0x-address or native
tokenOutYes0x-address or native
amountRawNoBase units (any token)
slippageBpsNo10-2000, default 100
Behavior5/5

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

Discloses beyond annotations: returns UNSIGNED calldata, server never touches funds, 0.3% routing fee, ERC20 approval requirement. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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?

Two dense sentences plus a brief note. Front-loaded with key info. Every word earns its place.

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?

Complete for a swap tool with rich annotations. No output schema but explains return value as {to,data,value}. All 7 parameters covered in schema; description addresses critical behavioral aspects.

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%, but description adds value by clarifying amount vs amountRaw (human vs base units) and implicit approval requirement for ERC20 inputs. Baseline 3 exceeded.

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 uses specific verb 'Build' with resource 'NON-CUSTODIAL EVM DEX swap via KyberSwap aggregator' and lists supported chains. It clearly distinguishes from sibling tools like sol_swap or hl_build_order by specifying EVM and non-custodial nature.

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?

Provides clear context: non-custodial, sign with own wallet, ERC20 needs prior approval, 0.3% fee. Does not explicitly list when not to use, but the details implicitly guide correct usage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/polsolbridge/solana-swap-api'

If you have feedback or need assistance with the MCP directory API, please join our Discord server