Skip to main content
Glama
Sign In

SwapChan

by io.github.TSavo
OverviewDiscussionsAdmin

Build a limit order

build_limit_order
Read-only

Build a gasless CoW Protocol limit order (sell an ERC-20 for at least a target amount, valid until expiry). Returns EIP-712 typed data for the user's wallet to sign, the ERC-20 approve tx for CoW's vault relayer if the allowance is short, the current market amount for reference, and how to submit the signature. Never signs or submits. 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chainId": "<chainId>",
      "owner": "<owner>",
      "sellToken": "<sellToken>",
      "buyToken": "<buyToken>",
      "sellAmount": "<sellAmount>"
    },
    "name": "build_limit_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
ownerYesWallet that signs and owns the order
chainIdYesChain id where CoW runs: 1 Ethereum, 8453 Base, 42161 Arbitrum, 137 Polygon, 56 BNB, 43114 Avalanche, 59144 Linea
buyTokenYesToken to receive
buyAmountNoMinimum human amount to receive (the limit). Provide this OR limitPrice.
sellTokenYesERC-20 to sell (not the native token; wrap first)
limitPriceNoPrice in buyToken per 1 sellToken. Provide this OR buyAmount.
sellAmountYesHuman amount to sell, e.g. "100"
expiresInHoursNoDefault 168 (7 days)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

The description discloses the full return shape (EIP-712 typed data, conditional vault-relayer approve tx, current market amount, submission instructions) and reinforces the readOnlyHint by stating it never signs or submits. It also flags an output-side obligation — show the `display` markdown to the user. It stops short of failure modes, allowance-check semantics, or what happens on unsupported chains.

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?

Front-loaded and dense — the core purpose and the non-submission guarantee land in the first two sentences. The trailing parenthetical listing seven playbook workflow names is the one part that is enumerative rather than informative, and it slightly dilutes the close.

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?

With no output schema, the description carries the burden of describing returns, and it does so concretely — typed data, approve tx, market reference, submission steps, display markdown. For an 8-parameter read-only builder this is nearly complete; only error/edge-case behavior is left unaddressed.

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 coverage is 100%, so every parameter including the buyAmount/limitPrice mutual exclusion and the chainId enum-like listing is already documented in structured fields. The description only echoes "target amount" and "valid until expiry," adding no parsing or format guidance beyond the schema. 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.

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 gasless CoW Protocol limit order — and immediately defines the semantics that separate it from a market swap: sell an ERC-20 for at least a target amount, valid until expiry. Against siblings like build_swap_tx, cancel_limit_order, and list_limit_orders, an agent can pick this correctly without opening a schema.

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?

"Never signs or submits" plus the explicit pointer to swapchan_playbook and its named workflows gives an agent clear routing context for the broader flow. What's missing is an explicit exclusion — it never says when to prefer build_swap_tx or get_quote instead of building a limit order, leaving that inference to the agent.

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

All SwapChan toolsInspect
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.

Resources