Skip to main content
Glama
walletchan

WalletChan MCP

Official
by walletchan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Swap

swap

Quote and prepare token exchanges, build required approvals plus calls, and submit for WalletChan popup approval unless previewOnly is true.

Instructions

Quote a WalletChan swap, build needed approval plus swap calls, and submit them to WalletChan for popup approval unless previewOnly is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoOptional approved WalletChan sender. Defaults to first approved account.
chainNoChain name or ID. Defaults to the active WalletChan RPC chain.
takerNoAlias for from.
submitNoSet false to return quote and prepared calls without submitting to WalletChan.
buyTokenYesBuy token address, symbol from the WalletChan token list, or native/ETH.
decimalsNoOptional token decimals when sellToken is an address not in the token list.
profileIdNoAlias for executionProfile.
recipientNoOptional recipient for bought tokens.
sellTokenYesSell token address, symbol from the WalletChan token list, or native/ETH.
sellAmountNoDecimal sell amount in token units, e.g. 1.5. Use sellAmountWei for base units.
previewOnlyNoIf true, return quote and prepared calls without submitting to WalletChan.
slippageBpsNoSlippage in basis points. Defaults to 500 (5%).
allowWarningsNoIf true, allow submission despite balance/liquidity warnings. Defaults to false.
sellAmountWeiNoOptional base-unit sell amount as an integer string.
tokenDecimalsNoAlias for decimals.
atomicRequiredNoWhether the WalletChan call batch must execute atomically. Defaults to true with automatic non-atomic fallback.
executionProfileNoExecution profile override. Use walletconnect for main WalletChan popup approval, agent:<walletId> for delegated 1Shot execution, or agent-eoa:<walletId> for raw local agent EOA execution. Defaults to the stored profile.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden, and it does add real context: it quotes, builds approval plus swap calls, and submits for a popup approval unless previewOnly is set. It does not disclose permission/auth requirements, failure modes, gas implications, or what happens on submission rejection. Solid on the core flow, thin on edge behavior.

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?

A single dense sentence with the core action front-loaded and no wasted words. The trailing 'unless previewOnly is true' qualifier is slightly tacked-on but earns its place by modifying the default behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter swap tool with no output schema and no annotations, the description covers the main flow but omits return-shape context (quote object vs submitted transaction) and the non-atomic fallback mentioned in the schema. It is adequate but not complete for the tool's complexity.

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%, so the schema already documents all 17 parameters in detail. The description gestures at previewOnly but adds no syntax, defaults, or alias behavior beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resource: quote a WalletChan swap, build approval plus swap calls, and submit for popup approval. An agent can tell this is a swap-execution tool, distinct from the sibling 'bridge'. It stops short of explicitly contrasting with get_swap_price, which also quotes swaps, so it is clear but not fully sibling-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The 'unless previewOnly is true' clause implies a preview-vs-execute usage mode, and submit=false is documented in the schema. However there is no explicit when-to-use guidance, no routing to alternatives like get_swap_price or bridge, and no stated prerequisites. Usage is implied rather than stated.

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

Deploy Server

Other Tools