Skip to main content
Glama
Sign In

TraderWAI

by com.traderwai
OverviewDiscussionsAdmin

Execute Trade

execute_trade
Destructive

Place an order on a connected broker account NOW: market, or a pending LIMIT or STOP order at the broker. Use this when the user wants to trade RIGHT NOW — e.g. "buy EUR/USD", "sell Gold at 2450". This sends the order to the broker instantly. Plain breakout entries ("sell if price breaks below X", "buy above Y") are pending STOP orders: on TradeLocker, cTrader, MetaTrader, Capital.com, Bybit and tastytrade send executionType "STOP" (they wait at the broker and trigger instantly at its price). Use create_conditional_order only for what the broker cannot do: candle closes, liquidity sweeps, time windows, several conditions, or platforms without STOP orders (Match-Trader, Binance). Supports LONG (buy) and SHORT (sell) with stop loss and take profit. You can specify quantity in lots directly, or use percentage-based sizing (sizingMode="percentage") to risk a % of the account balance. IMPORTANT: the percentage is the % of the balance LOST if the stop loss is hit, NOT the share of the balance used to open the trade (1 = lose 1% of the balance at the stop). Typical values are 0.25-2%. Up to 100% is allowed, but above 10% the order is rejected until the user confirms it: explain the risk in plain words (in money if you know the balance, and the total if several orders share it, e.g. 10 ladder orders × 1% = 10% of the account) and only if they confirm, repeat the call with confirmHighRisk: true. Use get_broker_accounts to find available accounts and their IDs. Before sending, ALWAYS get the broker's current price with get_quote and compute levels from it (never from get_ohlc): a BUY LIMIT must be below the ask and a SELL LIMIT above the bid; a BUY STOP above the ask and a SELL STOP below the bid. The stop loss of a buy goes below the entry and of a sell above it. If the user's level is on the wrong side, do not send it: ask. Each execution consumes 1 daily credit.

Input Schema

NameRequiredDescriptionDefault
symbolYesTrading symbol in TraderWAI format (e.g. "EUR_USD", "XAU_USD", "NAS100_USD", "BTC_USD")
quantityNoPosition size in lots (e.g. 0.01 = micro lot, 0.1 = mini lot, 1.0 = standard lot). Required unless using percentage sizing.
stopLossYesStop loss price level (absolute price, not pips). The trade will be closed at a loss if price reaches this level.
trailingNotrue: trailing stop executed by the broker — the stop follows price at the initial stop distance (entry to stopLoss) and only moves in favour. Available on cTrader, TradeLocker and MetaTrader (market and pending orders) and Bybit (market orders); rejected on other platforms. backtest_strategy trade.trailing simulates the same rule.
orderTypeYesTrade direction: "LONG" for buy, "SHORT" for sell
entryPriceNoRequired for LIMIT and STOP orders: the price where the pending order triggers. Ignored for MARKET orders.
sizingModeNoHow to determine position size. "fixed_lots" (default): use the quantity field directly. "percentage": risk a % of account balance (requires sizingValue).
takeProfitYesTake profit price level (absolute price, not pips). The trade will be closed at a profit if price reaches this level.
sizingValueNoWhen sizingMode="percentage", the % of the account balance LOST if the stop loss is hit (e.g. 1 = lose 1% at the stop; not the share of the balance used). The lot size is auto-calculated from the SL distance. Above 10 requires confirmHighRisk.
executionTypeYes"MARKET" fills now at the broker price. "LIMIT" = pending order for a pullback (BUY LIMIT below the ask, SELL LIMIT above the bid). "STOP" = pending order for a breakout (BUY STOP above the ask, SELL STOP below the bid), only on TradeLocker, cTrader, MetaTrader, Capital.com, Bybit and tastytrade; elsewhere use create_conditional_order with action type "market".
brokerAccountIdYesID of the broker account to trade on. Use get_broker_accounts to list available accounts.
confirmHighRiskNoOnly after the user explicitly confirmed a percentage risk above 10% per order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / trailing
      Added value: +{
+  "description": "true: trailing stop executed by the broker — the stop follows price at the initial stop distance (entry to stopLoss) and only moves in favour. Available on cTrader, TradeLocker and MetaTrader (market and pending orders) and Bybit (market orders); rejected on other platforms. backtest_strategy trade.trailing simulates the same rule.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / executionType / description
      Previous value: -"\"MARKET\" fills now at the broker price. \"LIMIT\" = pending order for a pullback (BUY LIMIT below the ask, SELL LIMIT above the bid). \"STOP\" = pending order for a breakout (BUY STOP above the ask, SELL STOP below the bid), only on TradeLocker, cTrader, MetaTrader, Capital.com and Bybit; elsewhere use create_conditional_order with action type \"market\"."New value: +"\"MARKET\" fills now at the broker price. \"LIMIT\" = pending order for a pullback (BUY LIMIT below the ask, SELL LIMIT above the bid). \"STOP\" = pending order for a breakout (BUY STOP above the ask, SELL STOP below the bid), only on TradeLocker, cTrader, MetaTrader, Capital.com, Bybit and tastytrade; elsewhere use create_conditional_order with action type \"market\"."
  3. Changed2 schema fields changed
    • addedInput schema / properties / confirmHighRisk
      Added value: +{
+  "description": "Only after the user explicitly confirmed a percentage risk above 10% per order.",
+  "type": "boolean"
+}
    • changedInput schema / properties / sizingValue / description
      Previous value: -"When sizingMode=\"percentage\", the % of account balance to risk (e.g. 2 = risk 2% of balance). The lot size is auto-calculated based on SL distance."New value: +"When sizingMode=\"percentage\", the % of the account balance LOST if the stop loss is hit (e.g. 1 = lose 1% at the stop; not the share of the balance used). The lot size is auto-calculated from the SL distance. Above 10 requires confirmHighRisk."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive, non-idempotent and open-world, so the description's job is added context — and it delivers: 1 daily credit per execution, rejection above 10% percentage risk until confirmHighRisk:true, the exact confirmation script (explain in money, aggregate ladder orders), and the percentage semantics being loss-at-stop rather than capital deployed. That is the kind of behavior an agent cannot infer from the annotations.

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-loaded with the core action and the sibling split, and nearly every sentence carries operational weight. It is still a dense block with some duplication — the percentage-risk definition and the LIMIT/STOP side rules appear both here and in the schema — which keeps it from a 5.

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?

For a destructive, 12-parameter, credit-consuming trade tool, the description covers risk confirmation, platform support, price-level validation, account lookup and credit cost. With no output schema, the only omission is what a successful call returns (order ID, fill status), which is minor relative to everything else it supplies.

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 the baseline is 3; the description earns above that by supplying the confirmHighRisk escalation workflow and the wrong-side validation rule that the schema does not encode. It loses a point for restating schema content almost verbatim (percentage risk definition, BUY LIMIT below ask / SELL LIMIT above bid) rather than extending it, and it says nothing about trailing or entryPrice beyond what the schema already documents.

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 (place an order on a connected broker account) with immediate scope qualifiers: market, pending LIMIT, or STOP. It explicitly separates itself from the closest sibling by naming create_conditional_order and describing exactly which cases belong there (candle closes, liquidity sweeps, time windows, platforms without STOP orders).

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?

Explicit when-to-use ("user wants to trade RIGHT NOW") and when-not-to-use (anything the broker cannot do natively → create_conditional_order), with per-platform carve-outs. It also prescribes the prerequisite workflow: get_broker_accounts for the account ID and get_quote before computing levels, plus the rule to ask rather than send when the level is on the wrong side.

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

All TraderWAI 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