Skip to main content
Glama

Execute live CEX order

execute_trade
Destructive

Execute a live CEX order immediately (real money) via stored exchange keys. Needs the trade:execute scope AND user YOLO eligibility (kill switch off, autonomy != propose_only); caps enforced per order. Fee-aware: pass stop to refuse stops that cannot survive round-trip fees (min-move gate), or risk_usd to size from risk (needs stop, else an ATR stop from venue klines). Returns the fee estimate + min-move in the result. CEX spot/futures only — never on-chain.

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": {
      "exchange": "<exchange>",
      "pair": "<pair>",
      "side": "<side>"
    },
    "name": "execute_trade"
  }
}

Input Schema

NameRequiredDescriptionDefault
tpNoTake-profit price (> 0) armed with the entry as a single 100%-share venue-native TP exit leg across all CEX venues. Must sit on the profit side of the entry (long: above, short: below).
pairYese.g. BTC/USDT
sideYesOrder side: buy|sell
stopNoProtective stop price (> 0). Gated server-side: stops inside round-trip fees x factor are refused with the shortfall spelled out, and armed as a venue-native SL exit leg after the entry across all CEX venues.
typeNoOrder type. Defaults to 'limit' when a price is given, else 'market'. Use 'market' for a live entry: the exit legs are venue-native conditionals that attach to a POSITION, so a RESTING LIMIT has no position to protect and rests on the book unprotected until it fills.
actorNoWHO is placing the order. 'machine' for the trading machine; 'owner' for the account owner's own manual trading. The account is SHARED, so this is what tells the machine's trades from the owner's when a closed trade is reconciled against the machine's daily loss cap. Defaults to 'owner'.
priceNoLimit price. OMIT for a market order. When the order type is 'market' the price is only a reference for sizing and is NOT sent to the venue — a resting limit has no position to protect, so the exit legs cannot attach to it.
amountNoBase units, e.g. 0.05 (omit when risk_usd sizes the order)
marketNoWhich market to trade (default spot)
tpLegsNoOptional 1-3 split take-profit legs ({ price, share }, where share is 1..100 percent of entry size) armed as venue-native TP orders after the entry.
tpPriceNoDeprecated alias of tp.
exchangeYesCEX slug, e.g. kucoin
leverageNoFutures only; rides the order (KuCoin has no venue-level setting)
risk_usdNoMax USD loss at the stop — sizes the order as risk_usd / stop distance (needs stop, else ATR stop from venue klines; capped by max_position_usd + lot step).
clientOidNoOptional caller-supplied identity tag for the order (max 36 chars, [A-Za-z0-9_-]). A later session uses it to attribute the order to its owner instead of classifying it as foreign/unknown-origin. Omit it and the server generates a random UUID.
marginModeNoFutures only; isolated bounds max loss to position margin (default cross)
connectionIdNoCEX connection id (see list_connections). Takes precedence over exchange.
referencePriceNoFor a MARKET order only: the price the exit legs were derived from. The venue may fill the entry at a different price, and the server REBASES the stop and target onto the actual fill (each keeps its distance from this reference). Omit it and the legs are placed at their original absolute prices, which can land on the wrong side of the fill.
idempotency_keyNoOptional per-INTENT key. Two submits with the same key are the same intent: the second is deduped and never dispatched again. Use it when a submission may be retried (a timeout, a reconnect) so a retry cannot double-fill.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the destructive/open-world annotations, the description discloses required auth scope, eligibility gating, kill-switch and autonomy constraints, per-order caps, stop min-move fee gating, and that results include the fee estimate plus min-move. It also clarifies that CEX spot/futures are supported but on-chain execution is not.

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?

The description is front-loaded with the action and real-money warning, followed by eligibility and fee-aware execution details. It is dense but organized, and each sentence carries operational information for a destructive live-trading tool.

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 19-parameter destructive trading tool with no output schema, the description covers the essential prerequisites, gating, fee-aware behavior, venue restriction, and key return information. Some failure-mode detail and explicit sibling routing are omitted, but the schema carries the per-parameter burden.

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?

With 100% schema coverage, the schema already documents all 19 parameters. The description adds cross-parameter meaning not obvious from individual fields: risk_usd needs a stop or falls back to an ATR stop from venue klines, stops inside round-trip fees are refused, and market orders are required for live entries because resting limits cannot attach protective exit legs.

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?

The description states a specific verb and resource: 'Execute a live CEX order immediately (real money)'. It also distinguishes the scope from proposal siblings by emphasizing immediate live execution and restricting the venue to CEX spot/futures, never on-chain.

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?

It gives concrete prerequisites, including the trade:execute scope, YOLO eligibility with kill switch off, autonomy not propose_only, and per-order caps. It does not explicitly name propose_trade or another alternative as the safer path, so the when-not guidance is implied rather than fully spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.