GDEX Trading

sell_token

Destructive

Sells a token from your managed GDEX wallet for the chain's native token, accepting an absolute amount or a percentage of your balance and returning a requestId to track with wait_for_trade.

Instructions

Sell a token for the chain's native token from the managed GDEX wallet (session-signed sell_v2). Amount is a token amount ('100') or a percentage of the held balance ('50%', '100%'), resolved from the managed holdings. Returns a requestId; follow it with wait_for_trade. To receive USDC use usdc_sell.

Input Schema

Name	Required	Description
`dex`	No	Not supported: the backend picks the route. Rejected when set.
`chain`	Yes	Chain identifier
`amount`	Yes	Amount to sell, e.g. '100' or '50%'
`apiKey`	No	GDEX API key used to encrypt the signed trade
`referrer`	No	Not supported by purchase_v2/sell_v2. Rejected when set.
`slippage`	No	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.
`accountRef`	No	Connected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
`outputToken`	No	Omit, or the chain's native token. Anything else is rejected (use usdc_sell for USDC).
`priorityFee`	No	Solana priority fee in lamports (integer, max 50000000 = 0.05 SOL). Solana only.
`tokenAddress`	Yes	Contract address of the token to sell
`tokenDecimals`	No	Only for an absolute amount of a token missing from the managed holdings
`walletAddress`	No	Control wallet address (the GDEX userId)
`sessionPrivateKey`	No	Session private key from sign-in

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv5.1.0Oct 23, 2026

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 / apiKey

Added value: +{
+  "description": "GDEX API key used to encrypt the signed trade",
+  "type": "string"
+}

changedInput schema / properties / dex / description

Previous value: -"Preferred DEX"New value: +"Not supported: the backend picks the route. Rejected when set."

changedInput schema / properties / outputToken / description

Previous value: -"Override output token address"New value: +"Omit, or the chain's native token. Anything else is rejected (use usdc_sell 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."

addedInput schema / properties / sessionPrivateKey

Added value: +{
+  "description": "Session private key from sign-in",
+  "type": "string"
+}

removedInput schema / properties / slippage / default
```
Removed value: -1
```

changedInput schema / properties / slippage / description

Previous value: -"Max slippage tolerance in percent"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."

addedInput schema / properties / tokenDecimals

Added value: +{
+  "description": "Only for an absolute amount of a token missing from the managed holdings",
+  "type": "integer"
+}

changedInput schema / properties / walletAddress / description

Previous value: -"Wallet address to trade from"New value: +"Control wallet address (the GDEX userId)"

Changed2 schema fields changedv4.12.0Oct 19, 2026
- 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)"
```
First observedv4.11.3Oct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructive=true, readOnly=false, openWorld=true, so the safety profile is covered. The description adds value beyond that: it is session-signed, amounts are resolved against managed holdings, it returns a requestId that must be polled with wait_for_trade. Minor gap: no note on failure modes or whether the sell can partially fill.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action, then amount semantics, then output/next-step routing. No filler.

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 13-parameter mutation tool with no output schema, the description covers the essentials: what it sells into, amount forms, return handle, and the follow-up tool. It leaves auth/session sourcing and rejection cases to the schema, which handles them, so remaining gaps are minor.

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 100%, so baseline would be 3. The description still adds meaning by explaining that amount may be absolute ('100') or a percentage of held balance ('50%') resolved from managed holdings, which is not fully spelled out in the schema's terse pattern text.

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: sell a token for the chain's native token from the managed GDEX wallet, using session-signed sell_v2. It also explicitly distinguishes itself from the sibling usdc_sell for USDC output, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Names the alternative (usdc_sell) and the condition that selects it ('To receive USDC'), and prescribes the follow-up step ('Returns a requestId; follow it with wait_for_trade'). Provides both when-to-use and what-to-do-next guidance.

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

Deploy Server

sell_token

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools