Skip to main content
Glama
Sign In

EventTrader MCP

by com.cymetica
OverviewDiscussionsAdmin

Prepare Own Wallet Swap

prepare_own_wallet_swap

Swap any token for any token from the caller's OWN wallet: returns the exact unsigned transaction (EVM tx dict or base64 Solana tx) for that wallet to sign and broadcast. Non-custodial — no key leaves the user, nothing is held, no ledger, no identity step; the wallet is the account. Chains: GET /api/v1/swap/chains; tokens: GET /api/v1/swap/tokens/{chain_id} (Solana is chain_id 501). Platform fee: GET /api/v1/promo/status (0% while the promo runs); the user pays chain gas. Tickers (USDC, ETH, SOL) or contract/mint addresses are accepted. When an ERC-20 sell needs allowance, approval carries the exact approve tx to sign first. Optionally record the signed tx in swap history with POST /api/v1/swap/broadcast (X-API-Key).

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_id": "<chain_id>",
      "sell_token": "<sell_token>",
      "buy_token": "<buy_token>",
      "sell_amount": "<sell_amount>",
      "wallet_address": "<wallet_address>"
    },
    "name": "prepare_own_wallet_swap"
  }
}

Input Schema

NameRequiredDescriptionDefault
chain_idYesChain id (1 Ethereum, 8453 Base, 56 BNB, 137 Polygon, 42161 Arbitrum, 10 Optimism, 43114 Avalanche, 501 Solana)
buy_tokenYesToken to buy: symbol or contract/mint address
sell_tokenYesToken to sell: symbol or contract/mint address
sell_amountYesAmount of sell_token in whole units (e.g. "25")
slippage_bpsNoMax slippage in basis points (1-5000)
wallet_addressYesThe user's OWN wallet address that will sign (0x… on EVM, base58 on Solana)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already mark it non-destructive, non-idempotent and non-read-only, and the description adds real behavioral context beyond that: nothing is custodied, no identity step, gas paid by the user, platform fee varies via a promo endpoint, and an `approval` tx must be signed first for ERC-20 sells. The remaining gap is that it doesn't say whether the returned tx expires or how quotes are priced/fresh.

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-loads the core action and return shape before the supporting endpoint references, so an agent can stop reading early. It is dense with GET paths and parentheticals that could be trimmed, but every clause carries operational information.

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?

No output schema exists, and the description compensates by naming the exact return payload and the conditional `approval` field. Combined with the fee/gas and optional broadcast-recording notes, an agent has enough to call this correctly.

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 all six parameters are already documented in the schema. The description adds marginal meaning (symbols vs contract/mint addresses, Solana = chain_id 501) but mostly restates what the schema says; baseline 3 applies when the schema carries the load.

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?

Uses a specific verb ('Swap... from the caller's OWN wallet') plus the exact artifact produced ('returns the exact unsigned transaction (EVM tx dict or base64 Solana tx)'). The 'OWN wallet / non-custodial' framing distinguishes it from custodial or path-finding siblings such as find_trade_path and place_order.

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?

Gives clear context: use when the user's own wallet will sign and broadcast, with tickers or contract addresses accepted, and it points to GET endpoints for chain/token/fee discovery. It never names an explicit alternative tool or a when-not-to-use case, so it stops short of a 5.

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

All EventTrader MCP 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