Skip to main content
Glama

siexchange_calldata

Generate ready-to-sign swap calldata for Solana, Base, Ethereum, Polygon, or Robinhood; launch coins return free calldata, arbitrary token pairs require a $0.02 x402 payment.

Instructions

[FREE for launch coins / $0.02 x402 for arbitrary tokens] Ready-to-sign swap transaction from the Super Intelligence Exchange (siexchange.lol). Non-custodial: the exchange NEVER holds keys or broadcasts; the taker signs and submits with their own wallet. chain: solana|base|ethereum|polygon| robinhood. taker: the checksummed EVM address or Solana pubkey that will sign. Launch-set coins (MUSKOX, ARENA, SOLV, AGWC, GITLAWB + gas/quote currencies) return calldata free. Arbitrary token pairs return an x402 payment request for $0.02 USDC on Base L2 via https://x402-agent-pay.com/facilitator: attach

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": {
      "chain": "<chain>",
      "token_in": "<token_in>",
      "token_out": "<token_out>",
      "amount_in": "<amount_in>",
      "taker": "<taker>"
    },
    "name": "siexchange_calldata"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainYes
takerYes
token_inYes
amount_inYes
token_outYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

B3/5.0
Behavior1/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does good work here: non-custodial, the exchange never holds keys or broadcasts, the taker signs and submits, plus pricing and payment rail. However the text is truncated mid-instruction ('attach '), leaving the crucial x402 payment-attachment step undefined for the paid path.

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?

Front-loads the price/free distinction and the non-custodial guarantee, which is good ordering, and the density is reasonable. But the final sentence runs off mid-thought ('attach '), so the structure is visibly broken rather than tight.

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 5-required-parameter, no-annotation, no-output-schema trading tool, the description covers custody model, chains, pricing, and payment rail, which is substantial. The truncated ending means an agent cannot complete the paid x402 flow from this text alone, so it is not fully self-sufficient.

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 0%, so the description must compensate, and it largely does: it enumerates the valid chain values (solana|base|ethereum|polygon|robinhood) and specifies the taker format (checksummed EVM address or Solana pubkey), neither of which appears in the schema. It adds nothing about amount_in units/decimals or the token_in/token_out address format, so a small gap remains.

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 a concrete verb and resource: a ready-to-sign swap transaction (calldata) from the Super Intelligence Exchange, with the non-custodial signing model spelled out. It never names its closest sibling (siexchange_quote), so the agent must infer the quote-vs-calldata boundary, which keeps this short of a 5.

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?

Usage is only implied through pricing tiers: launch-set coins return calldata free, arbitrary pairs trigger an x402 payment request. That hints at when the call succeeds outright versus when it returns a payment challenge, but there is no explicit 'use this when you are ready to sign/execute, call siexchange_quote first' routing guidance.

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