Skip to main content
Glama
GemachDAO

GDEX Trading

by GemachDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

buy_token

Destructive

Purchase a token with a chain's native currency from a managed GDEX wallet; returns a requestId to track with wait_for_trade. For USDC payments, use usdc_buy.

Instructions

Buy a token with the chain's native token from the managed GDEX wallet (session-signed purchase_v2). Chains: Ethereum 1, Optimism 10, BSC 56, Sonic 146, Fraxtal 252, Robinhood 4663, Base 8453, Arbitrum 42161, Solana. Returns a requestId; follow it with wait_for_trade. To pay with USDC use usdc_buy.

Input Schema

NameRequiredDescriptionDefault
dexNoNot supported: the backend picks the route. Rejected when set.
chainYesChain: 'solana', 'base', or a chain id (8453=Base, 42161=Arbitrum)
amountYesNative token to spend, e.g. '0.1' for 0.1 SOL; converted exactly to native decimals
apiKeyNoGDEX API key used to encrypt the signed trade
referrerNoNot supported by purchase_v2/sell_v2. Rejected when set.
slippageNoSlippage percent, Solana and Sui only (sent as bps, max 50). Rejected on EVM, where the account's stored slippage applies. Omit to use the stored setting.
accountRefNoConnected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
inputTokenNoOmit, or the chain's native token. Anything else is rejected (use usdc_buy for USDC).
priorityFeeNoSolana priority fee in lamports (integer, max 50000000 = 0.05 SOL). Solana only.
tokenAddressYesContract address (mint on Solana) of the token to buy
walletAddressNoControl wallet address (the GDEX userId)
sessionPrivateKeyNoSession private key from sign-in

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv5.1.0
    • changedInput schema / properties / amount / description
      Previous value: -"Amount of native token to spend, e.g. '0.1' for 0.1 SOL"New value: +"Native token to spend, e.g. '0.1' for 0.1 SOL; converted exactly to native decimals"
    • changedInput schema / properties / apiKey / description
      Previous value: -"GDEX API key for managed-custody buys (with sessionPrivateKey)."New value: +"GDEX API key used to encrypt the signed trade"
    • changedInput schema / properties / chain / description
      Previous value: -"Chain: 'solana', 'sui', or ChainId number (1=ETH, 8453=Base, 42161=Arbitrum)"New value: +"Chain: 'solana', 'base', or a chain id (8453=Base, 42161=Arbitrum)"
    • changedInput schema / properties / dex / description
      Previous value: -"Preferred DEX (raydium, orca, uniswap-v3, cetus, odos, etc.)"New value: +"Not supported: the backend picks the route. Rejected when set."
    • changedInput schema / properties / inputToken / description
      Previous value: -"Override input token address (default: native)"New value: +"Omit, or the chain's native token. Anything else is rejected (use usdc_buy for USDC)."
    • changedInput schema / properties / priorityFee / description
      Previous value: -"Solana priority fee in lamports (integer, Solana only)"New value: +"Solana priority fee in lamports (integer, max 50000000 = 0.05 SOL). Solana only."
    • changedInput schema / properties / priorityFee / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / referrer / description
      Previous value: -"Referral address"New value: +"Not supported by purchase_v2/sell_v2. Rejected when set."
    • changedInput schema / properties / sessionPrivateKey / description
      Previous value: -"Managed-custody session private key (from sign-in). Required for EVM managed swaps — routes through the session-signed purchase_v2 flow."New value: +"Session private key from sign-in"
    • removedInput schema / properties / slippage / default
      Removed value: -1
    • changedInput schema / properties / slippage / description
      Previous value: -"Max slippage tolerance in percent. Default: 1"New value: +"Slippage percent, Solana and Sui only (sent as bps, max 50). Rejected on EVM, where the account's stored slippage applies. Omit to use the stored setting."
    • changedInput schema / properties / tokenAddress / description
      Previous value: -"Contract address of the token to buy"New value: +"Contract address (mint on Solana) of the token to buy"
    • changedInput schema / properties / walletAddress / description
      Previous value: -"Wallet address to trade from"New value: +"Control wallet address (the GDEX userId)"
  2. Changed3 schema fields changedv4.12.0
    • addedInput schema / properties / accountRef
      Added value: +{
+  "description": "Connected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat",
+  "type": "string"
+}
    • addedInput schema / properties / amount / pattern
      Added value: +"^\\d+(\\.\\d+)?$"
    • changedInput schema / properties / priorityFee / description
      Previous value: -"Solana priority fee in SOL"New value: +"Solana priority fee in lamports (integer, Solana only)"
  3. First observedv4.11.3

TDQS

A4.1/5.0
Behavior4/5

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

With destructiveHint=true and openWorldHint=true already declared, the description still adds real value: it discloses the async request/confirm pattern via requestId and wait_for_trade, and that the wallet is managed/session-signed rather than a raw key. It does not state that native funds are irreversibly spent on a DEX route or what happens on a failed fill, which for a destructive trade tool is a notable omission.

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?

Three sentences, front-loaded with the action and mechanism, then chains, then the follow-up step and the alternative. The chain list is long but functional; almost nothing is wasted.

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?

For a 12-parameter destructive trade tool with no output schema, the description covers the essential operating picture: supported chains, wallet model, async completion path, and the USDC alternative. Remaining gaps (failure/refund behavior, prerequisite connection via accountRef) are modest given how much the schema and annotations already carry.

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 parameter documentation is already carried by the schema (including the dex/referrer rejection notes and slippage constraints). The description adds only the inputToken restriction implicitly ('with the chain's native token'), so baseline 3 is appropriate.

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 ('Buy a token') plus the payment asset ('with the chain's native token') and the wallet/mechanism ('managed GDEX wallet, session-signed purchase_v2'). It enumerates supported chains and explicitly disambiguates from usdc_buy, so an agent can tell it apart from its buy siblings without reading the 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?

Gives a clear routing rule ('To pay with USDC use usdc_buy') and a mandated next step ('Returns a requestId; follow it with wait_for_trade'). However, it says nothing about when to prefer limit_buy, managed_purchase, or execute_spot over this tool, so the broader alternative landscape is left to inference.

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