Claude, ChatGPT, Grok or Perplexity: draw on live charts, backtest and trade on your own broker
Scored across 43 tools
Execution-related tools overlap heavily: execute_trade, execute_trade_multi, suggest_order, create_conditional_order, and run_conditional_order all concern placing, proposing, or evaluating trades. The cancel/delete pairs across conditional orders, broker orders, and suggested orders also require careful reading, though the descriptions explicitly disambiguate many cases.
Names almost uniformly follow a snake_case verb_noun pattern such as get_ohlc, create_conditional_order, cancel_broker_order, and set_auto_execution_config. Minor deviations are limited to expected singular/plural variants and compound terms like get_broker_account_state, so the convention remains highly predictable.
With 43 tools, the server is far beyond the well-scoped 3–15 range and carries many specialized operations across market data, execution, conditional rules, broker administration, auto-execution, risk, and billing. The breadth reflects a full trading platform, but the surface is too large for an agent to navigate efficiently.
The tool set covers market data, charting and drawing, backtesting, single/multi-account execution, conditional-order lifecycle, broker account management, positions, suggested orders, risk limits, auto-execution, account groups, trade results, and plan management. Only minor gaps exist, such as retrieving a single broker pending order or richer order-history inspection.
Backtest a rule-based strategy on TraderWAI historical 1-minute data and get every trade plus a summary (win rate, total R, drawdown). It uses the SAME rules and engine as create_conditional_order, so a rule that looks good can be turned into a live conditional order. Pure calculation on the server, no AI: use it whenever the user asks to backtest or "how would this have worked" — do not compute backtests yourself from get_ohlc candles. Levels can be daily references so the rule works every day: {"ref":"session_high","session":"asia"} (asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC), {"ref":"range_high","start":"00:00","end":"06:00"}, {"ref":"prev_day_low"}; the rule is armed each day once its levels are known. Example — "buy EUR/USD when it breaks the Asian high": symbol EUR_USD, conditions [{"type":"close_above","timeframe":"M15","level":{"ref":"session_high","session":"asia"}},{"type":"time_window","start":"07:00","end":"12:00"}], trade {"side":"buy","stop":{"type":"level","ref":{"ref":"session_low","session":"asia"}},"target":{"type":"rr","value":2},"closeAt":"20:00"}. Example — "sell gold when it sweeps the Asian high": conditions [{"type":"sweep_above","timeframe":"M15","level":{"ref":"session_high","session":"asia"},"maxCandles":2}], trade {"side":"sell","stop":{"type":"wick","bufferPips":20},"target":{"type":"rr","value":2}}. Indicators and trend filters: any level can be {"ref":"indicator","indicator":"sma|ema|rsi|atr|highest|lowest","timeframe":"D1","period":50}, {"ref":"price"}, {"ref":"day_open"} or {"ref":"day_high","daysAgo":2}; combine them with compare (e.g. {"type":"compare","left":{"ref":"price"},"op":"above","right":{"ref":"indicator","indicator":"ema","timeframe":"D1","period":50}}) and candle_direction (e.g. yesterday bullish). Indicators use closed candles only. Example — "buy gold on the first retest of a bullish M15 FVG in London": conditions [{"type":"fvg_retest","timeframe":"M15","direction":"bullish","maxCandles":20},{"type":"time_window","start":"07:00","end":"12:00"}], trade {"side":"buy","stop":{"type":"wick","bufferPips":10},"target":{"type":"rr","value":2}} (the wick stop goes beyond the gap's far edge). Limit entries and time exits: trade.entry {"type":"limit","at":{"type":"fvg","point":"midpoint"},"expiryMinutes":60} waits for price to come back to the limit (unfilled signals are reported), trade.maxMinutes closes after N minutes, and the target can be "none" with a time exit. Example — "when a bearish M15 FVG forms on gold, sell limit at its midpoint, stop above the gap, 2R or close after 2 hours": conditions [{"type":"fvg_formed","timeframe":"M15","direction":"bearish"}], trade {"side":"sell","entry":{"type":"limit","at":{"type":"fvg","point":"midpoint"},"expiryMinutes":60},"stop":{"type":"wick","bufferPips":20},"target":{"type":"rr","value":2},"maxMinutes":120}. Example — "buy the break and retest of today's 08:00-10:00 UTC range high": conditions [{"type":"retest","timeframe":"M15","direction":"up","level":{"ref":"range_high","start":"08:00","end":"10:00"},"maxCandles":10}], trade {"side":"buy","stop":{"type":"wick","bufferPips":5},"target":{"type":"rr","value":2}} (the wick stop goes below the retest candle; same rule and result as a live conditional). A limit entry at a level can be shifted with trade.entry.at.pips (positive above, negative below the level). COSTS: costs {"spreadPips","slippagePips","commissionPerLot" (USD, gold/silver/USD forex) or "commissionPips"} are charged on buys AND sells and the result shows R gross and net (spreadPips alone works the same). Always add realistic costs for strategies with small stops (M1/M5). RESULT DETAIL: every trade has its stop size in pips, MFE and MAE in R (how far it went for / against before closing), and the summary breaks the result down by month, by halves of the period, by weekday and entry hour, with profit factor and how many trades reached +1R…+4R: use it to choose the target and stop instead of running one backtest per variant; allTrades:true lists every trade (up to 300). STOP AT THE GAP: trade.stop {"type":"fvg","edge":"far","bufferPips":30} puts the stop beyond the far edge of the fvg_retest/fvg_formed gap, and "edge":"pattern" beyond the high/low of the three candles that form it; with a limit entry at the far edge use "pattern" (a far-edge stop would sit right next to the entry). trade.minStopPips/maxStopPips skip signals with a stop outside that size (counted). MANAGEMENT: trade.management {"breakevenAtR":1,"partials":[{"atR":1,"closePct":50}]} moves the stop to entry at +1R and closes half at +1R. LOCAL MARKET TIME: time_window, range_high/range_low and trade.closeAt accept "timezone" (e.g. Europe/London, America/New_York), so a London 08:00-11:00 window is measured at the same market hour in summer and winter. MARKET STRUCTURE: swings, BOS/CHoCH, order blocks, flip zones (broken base), Fibonacci of the last impulse, FVGs and equal highs/lows are detected candle by candle without look-ahead (see the condition types). Example — "sell gold on the first retest of a bearish order block + Fibonacci 0.5-0.618 + broken base overlap on M15, rejection candle on M5, bearish day, stop above the zone, target the last swing low, exit if no new low in 6 M5 candles": conditions [{"type":"bos","timeframe":"M15","direction":"bearish"},{"type":"confluence","direction":"bearish","zones":[{"zone":"order_block","timeframe":"M15"},{"zone":"flip_zone","timeframe":"M15"},{"zone":"fib_zone","timeframe":"M15","from":0.5,"to":0.618}],"min":2,"trigger":"rejection","confirmTimeframe":"M5","maxTouches":3},{"type":"compare","left":{"ref":"price"},"op":"below","right":{"ref":"day_open"}}], trade {"side":"sell","stop":{"type":"zone","edge":"far","bufferPips":20},"target":{"type":"level","ref":{"ref":"swing_low","timeframe":"M15"}},"management":{"exitIfNoProgress":{"candles":6,"timeframe":"M5"}}}. Results are broken down by zone / combination. Selective setups give few trades: use long periods, and sensitivity:true reruns the rule with neighbouring parameters (swing strength ±1, target ±0.5R) to see if the result holds. TRAILING: trade.trailing true moves the stop behind price at the initial stop distance (same rule as trailing: true on live orders). Not supported: other chart patterns (head and shoulders, triangles…), news, ATR or candle trailing stops. History available: 2 years of 1-minute candles (since 31 Oct 2024) on forex, gold, silver, crypto, indices and oil. Plan limits: Free = last 14 days and 5 backtests per day; Plus = 6 months and 20 per day; Trader = 1 year and 50 per day; Max = all history, unlimited. One backtest covers at most 1 year (2 years on Max) and up to 2000 trades: split longer periods. Works with the market closed (weekends) and without a broker account.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End (ISO 8601, default now) | |
| days | No | Period: the last N days (default 7) | |
| from | No | Or an explicit start (ISO 8601) | |
| costs | No | Trading costs charged on every trade (buys and sells): the result shows R gross and net of costs. E.g. gold {"spreadPips":30,"commissionPerLot":7} | |
| trade | Yes | Side, stop, target and optional daily close time | |
| symbol | Yes | Symbol (e.g. EUR_USD, XAU_USD, NAS100_USD). | |
| allTrades | No | true: list every trade of the period (up to 300) instead of the latest 40 | |
| conditions | Yes | Entry rule (all conditions must be met, max 5). Same types as create_conditional_order except at_time | |
| spreadPips | No | Spread in pips, charged on buys and sells (same as costs.spreadPips) | |
| sensitivity | No | true: also run the rule with neighbouring parameters (swing strength ±1 for structure conditions, target ±0.5R) and report each result, to check it is not fitted to the past |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond them: server-side pure calculation with no AI, available history, plan limits, cost simulation, result breakdowns, sensitivity checks, unsupported features, and behavior with markets closed. No contradiction with the annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, but it is extremely long and dense, with repeated examples and duplicated guidance across sections. The length is partly justified by the complex nested schema, but it is not concise and could be tightened without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema, lack of an output schema, and wide range of condition types, the description is highly complete. It explains return details, cost treatment, plan limits, unsupported features, and operational constraints that an agent needs in order to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already carries parameter semantics. The description adds meaningful value beyond it through concrete examples for levels, sessions, indicators, entries, stops, targets, management, costs, and timezone handling, though some of this repeats structured schema descriptions rather than introducing entirely new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: backtest a rule-based strategy on TraderWAI historical 1-minute data, returning every trade plus a summary. It explicitly distinguishes the tool from create_conditional_order and get_ohlc by saying rules are shared with live conditionals and that the agent should not compute backtests from candles itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'use it whenever the user asks to backtest or how would this have worked' and a clear when-not alternative: 'do not compute backtests yourself from get_ohlc candles.' It also explains how backtest rules map to create_conditional_order live orders and notes plan/history limits that affect when the tool is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a pending order (limit/stop order waiting to be filled) on a broker account. The order will be removed from the broker and will not be filled. This does not affect any existing open positions.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The pending order ID (from get_positions) | |
| brokerAccountId | Yes | The broker account ID (from get_positions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the bar is lower. The description still adds real context beyond them: the order is removed from the broker, will not be filled, and open positions are untouched. It does not address reversibility or what happens if the order was already filled, but the added effect-scope detail is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action, and the second sentence (scope of effect on positions) earns its place by pre-empting a likely misreading. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with no output schema, the description covers what the tool does and its blast radius. Its only gaps are edge-case outcomes (order already filled, cancel failure) which an agent might want, but annotations plus the effect statement make it largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, and each already documents its origin ('from get_positions'). The description contributes no parameter-level meaning at all, so the baseline 3 for a fully-documented schema is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Cancel a pending order') and further narrows the scope with the parenthetical '(limit/stop order waiting to be filled) on a broker account', which implicitly separates it from cancel_conditional_order and cancel_suggested_order. It stops short of naming those siblings explicitly, so an agent must still infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'This does not affect any existing open positions' implies this tool is not the route for closing positions, nudging the agent toward close_position/modify_position, but no alternative sibling is named and no when-not condition is stated. Usage is inferred rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an active conditional order. The order will stop being monitored by the AI. This action is irreversible — the order status changes to "cancelled" and cannot be reactivated. Use update_conditional_order with enabled=false to temporarily pause monitoring instead.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The conditional order ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is known. The description adds real behavioral context on top: the AI stops monitoring the order, the status transitions to 'cancelled', and it cannot be reactivated. It does not explain failure modes (e.g., cancelling an already-terminal order), so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action, then consequences, then the alternative. Every sentence carries information an agent needs; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation with no output schema, the description supplies the missing outcome information (status becomes 'cancelled', monitoring stops, no reversal) and the routing alternative. Nothing an agent needs to call this correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 100% schema description coverage, the schema already documents orderId fully. The description adds no formatting, range, or sourcing detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Cancel an active conditional order') with a clear qualifier that this applies only to active orders. It also names the sibling alternative (update_conditional_order) for the pause case, so an agent can separate it from adjacent conditional-order tools without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly handles the when/when-not decision: cancel when the order should never run again, versus update_conditional_order with enabled=false to temporarily pause monitoring. This is exactly the ambiguity an agent would face given siblings like update_conditional_order, delete_conditional_order, and cancel_suggested_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Withdraw a PENDING order to authorize (suggested order) you proposed, so it can no longer be authorized or auto-executed. Only pending orders can be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The suggested order ID (from get_suggested_orders) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by explaining the consequence (the order cannot be authorized or auto-executed) and the state constraint (pending only), which also implicitly explains the non-idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler. The core action is front-loaded, with the consequence following and the state restriction last as a natural qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with full annotation coverage, the description supplies the action, the effect on downstream authorization/auto-execution, and the state precondition. No output schema exists, so return behavior is unspecified, which is a minor gap for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'id' parameter is documented there as the suggested order ID from get_suggested_orders. The description adds no format, sourcing, or semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Withdraw') and resource ('PENDING order to authorize (suggested order)') and clarifies what the operation prevents ('no longer be authorized or auto-executed'). The term 'suggested order' implicitly distinguishes it from the sibling cancel_broker_order and cancel_conditional_order, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Only pending orders can be cancelled' gives a meaningful precondition for successful use. However, it offers no routing guidance — an agent is not told when to prefer this over the sibling cancel tools or what to do for non-pending orders, leaving usage partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close an open position on a broker account. Can close the full position or a partial amount. Closing is immediate at market price. WARNING: This executes a real trade on the broker — closing on a "live" account will result in actual realized P&L. Closing or modifying positions does not consume daily credits.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | Quantity in lots to close. Omit or 0 for full close | |
| positionId | Yes | The position ID (from get_positions) | |
| brokerAccountId | Yes | The broker account ID (from get_positions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, openWorldHint=true and non-idempotency, but the description goes well beyond them: execution is immediate at market price, on a live account it produces real realized P&L, and closing/modifying consumes no daily credits. That is exactly the kind of consequence and cost context an agent needs before a write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by scope, execution semantics, and a clearly marked WARNING. Every sentence carries distinct, actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no output schema, the definition covers safety, execution model and cost implications thoroughly. It stops short of describing what the call returns (e.g., realized P&L or fill confirmation), which is the only meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so positionId, brokerAccountId and qty are already documented in the schema, including the omit/0 semantics for qty. The description only restates full-vs-partial at a high level, adding no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Close an open position on a broker account') and immediately scopes the operation ('full position or a partial amount'). An agent can distinguish it from modify_position and cancel_broker_order without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to use it (closing an open position, full or partial) and implicitly contrasts with 'modifying positions'. However, it never names an explicit alternative (e.g., modify_position for adjustments, cancel_broker_order for pending orders) or states when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an authorization URL to connect a cTrader broker account. The user must open the URL in their browser and authorize access. Once authorized, the cTrader account is automatically saved to TraderWAI. After connecting, use test_broker_account to verify it works.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Friendly name for this account (default "cTrader Account") | |
| environment | No | "demo" for paper trading, "live" for real money (default "demo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (non-read-only, open-world, non-idempotent, non-destructive), and the description adds genuinely new behavioral context: this is a two-step out-of-band OAuth flow requiring user browser action, and successful authorization automatically persists the account. That side effect and human-in-the-loop requirement are not derivable from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and immediately followed by the required user step and the verification step. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool, the description covers the action, the out-of-band user step, the persistence side effect, and the next step. It implies the return value (an authorization URL) without needing a schema, though it does not say what happens on failure or how long the URL remains valid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (label, environment) are already documented with defaults and enum meanings in the schema. The description adds no parameter-level detail such as how label is used or environment implications beyond what the schema states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: "Generate an authorization URL to connect a cTrader broker account." An agent can distinguish this from data-fetching siblings, and it names test_broker_account as the follow-up. It does not, however, differentiate itself from the similarly named create_broker_account, leaving that inference to the caller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: the user must open the returned URL in a browser and authorize, after which the account is saved. It also names the verification follow-up (test_broker_account). No explicit when-not or alternative tool (e.g. create_broker_account) is given, 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.
Connect a new broker account to TraderWAI (TradeLocker, Match-Trader, MetaTrader, DXtrade, Capital.com, Binance spot or Bybit USDT perpetuals). MetaTrader: each plan adds as many MetaTrader accounts every 30 days as it includes (Trader 1, Max 3); switching to another account sooner costs 3 USD (the user pays it in Settings → Brokers) or goes through support (hi@flex-in.org). So confirm the account number, master password and server with the user BEFORE adding it, and prefer the account they will really trade. A new password or server of the SAME account is free: use update_broker_account. For cTrader accounts, use the connect_ctrader tool instead (it uses OAuth). tastytrade (US futures, beta) cannot be added with this tool either: it is connected with the tastytrade login (OAuth) from the TraderWAI website (Settings → Broker accounts → Connect tastytrade); send the user there. The credentials are encrypted at rest and used only to authenticate with the broker for trade execution. After creating, use test_broker_account to verify the connection works. Available on all plans (FREE: 1, PLUS: 3, TRADER: 5, MAX: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Broker login email. MetaTrader: the account number (login). DXtrade: the platform username. Capital.com / Binance / Bybit: the API key. | ||
| label | Yes | Friendly name for this account (e.g. "My Demo Account") | |
| server | No | Not used for Binance or Bybit. Capital.com: the email the user logs in to Capital.com with. TradeLocker: the broker server name (e.g. "HEROFX"). Match-Trader: the URL of the broker's Match-Trader platform (e.g. "https://mtr.e8markets.com"; any page of it works). MetaTrader: the server name exactly as in MetaTrader (e.g. "HeroFX-Trade"). DXtrade: the web address of the broker's DXtrade platform (e.g. "https://trader.blueberrymarkets.com"), plus "#<domain>" only if the broker uses a domain other than "default". | |
| password | Yes | Broker login password. MetaTrader: the master password (the investor password only allows reading). Binance: the API secret (or the Ed25519 private key in PEM). Bybit: the API secret. Capital.com: the custom password chosen when generating the API key (not the Capital.com password). | |
| brokerType | No | Platform: "tradelocker" (default), "matchtrader", "metatrader", "dxtrade" (username + password + platform address; the broker must enable API access; beta), "capitalcom" (Capital.com's own platform; API key + its password + login email; the user enables two-factor authentication and generates the key in Capital.com → Settings → API integrations; environment "demo" = Capital.com demo account; beta), "binance" (spot; environment "demo" = Binance Spot Testnet) or "bybit" (USDT perpetuals; environment "demo" = Bybit Demo Trading). For Bybit the API key needs only «Contract → Orders & Positions» (never withdrawals), ideally restricted to IP 187.7.69.7. For Binance the user creates an API key with only «Spot & Margin trading» enabled (never withdrawals), ideally restricted to IP 187.7.69.7; suggest connecting it from the web (Settings → Broker accounts) rather than pasting the secret in the chat. For cTrader use the connect_ctrader tool. MetaTrader setup takes 1-3 minutes (check metaapiState with get_broker_accounts); Trader includes 1 MetaTrader account, Max 3. | |
| mtPlatform | No | MetaTrader only: "mt5" (default) or "mt4" | |
| environment | Yes | "demo" for paper trading, "live" for real money | |
| subAccountId | No | Optional, TradeLocker: which account of the login to use, by its id or accNum (test_broker_account lists them). One login can hold several accounts (e.g. accNum 1 and 4); without this the first one is used. To run separate strategies, create one connection per account with the same login and a different subAccountId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-readOnly, openWorld, non-idempotent, non-destructive operation, but the description adds substantial behavior context: plan limits, MetaTrader 30-day account-switch constraints and fees, encrypted credential storage, credential use limited to broker authentication, setup timing, API key permission requirements, IP restriction guidance, and beta status for DXtrade and Capital.com. Nothing contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and platforms, and nearly every sentence carries operational detail that matters for a complex multi-platform connection tool. It is long and dense, but the length is justified by the number of broker-specific caveats and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given eight parameters, full schema description coverage, no output schema, and multiple broker-specific edge cases, the description is complete enough to call the tool correctly. It covers supported platforms, plan limits, alternative tools for cTrader and tastytrade, pre-call confirmation, credential security, and post-call verification with test_broker_account.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; however, the description adds cross-parameter workflow meaning by requiring the agent to confirm the account number, master password, and server with the user before adding, and by preferring the account the user will actually trade. It also explains that a password or server change for the same account should use update_broker_account rather than this creation tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: connecting a new broker account to TraderWAI, and names the supported platforms. It explicitly distinguishes itself from update_broker_account, connect_ctrader, and tastytrade OAuth, so an agent can identify the correct tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance, including confirming credentials before adding, preferring the account the user will really trade, using update_broker_account for password/server changes to the same account, and redirecting cTrader and tastytrade users to their respective OAuth flows. It also says to verify with test_broker_account after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a rule-based conditional order that TraderWAI monitors every minute and fires ONCE when all conditions are met (pure algorithmic checks on price, candle closes and time — no AI involved). It can ENTER a trade or EXIT / manage an open position (close it, move its stop to break-even…), see EXITS below. Do NOT use this for immediate trades — use execute_trade for "buy now". Examples: "sell if an H1 candle closes below 1.0820", "buy if price crosses above 2350 between 08:00–16:00 UTC on weekdays", "sell gold if it sweeps the Asian session high at 4182 and an M15 candle closes back below" (sweep_above 4182, M15, then a market sell with the stop above the wick). "buy EUR_USD when price closes above the H1 EMA 50, only if price is above the D1 EMA 200" (close_above with level {"ref":"indicator","indicator":"ema","timeframe":"H1","period":50} + compare price above D1 EMA 200). "buy EUR_USD on the break and retest of today's 08:00-10:00 UTC range high" (retest {"level":{"ref":"range_high","start":"08:00","end":"10:00"},"direction":"up","timeframe":"M15","maxCandles":10}, market buy with stopAt {"type":"signal_extreme"} below the retest wick). "after an M15 close above today's 08:00-10:00 range high, leave a BUY LIMIT at that range high" (close_above with that level and action {"type":"limit","limitAt":{"type":"level","ref":{"ref":"range_high","start":"08:00","end":"10:00"}},"expiryMinutes":60}: the level is computed when the rule fires, optional limitAt.pips moves it up (+) or down (−)). PRICES: the rule is evaluated on the BROKER'S OWN PRICE of the account it trades (the first account in brokerConfigs; for exits, the position's account; for "suggest" without accounts, the account set for auto-execution of the symbol): real broker candles on MetaTrader and cTrader, the broker's live price on the other platforms. Each broker quotes slightly differently, so set levels from get_quote on that account, not from get_ohlc / get_chart (TraderWAI feed). If the broker does not answer, the rule falls back to the TraderWAI feed; get_conditional_order shows the source (lastPriceSource). Levels can be references (session high/low, previous day, indicators) that update every minute, and the same rule can be tested first with backtest_strategy. If your analysis needs judgement (patterns, divergences), translate it into concrete levels first. Action "execute" trades on the broker; "suggest" creates a suggested order for the user to confirm. IMPORTANT — a conditional order is NOT a limit order: TraderWAI waits for the conditions and then enters. How it enters is action.type: "market" (default) enters immediately at the broker price when the rule fires — for breakouts with an extra condition, or on platforms without pending STOP orders (Match-Trader, Binance). For a plain breakout on TradeLocker, cTrader or MetaTrader prefer execute_trade with executionType "STOP" (it waits at the broker). "limit" adds a second wait: after the rule fires it leaves a pending limit order at the broker, which only fills on a pullback to limitPrice (a retest entry). If the user just wants to wait for a price level with a pending order and no other condition, that is a plain LIMIT order with execute_trade, not a conditional order. Stop loss is required for entries. EXITS — WATCH AN OPEN POSITION: the same rules can MANAGE a position that is already open. Set action.type "close_position" (close it, or part of it with qty) or "modify_position" (move the stop loss to a price or to "break_even", or change the take profit), with brokerAccountId and positionId from get_positions. TraderWAI checks the rule every minute, around the clock, even when the user and you are away — so when the user asks you to "watch my trade and close it if…", create an exit rule instead of promising to check later yourself. Translate the idea into levels: e.g. "close my gold buy if there is a CHoCH on M15" → close_below the last higher low on M15 (take it from get_ohlc); "move the stop to break-even when it reaches 1R" → crosses_above entry + 1R with modify_position stopLoss "break_even". The position must be open when you create the rule; if it closes earlier (stop, target or manually) the rule is cancelled automatically. Exits do not use daily executions. Use the broker stop loss for instant price exits; exit rules are for structure, candle closes and time (checked once a minute on the broker's price). Entry orders last at most 24 hours from creation and exit rules at most 7 days, then expire. Active orders (entries and exits): Free 2, Plus 5, Trader 10, Max 30 (if the plan changes, the excess is cancelled).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Short descriptive name | |
| action | Yes | What to do when the conditions are met | |
| symbol | Yes | Trading symbol (e.g. EUR_USD). | |
| expiresAt | No | ISO 8601 expiration: entries at most 24h from now, exits at most 7 days (later values are capped). Omit for that maximum | |
| conditions | Yes | Conditions combined with AND (max 5; up to 8 when using level references, compare or candle_direction). At least one must be a price/candle condition or a compare with crosses_above/crosses_below. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide a basic safety profile, but the description adds substantial behavioral context: monitoring every minute, firing once, automatic cancellation when a position closes, entry order expiry of 24 hours, exit rule expiry of 7 days, active-order plan limits, and broker-price versus TraderWAI-feed fallback behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and most sentences carry needed nuance, but the description is a wall of text with many repeated examples and parenthetical explanations. For a tool this complex some length is warranted, but it would benefit from clearer structure and trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is highly detailed and there is no output schema, yet the description covers the missing operational context: entry versus exit behavior, required stop loss for entries, expiry caps, plan limits, auto-cancellation, broker price source, and fallback behavior. An agent has enough to call it correctly for both entry and exit use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline 3 is appropriate, but the description goes further by mapping natural-language trading ideas to concrete parameter shapes: action.type market/limit/close_position/modify_position, stopAt and limitAt relative references, level references, and examples such as range_high with start/end. It does not document every field, but it materially improves interpretation of the most important ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Create a rule-based conditional order') and immediately distinguishes it from immediate execution ('Do NOT use this for immediate trades — use execute_trade'). It also clarifies that it is not a limit order and names the sibling execution path for plain breakouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool versus alternatives: use execute_trade for 'buy now', use a plain LIMIT order when only waiting for a price level, and use backtest_strategy to test the same rule first. It also describes when to use action types market versus limit versus close_position/modify_position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an account group by name (the broker accounts themselves are not affected).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is carried there. The description adds genuinely non-obvious consequence information — that the broker accounts themselves survive the deletion — which is exactly the kind of blast-radius detail an agent needs before invoking a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb and target, with the scoping clarification placed where it matters. Nothing is padded and no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive delete with no output schema and annotations covering safety and idempotency, the description covers the essentials and the key side effect. It stops short of stating failure behavior when the name does not exist or what happens to accounts currently assigned to the group.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'name' parameter, so the schema already documents it. The description restates that deletion is keyed by name but adds no formatting, case-sensitivity, or matching nuance beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete an account group') and immediately scopes it by name, so the operation is unambiguous. The parenthetical separates it in practice from delete_broker_account, though it does so indirectly rather than naming the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Delete' tells the agent this is the removal counterpart to set_account_group/get_account_groups, but no when-to-use condition, prerequisites, or explicit alternative is stated. The agent must infer that a group must already exist and that this is distinct from deleting the accounts inside it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the per-symbol auto-execution configuration for a symbol. After this, suggested orders for that symbol are no longer auto-executed (they stay as suggestions for the user to review). To keep the config but pause it, use set_auto_execution_config with enabled=false instead.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading symbol whose auto-execution config to delete (e.g. EUR_USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral value the annotations cannot: the post-delete state is disclosed (orders stay as suggestions for review). It does not mention reversibility or whether the config is recoverable, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: action, consequence, and alternative, ordered by importance with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param destructive toggle with no output schema, the description covers what is removed, what happens to dependent behavior, and the safer sibling alternative. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, so the schema fully documents the symbol argument and the description adds nothing param-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with explicit scope ('per-symbol'), and the title reinforces the boundary. An agent can immediately distinguish this from set_auto_execution_config or delete_account_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the concrete alternative and the condition that selects it: use set_auto_execution_config with enabled=false to pause rather than delete. This is exactly the when-not guidance that prevents a destructive mistake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a broker account and all associated trade execution history. This cannot be undone. Any conditional orders using this account will need their broker configs updated. Consider setting isActive=false via update_broker_account instead. MetaTrader: deleting it does not free a new add: another MetaTrader account can be added 30 days after the last add, or sooner for 3 USD. To use a new password or server of the same account, use update_broker_account instead (free). Warn the user before deleting a MetaTrader account.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The broker account ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true and idempotentHint=false annotations, the description discloses irreversibility, the collateral deletion of trade history, downstream breakage of conditional orders, and a provider-specific cost/timing rule (30-day lockout or 3 USD). This is exactly the extra context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The most important fact — permanent, irreversible deletion — is front-loaded, and the MetaTrader caveats are genuinely useful. However, update_broker_account is recommended twice in close succession, which is slight redundancy in an otherwise dense but efficient paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with full annotation coverage and no output schema, nothing an agent needs to call it safely is missing: purpose, irreversibility, alternatives, and provider-specific gotchas are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (accountId) with 100% schema description coverage, so the schema fully documents it. The description adds no further semantics about the ID format or source (e.g., from get_broker_accounts), so it sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Permanently delete a broker account') and immediately scopes what else is removed ('all associated trade execution history'). It is clearly distinguishable from siblings like update_broker_account and cancel_broker_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit alternatives and the conditions selecting them: use isActive=false via update_broker_account for deactivation, and update_broker_account for password/server changes on the same account. It also names a prerequisite/knock-on effect (conditional orders' broker configs) and instructs the agent to warn the user for MetaTrader accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a conditional order. If the order is still active, it will be automatically cancelled instead of deleted (active orders cannot be permanently deleted). Only cancelled, expired, executed, or failed orders are permanently removed. Use cancel_conditional_order if you just want to stop monitoring without deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The conditional order ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds genuinely new behavioral context: active orders are auto-cancelled rather than deleted, and only cancelled/expired/executed/failed orders are permanently removed. This is exactly the kind of outcome nuance annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action, then the edge-case behavior, then the sibling routing. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with no output schema, the description covers the action, the conditional behavior, the state-dependent restriction, and the sibling alternative. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('The conditional order ID to delete'), so the schema fully carries parameter meaning. The description adds no syntax, format, or sourcing detail beyond it, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Delete a conditional order') and immediately distinguishes it from the sibling cancel_conditional_order by name. An agent can tell exactly what this tool does versus closely-named alternatives without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative ('Use cancel_conditional_order if you just want to stop monitoring without deleting') and gives the condition that selects it. It also explains the fallback behavior when deletion isn't possible, so the agent knows what to expect in that edge case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YOU CAN DRAW ON CHARTS WITH THIS TOOL. draw_chart renders YOUR technical analysis on a real TraderWAI candlestick chart and returns the image, so the user sees it right in the chat. Use it EVERY time you want to show something visually: support/resistance levels, supply/demand zones, trendlines and channels, candle markers (sweeps, rejections, signals), labels (HH, HL, BOS, CHoCH…), Fibonacci, chart patterns, measurements, the expected path and the trade plan (entry, stop loss, targets with R). You decide what to mark; TraderWAI draws it with the exact candles and prices. NEVER create chart images yourself (code, matplotlib, image generation) and NEVER edit or redraw TraderWAI chart images (they are © TraderWAI): call draw_chart instead. HOW: 1) get_chart to see the market; 2) get_ohlc for the candle open times (UTC) and exact prices; 3) draw_chart with up to 30 marks. Identify candles by their OPEN TIME in UTC, ISO format (never by position: new candles arrive every minute), and anchor a price to a candle with "high"/"low" when the level is that candle's extreme. Use "until" (the last candle you analysed) to freeze the chart at that moment. Invalid marks are skipped and explained in the reply: fix them and call again. Call it again whenever you want to change or add marks. Example: {"symbol":"XAU_USD","timeframe":"H1","marks":[{"type":"zone","high":4160,"low":4152,"from":"2026-10-15T09:00:00Z","extend":true,"label":"Supply","tone":"bearish"},{"type":"hline","price":"low","from":"2026-10-15T05:00:00Z","label":"Support","tone":"bullish"},{"type":"position","side":"short","entry":4148,"stop_loss":4162,"take_profit":[4130,4110]}]}. Free plan: 5 marked charts per day (looking at charts with get_chart is always unlimited); Plus, Trader and Max: unlimited.
| Name | Required | Description | Default |
|---|---|---|---|
| marks | Yes | What to draw | |
| until | No | Optional: draw the chart only up to this candle time (UTC ISO), e.g. the last candle you analysed | |
| symbol | Yes | Symbol (e.g. XAU_USD, NAS100_USD, EUR_USD). | |
| timeframe | Yes | Chart timeframe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the 30-mark cap, that invalid marks are skipped and explained in the reply (fix-and-retry loop), that 'until' freezes the chart, that new candles arrive every minute so positions shift, and the exact daily quota per plan tier. The readOnlyHint is consistent — it renders an image without persisting state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and then organized into a numbered HOW sequence plus a concrete example, so it is easy to scan. It is on the long side with heavy capitalization and some repetition of the NEVER-draw-it-yourself rule, which costs a point but does not obscure the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description states the tool returns a rendered image visible to the user, covers the constraint layer (quota, invalid-mark handling, candle-time identification), and supplies an example. An agent has everything needed to invoke it correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description still adds crucial semantics: identify candles by UTC open time in ISO format and never by index, use "high"/"low" to anchor to a candle extreme, and use "until" for the last analysed candle. It also provides a full worked example payload showing zone, hline and position marks together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it renders technical-analysis marks on a TraderWAI candlestick chart and returns the image into the chat. This is immediately distinguishable from siblings like get_chart (view market) and get_ohlc (fetch candle data), which the description references as prerequisite steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit workflow (1: get_chart, 2: get_ohlc, 3: draw_chart), lists the mark categories it is meant for, and names the alternatives it forbids (writing code/matplotlib or image generation, editing TraderWAI images). It even states when to call it again to modify marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading symbol in TraderWAI format (e.g. "EUR_USD", "XAU_USD", "NAS100_USD", "BTC_USD") | |
| quantity | No | Position size in lots (e.g. 0.01 = micro lot, 0.1 = mini lot, 1.0 = standard lot). Required unless using percentage sizing. | |
| stopLoss | Yes | Stop loss price level (absolute price, not pips). The trade will be closed at a loss if price reaches this level. | |
| trailing | No | 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. | |
| orderType | Yes | Trade direction: "LONG" for buy, "SHORT" for sell | |
| entryPrice | No | Required for LIMIT and STOP orders: the price where the pending order triggers. Ignored for MARKET orders. | |
| sizingMode | No | How to determine position size. "fixed_lots" (default): use the quantity field directly. "percentage": risk a % of account balance (requires sizingValue). | |
| takeProfit | Yes | Take profit price level (absolute price, not pips). The trade will be closed at a profit if price reaches this level. | |
| sizingValue | No | 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. | |
| executionType | Yes | "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". | |
| brokerAccountId | Yes | ID of the broker account to trade on. Use get_broker_accounts to list available accounts. | |
| confirmHighRisk | No | Only after the user explicitly confirmed a percentage risk above 10% per order. |
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.
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.
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.
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.
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.
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.
Place the SAME immediate order on several broker accounts at once (multi-account: Plus, Trader and Max): either an account group (accountGroup, see get_account_groups) or a list of brokerAccountIds. Groups can define the size per account (e.g. 0.5% risk on a prop firm account and 1 lot on a personal one); otherwise the quantity/sizing of this call is used for every account. Each account is checked against its own risk limits and uses 1 daily execution. For a single account use execute_trade.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading symbol in TraderWAI format (e.g. "EUR_USD", "XAU_USD") | |
| quantity | No | Lots for accounts without their own sizing in the group | |
| stopLoss | Yes | Stop loss price (absolute) | |
| orderType | Yes | "LONG" for buy, "SHORT" for sell | |
| entryPrice | No | Required for LIMIT and STOP orders | |
| sizingMode | No | Sizing for accounts without their own sizing | |
| takeProfit | Yes | Take profit price (absolute) | |
| sizingValue | No | When sizingMode="percentage", the % of each account balance LOST if the stop loss is hit (not the share of the balance used). Above 10 requires confirmHighRisk. | |
| accountGroup | No | Name of an account group (get_account_groups). Use this or brokerAccountIds. | |
| executionType | Yes | "MARKET" fills now; "LIMIT" = pending pullback order at each broker (BUY LIMIT below the ask, SELL LIMIT above the bid); "STOP" = pending breakout order (BUY STOP above the ask, SELL STOP below the bid), only on TradeLocker, cTrader, MetaTrader, Capital.com and Bybit — accounts on other platforms return an error, use create_conditional_order for them. | |
| confirmHighRisk | No | Only after the user explicitly confirmed a percentage risk above 10% per order (tell them the total across accounts). | |
| brokerAccountIds | No | IDs of the broker accounts (get_broker_accounts). Use this or accountGroup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true and non-idempotent=true already declared, the description still adds real value: per-account risk-limit checks, consumption of one daily execution per account, the confirmHighRisk gate above 10%, and the platform restriction on STOP orders. What it does not disclose is failure semantics when only some accounts succeed, which matters a great deal for a fan-out write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, then the account-selection mechanism, then the caveats. Dense but every clause carries information; the one blemish is calling it an 'immediate order' while later supporting LIMIT and STOP pending orders, which reads slightly inconsistent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter destructive write with no output schema, the description covers the selection, sizing, risk-gating and platform-constraint dimensions well. The remaining gap is the return/partial-failure story — an agent cannot tell whether a multi-account call returns per-account results or aborts on first failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: quantity/sizingValue apply only to accounts lacking their own group sizing, and sizingValue is the percent of balance lost at the stop rather than capital deployed. That resolves the most likely misreading of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (place the same order on several broker accounts) and immediately names the distinguishing scope: multi-account versus single. It explicitly routes to execute_trade for the single-account case, which is the exact sibling an agent would confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete selection criteria: use accountGroup or brokerAccountIds, use execute_trade for one account, and use create_conditional_order for STOP orders on unsupported platforms. It also explains what happens when the group has no per-account sizing (the call's quantity/sizing applies). Little 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.
List the user's broker account groups (for execute_trade_multi), with each member account and its optional per-account sizing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful return-shape context — that each group includes its member accounts plus optional per-account sizing — which matters since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the core purpose is front-loaded before the downstream-use hint. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description covers purpose, downstream use, and return contents adequately. It does not state response format or whether sizing fields can be absent per account, but those are minor for this shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema describes an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the user's broker account groups') and even names the return contents — member accounts and per-account sizing. An agent can distinguish this from set_account_group and delete_account_group without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(for execute_trade_multi)' ties the tool to the downstream call that consumes the group names, which is clear usage context. It stops short of an explicit 'call this before execute_trade_multi' instruction or of naming when a plain account lookup (get_broker_accounts) would suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's TraderWAI plan, today's order executions used/remaining, and plan limits (broker accounts, conditional orders, auto-execution, multi-account, risk limits, results history) with current usage, plus which plan to upgrade to. Check it before a multi-step task that could hit a limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds that the tool reports consumption counters against limits, which is mildly useful context, but discloses nothing about auth requirements, freshness/caching of the usage numbers, or rate limits. With annotations carrying the main burden, this is a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in a single dense sentence with the when-to-use trigger following it; no sentence is filler. The parenthetical enumeration of limit categories is long but each item earns its place by telling the agent what limits it can rely on this tool to surface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden, and it does: it lists plan, per-day execution counters, and every limit category with current usage, plus the upgrade recommendation. Combined with the annotations, an agent has everything needed to decide to call it and what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-parameter schema is 4. The description correctly implies a no-argument call by never referencing any input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource and enumerates exactly what is returned: plan, today's executions used/remaining, plan limits, and upgrade target. It is unmistakably a read-only account snapshot. However, it never differentiates itself from siblings that overlap its content, notably get_risk_limits, get_trade_results, and get_upgrade_url, leaving the agent to infer why this aggregate view exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Check it before a multi-step task that could hit a limit" gives a concrete usage trigger that tells the agent when to call this versus just proceeding. It stops short of naming alternatives or exclusions (e.g., use get_risk_limits for detailed risk data), so it is clear context without routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's per-symbol auto-execution configuration plus the global on/off switch. When auto-execution is ENABLED for a symbol, TraderWAI automatically executes suggested orders (created via suggest_order) for that symbol on the configured broker account(s) — no manual review needed. Read-only. Returns { globalEnabled, configs: [{ symbol, enabled, brokerConfigs, maxPerDay, skipIfOpenPosition }] }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower; the description's 'Read-only' merely echoes them. The genuine value-add is the domain behavior it discloses: that an ENABLED symbol causes TraderWAI to auto-execute suggested orders without manual review, which tells the agent the stakes of what it is reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource, followed by the meaning of the flag and the return shape. Three sentences with minimal waste; the inline return-shape object is justified because no output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters, no output schema, and safety already covered by annotations, the description supplies the missing pieces: what the flag controls and the exact return fields (globalEnabled, configs with symbol/enabled/brokerConfigs/maxPerDay/skipIfOpenPosition). Adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. The description correctly adds no parameter detail because there is nothing to document, and instead documents the response shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (per-symbol auto-execution configuration plus global switch), and the sibling names set_auto_execution_config / delete_auto_execution_config make the read-only scope unambiguous. An agent can distinguish this from the setters and deleters without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the returned configuration means and links it to suggest_order, which implies when an agent would care. However, it never states explicitly when to call this versus get_suggested_orders or the sibling set_/delete_ tools, and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all broker accounts connected by the user. Each account represents a connection to a trading broker (e.g. TradeLocker). Returns: account ID, label, environment (demo/live), broker type, server, active status, last connection time, any connection errors, and capabilities: what that trading platform supports (order types, partial close, closed-trade history, broker-reported P/L, commissions…; true = supported, false = not available, "planned" = coming). Credentials (email/password) are never returned. Use test_broker_account to verify a connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive behavior, so the description's extra value is in the private-data guarantee ('Credentials are never returned') and the meaning of the capability tri-state (true/false/'planned'). It does not cover auth requirements or rate limits, but the disclosure of what is and is not exposed adds real context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the rest is dense but information-bearing. The long capability parenthetical is the only heavy passage, and it earns its place by defining the tri-state values, though it could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of documenting the return shape, and it enumerates the fields (account ID, label, environment, broker type, server, status, last connection, errors, capabilities) precisely. Combined with the credential exclusion and sibling routing, an agent has everything needed to select and interpret this call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all broker accounts connected by the user') and clarifies what one unit represents ('a connection to a trading broker'). It is clearly distinguishable from sibling tools like create_broker_account or get_broker_account_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes verification to the sibling ('Use test_broker_account to verify a connection'), giving a clear when-to-use-this-vs-alternative signal. It lacks explicit when-not conditions or prerequisites, but the guidance is concrete rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current trading state of a broker account including real-time balance, equity, free margin, used margin, leverage, and currency. This connects to the broker in real-time — it may take a few seconds. Use this to check available margin before placing trades or to monitor account health.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The broker account ID (from get_broker_accounts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds real value beyond them by disclosing the real-time broker round-trip and its latency ('may take a few seconds'), which an agent needs before calling it in a hot path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each doing distinct work: what it returns, the latency trait, and when to use it. The returned-field enumeration is front-loaded and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by naming the fields. It also covers latency and usage. Minor gap: no mention of failure modes such as an invalid accountId or an unreachable broker for a live-connection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and the schema already documents it at 100% coverage, including its provenance ('from get_broker_accounts'). The description adds no further parameter meaning, so the baseline 3 for schema-covered parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get the current trading state of a broker account) and enumerates the exact fields returned: balance, equity, free margin, used margin, leverage, currency. That enumeration implicitly separates it from the list-style sibling get_broker_accounts, though it does not explicitly distinguish itself from get_account_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use context: 'check available margin before placing trades or to monitor account health.' This is a genuine workflow cue tied to sibling tools like execute_trade. It stops short of naming those siblings or stating exclusions, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a pre-rendered candlestick chart image for a trading symbol and timeframe (candles, day and session separators and the last price; no indicators are drawn). USE IT TO SEE THE PICTURE: market structure (higher highs / lower lows), trend and channels, ranges and compressions, chart patterns (flags, wedges, triangles, head and shoulders, double tops), liquidity sweeps, fair value gaps, and price versus the indicators. Patterns and context are much easier to spot in the image than in a list of numbers, so start an analysis with the chart (higher timeframe first, then the entry timeframe). Do NOT read exact prices from the image: take entry, stop loss and take profit levels from get_ohlc, and the broker's live price from get_quote. Each image is heavy: use it for context, not on every message. Charts are updated every minute from the TraderWAI market feed, which can differ slightly from the user's broker (use get_quote for the broker's exact bid/ask). The image is © TraderWAI: do not edit or redraw it, and do not generate chart images yourself. To DRAW levels, zones, trendlines, patterns or a trade setup on the chart for the user, call draw_chart (you decide the marks, TraderWAI draws them on the real candles).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD). | |
| timeframe | Yes | Chart timeframe: M1, M5, M15, H1, H4, or D. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, open-world, and non-destructive behavior, but the description adds important context about what the image contains, that no indicators are drawn, that charts update every minute from the TraderWAI feed, and that the feed may differ from the user's broker. It also discloses image weight and copyright/redraw restrictions, which materially affects how an agent should use the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, and nearly every sentence carries actionable guidance. It is somewhat long due to the list of visual patterns and multiple usage warnings, but the length is largely justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return value, and it does: a pre-rendered candlestick chart image with candles, separators, and last price but no indicators. It also covers update cadence, data-source caveats, and the related drawing workflow, leaving little ambiguity for an agent calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the symbol and timeframe parameters. The description adds usage context around timeframes, but it does not add parameter syntax or format details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns a pre-rendered candlestick chart image for a symbol and timeframe. It also distinguishes itself from nearby tools such as get_ohlc, get_quote, and draw_chart, so an agent can tell what this tool uniquely provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use the chart for visual market structure and context, starting with a higher timeframe and then the entry timeframe. It also gives clear exclusions: do not read exact prices from the image, use get_ohlc and get_quote instead, avoid using it on every message, and call draw_chart when the user wants levels or setups drawn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a conditional order: its rule-based conditions, action (execute/suggest, side, SL/TP, broker configs), status, the latest evaluation state (ruleState.lastResults shows which conditions are currently met; ruleState.lastPriceSource: the decision is always taken on the TraderWAI feed candles, the same ones backtest_strategy uses; "broker_candles" / "broker_quote" = the broker of brokerAccountId provides the live price and a stable offset = broker − feed, used to convert fixed levels to the feed scale and gaps/stops/prices to the broker scale for execution; "feed" = no broker price, with the reason), ruleState.evalLog (the last 30 evaluations: time, broker price, feed price, offset and each condition; for an unmet FVG, "nearest" shows the latest gap, the edge to touch and how far price has reached since) and its recent checks/trigger results. Use this to understand why an order has or hasn't fired yet. Orders with engine "ai" are legacy free-text orders that were retired.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The conditional order ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the readOnly/destructive profile, and the description layers substantial extra context on top: that evalLog holds only the last 30 evaluations, exactly what each eval row contains, and how price source ('broker_candles'/'broker_quote' vs 'feed') and the broker−feed offset drive evaluation. It also flags that engine 'ai' orders are retired, which an agent could not infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear 'Get a conditional order:' opener, and most clauses carry real information. But the body is one sprawling sentence with deeply nested parentheses and semicolon chains, which makes it hard to parse for a consuming agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of explaining the return shape and does so thoroughly: ruleState.lastResults, ruleState.lastPriceSource, ruleState.evalLog contents, and recent checks/trigger results, including FVG 'nearest' semantics. An agent has enough to interpret the response without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single orderId param is a plain number, so the schema does the work; the description adds nothing about the ID itself. It does reference brokerAccountId, which is not actually a parameter of this tool, a mild source of confusion rather than added param meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Get') plus resource ('conditional order') with the scope of what is returned enumerated: conditions, action, status, evaluation state, checks. The closing use-case line ('understand why an order has or hasn't fired yet') separates it from the list sibling get_conditional_orders without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case for diagnosis of why an order fired or not, which is real guidance. However, it never names an alternative sibling (get_conditional_orders, run_conditional_order, update_conditional_order) or states a when-not condition, so the routing guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's conditional orders. Conditional orders are rule-based (no AI): TraderWAI checks price, candle-close and time conditions every minute and fires the action once when all are met. Status can be: active (monitoring), executed (fired), expired, cancelled, or failed. Returns paginated results with the conditions summary, action and status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20, max 100) | |
| offset | No | Pagination offset (default 0) | |
| status | No | Filter by order status: active, executed, expired, cancelled, failed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds real domain context beyond that: the one-minute polling cadence, the fire-once semantics of conditional orders, and the meaning of each lifecycle status. It still omits ordering, retention, and any rate/volume limits on a polling-backed list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action, then mechanism, status glossary, and return shape. No filler; each sentence removes a plausible ambiguity for an agent choosing between the many order tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly supplies the return shape (paginated results containing conditions summary, action, status), and the safety profile is carried by annotations. Pagination controls are documented in the schema, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (limit default 20/max 100, offset default 0, enum-style status list), so the baseline is 3. The description enriches only two of the five status values ('active (monitoring)', 'executed (fired)'), which is a marginal addition over the schema's own list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'List the user's conditional orders' gives a specific verb+resource, and the plural plus the follow-up explanation of rule-based monitoring clearly separates it from the singular get_conditional_order and from mutators like create_conditional_order or run_conditional_order. It does not explicitly name those siblings, so it falls short of the 5-level routing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never states when to call this versus get_conditional_order (single order), get_suggested_orders, or run_conditional_order. Usage is only implied by the tool name; there are no exclusions, prerequisites, or alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market structure of a symbol at a moment, as TraderWAI's rule engine sees it (closed candles only, no look-ahead): confirmed swings, the last break of structure (BOS / CHoCH), trend by structure (higher highs and lows / lower highs and lows), the last impulse with its Fibonacci levels and the live zones (order blocks, flip zones = broken bases, Fibonacci 0.5-0.618 zone, fair value gaps, equal highs/lows) with how many times price has visited each. Use it to explain a past date ("why did the backtest enter here?"), to check that the detection matches the user's chart before trusting a structure backtest, or to pick concrete levels for an analysis. at = an ISO time (default now). Pure calculation on TraderWAI's market feed, no AI.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ISO 8601 time to look at (default now): what was known at the close of the last candle before it | |
| symbol | Yes | Symbol (e.g. XAU_USD, EUR_USD, NAS100_USD) | |
| strength | No | Candles on each side of a swing (1-10, default 3; the same parameter as in the rules) | |
| timeframe | Yes | Structure timeframe | |
| minSwingAtr | No | Ignore swings that stand out less than this × ATR(14) (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/destructive annotations by disclosing the decisive behavioral traits: closed candles only, no look-ahead, pure deterministic calculation on TraderWAI's market feed with no AI involved. It also explains that each zone carries a visit count, which tells the agent what the numbers mean. These caveats are exactly what an agent needs to trust or qualify results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the resource and its returned contents, then pivots to usage scenarios, which is a sensible order. The single dense opening sentence and the schema-duplicating 'at = an ISO time (default now)' clause are minor waste but don't obscure the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description enumerates the return payload (swings, BOS/CHoCH, trend, impulse, Fibonacci, zones with visit counts) and the closed-candle/no-look-ahead semantics that determine how those values should be read. That is sufficient for an agent to call and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents symbol, timeframe, at, strength, and minSwingAtr. The description only restates the `at` parameter ('an ISO time, default now'), which duplicates the schema, and adds nothing about strength or minSwingAtr beyond it. Baseline 3 applies when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('market structure of a symbol at a moment') and enumerates exactly what it computes: confirmed swings, last BOS/CHoCH, trend by structure, last impulse with Fibonacci levels, and live zones with visit counts. This clearly separates it from siblings like get_ohlc or get_chart, which return raw data rather than derived structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete usage scenarios: explaining a past date ('why did the backtest enter here?'), validating that detection matches the user's chart before trusting a structure backtest, and picking concrete levels for analysis. It lacks an explicit when-not or a named alternative (e.g. get_ohlc for raw candles), which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw OHLC (Open, High, Low, Close) candlestick data as numerical arrays for a trading symbol and timeframe. Returns exact price values — use it for anything that needs precise numbers: exact support/resistance levels, indicator calculations, swing highs/lows, and entry, stop loss and take profit placement. For visual reading (structure, trend, chart patterns, liquidity sweeps) look at get_chart first: patterns are easier to see in the image, then confirm the exact levels here. Data comes from the TraderWAI market feed, updated every minute: it is the same for every user and can differ slightly from the prices of the user's broker. For the exact current price at a broker (bid/ask), use get_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of time range. ISO 8601 (e.g. "2026-04-19T00:00:00Z") or unix seconds. Only candles at or before this time are included. | |
| from | No | Start of time range. ISO 8601 (e.g. "2026-04-01T00:00:00Z") or unix seconds. Only candles at or after this time are included. How far back you can go depends on the plan (Free: last 14 days, Plus: 6 months, Trader: 1 year, Max: all history, 2 years); the latest candles (without from/to) are available on every plan. | |
| limit | No | Number of candles to return (default 100, max 500). Returns the most recent candles within the time range. | |
| symbol | Yes | Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD, NAS100_USD). | |
| timeframe | Yes | Candle timeframe: M1, M5, M15, M30, H1, H2, H4, H6, H8, H12, or D. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/destructive annotations, it discloses the data source (TraderWAI market feed), the one-minute refresh cadence, that data is identical for all users, and that it may differ from the user's broker prices — real operational context that prevents misuse. It stops short of describing the returned array structure or ordering, which matters since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core definition, then routing guidance, then data provenance — a logical order with no filler. The use-case sentence is a slightly long list and 'Returns exact price values' overlaps with 'use it for anything that needs precise numbers', costing a little tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless-in-prose read tool with full schema coverage and no output schema, the description covers purpose, alternatives, provenance, freshness, and the broker-vs-feed caveat. The only residual gap, exact array shape, is minor and partly implied by 'numerical arrays'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so symbol, timeframe, from, to and limit are already fully documented, including plan-based history limits and the 500-candle cap. The description adds no parameter-level detail beyond naming symbol and timeframe, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (raw OHLC candlestick data as numerical arrays) plus the scope (symbol + timeframe), and explicitly separates itself from get_chart and get_quote. An agent can identify the tool and its niche from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use-case rule — anything needing precise numbers (levels, indicator math, swing points, stop/target placement) — and names the two alternatives with their conditions: get_chart for visual/pattern reading, get_quote for broker bid/ask. Also documents plan-dependent history limits in the schema, so an agent knows when it may fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all open positions and pending orders across all of the user's connected broker accounts. Positions are live trades currently in the market. Pending orders are limit/stop orders waiting to be filled. Each position includes: symbol, side (buy/sell), quantity, average entry price, unrealized P&L, stop loss (price + dollar amount), take profit (price + dollar amount), open date, broker account label, environment (demo/live), and linked conditional order info if applicable. To WATCH a position and close it or move its stop when something happens (a candle close, a CHoCH, a level, a time), create an exit rule with create_conditional_order (action.type close_position / modify_position, with this position id): TraderWAI checks it every minute. Each pending order includes: symbol, side, type (limit/stop), quantity, target price, SL/TP levels, and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds real context beyond that: the scope spans all connected broker accounts, and it describes the conditional-order linkage and that TraderWAI evaluates exit rules every minute. No rate limits or pagination behavior are mentioned, but this is solid added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded in the first sentence, and the field enumerations earn their place because there is no output schema. The two long field lists are somewhat dense, but they carry information not available elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query with no output schema, the description supplies what the agent actually needs: the two result categories, their field contents, and where to go to act on a position. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. The description correctly implies a parameterless call ('all ... across all of the user's connected broker accounts') and introduces no parameter vocabulary that would conflict with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get all open positions and pending orders') plus the scope ('across all of the user's connected broker accounts'), and it defines both entities so the agent can distinguish it from get_conditional_orders, get_suggested_orders, and get_broker_account_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context (live trades vs. waiting limit/stop orders) and explicitly routes the 'watch a position' use case to create_conditional_order with the position id. It does not state exclusions (e.g., when to prefer account-state or conditional-order endpoints instead), so it falls short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the CURRENT price (bid and ask) of a symbol directly from the broker of one of the user's accounts. This is the price that account actually trades at: market orders fill at it (buy at the ask, sell at the bid) and its stop loss / take profit trigger on it.
Two price sources exist in TraderWAI:
get_ohlc / get_chart: TraderWAI market feed. Same for everyone, with history, for analysis. It can differ slightly from each broker (spread, feed and timing).
get_quote: the broker's own live price for one account. No history.
WHEN TO USE EACH: analyzing → get_ohlc / get_chart. Placing or proposing an order → get_quote first, every time. Rules for orders:
Never take entry, stop loss or take profit levels from the feed price: compute them from this bid/ask (a market BUY fills at the ask, a market SELL at the bid).
A BUY LIMIT must be below the ask and a SELL LIMIT above the bid. On the wrong side the broker fills it immediately at market (or rejects it). If the level the user asked for is on the wrong side, do not send the order: explain it and ask what they meant.
BUY STOP above the ask, SELL STOP below the bid (breakout entries; execute_trade with executionType "STOP" on TradeLocker, cTrader, MetaTrader, Capital.com, Bybit and tastytrade; elsewhere create_conditional_order).
The stop loss of a BUY must be below the bid and the take profit above it (the reverse for a SELL).
There is no single "current price": each broker account has its own. Quote the account you are going to trade; if the user has several accounts and did not say which, ask or quote each one.
Supported on TradeLocker, cTrader, Match-Trader, MetaTrader 4/5, Capital.com, Binance spot, Bybit and tastytrade (futures, *_FUT symbols) accounts. On a platform without live broker prices it returns an error: then use get_ohlc as a reference. The response also includes the latest TraderWAI feed price (traderwaiFeedPrice) so you can see the difference. It connects to the broker in real time and may take a few seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Symbol in TraderWAI format (e.g. "EUR_USD", "XAU_USD", "NAS100_USD"); it is mapped to the broker's own symbol name. | |
| brokerAccountId | Yes | The broker account ID (from get_broker_accounts). Prices can differ between brokers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/non-destructive; the description adds substantial context beyond that: real-time broker connection latency ("may take a few seconds"), failure behavior on unsupported platforms, the platform support list, the fact that prices are per-account rather than global, and that the response includes traderwaiFeedPrice for comparison. No contradiction with the read-only annotation — the order rules are guidance for downstream tools, not claims that this tool mutates anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the feed-vs-broker distinction is laid out before the order rules, so structure is strong. It runs long for a two-parameter read tool, and the detailed LIMIT/STOP/stop-loss level rules arguably belong with execute_trade, but they are decision-critical to avoid misfired orders.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only quote tool with no output schema, the description covers what it returns (bid/ask plus traderwaiFeedPrice), latency, error cases, per-account variability, and platform coverage — everything an agent needs to call it and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents both symbol and brokerAccountId, so the description is not required to carry the load. It still adds meaning beyond the schema by emphasizing that prices differ per broker account and that the agent must resolve which account to quote when the user has several — a semantic constraint not visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get the CURRENT price (bid and ask) of a symbol directly from the broker") and immediately disambiguates from the two sibling feed tools (get_ohlc / get_chart) by contrasting feed vs broker scope. An agent can pick it apart from get_ohlc/get_chart 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit decision rule ("analyzing → get_ohlc / get_chart. Placing or proposing an order → get_quote first, every time") plus conditional alternatives for platforms without live prices ("it returns an error: then use get_ohlc as a reference") and for multi-account ambiguity ("if the user has several accounts and did not say which, ask or quote each one"). This goes well beyond what could be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the risk limits the user set for each broker account (e.g. prop firm rules): max lots per order, max open positions, max trades per day, max daily loss, max risk per trade, max drawdown (static or trailing), allowed trading hours (UTC) and allowed/blocked symbols. Every order is checked against them before it is placed; a blocked order fails with "RISK_LIMIT". Check them before proposing or executing trades so your orders fit. Read-only: only the user can change them on the TraderWAI website. "level" is what the plan enforces (none / basic / full); "inactiveRules" are saved but not enforced on the current plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description goes beyond them with enforcement behavior: every order is validated before placement and a blocked order fails with 'RISK_LIMIT', plus the plan-dependent semantics of 'level' and 'inactiveRules' (saved but not enforced). This is meaningful context an annotation cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and its fields, then enforcement behavior, then the read-only caveat. Dense and largely waste-free, though 'Every order is checked against them before it is placed' and 'Check them before proposing or executing trades so your orders fit' partially overlap in intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining the return shape and does so by enumerating the rule categories plus the 'level' and 'inactiveRules' fields. For a zero-parameter read tool this is complete enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description adds no parameter detail because none exist, but it does explain the meaning of returned fields like 'level' and 'inactiveRules', which is useful even though it is not strictly parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (risk limits per broker account) and enumerates the exact rules returned: max lots per order, max open positions, max trades per day, max daily loss, max risk per trade, max drawdown, allowed hours, and symbol allow/block lists. No sibling tool touches risk limits, so the agent can separate this from get_broker_accounts or get_account_info immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit directive: 'Check them before proposing or executing trades so your orders fit.' It also closes off the obvious alternative path by stating the limits are read-only and can only be changed by the user on the TraderWAI website, so the agent knows there is no set/modify counterpart to reach for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the orders to authorize (suggested orders) you or another AI proposed to the user, with their status. Status values: PENDING (waiting for the user's authorization, or for auto-execution if the user enabled it for that symbol), EXECUTING (being placed), EXECUTED (authorized by the user or by their auto-execution rule), EXPIRED, CANCELLED (rejected), FAILED, or CLOSED. Read-only. Returns paginated results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 50, max 100) | |
| offset | No | Pagination offset (default 0) | |
| status | No | Filter by status (PENDING, EXECUTED, EXPIRED, CANCELLED, FAILED, CLOSED) | |
| symbol | No | Filter by symbol (e.g. EUR_USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes well beyond that by defining the full status lifecycle (PENDING with auto-execution nuance, EXECUTING, EXECUTED, EXPIRED, CANCELLED labelled as rejected, FAILED, CLOSED) and noting paginated results, which is genuine domain context an agent needs to interpret output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and scope are front-loaded in the first clause, and the status glossary earns its length because no enum is defined in the schema. The list is dense but no sentence is pure filler; only the trailing 'Read-only' repeats an annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully supplies the status vocabulary and pagination behavior, and annotations carry the safety profile. It stops short of describing result ordering, default filtering behavior, or what fields each order record contains, which would round out a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, offset, status, and symbol are already documented in the schema; the description adds no filter syntax, defaults, or combination guidance. The status-value glossary indirectly helps interpret the status filter, but that is marginal added value over the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the orders to authorize (suggested orders)') and adds the crucial scope that these are orders proposed by an AI to the user, which distinguishes it from get_conditional_orders or the broker-order siblings. The alias 'suggested orders' also links it to suggest_order and cancel_suggested_order so an agent can place it correctly in the lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when you'd call it — checking the authorization status of AI-proposed orders — but never states when to use it versus alternatives such as get_conditional_orders or cancel_suggested_order, and gives no exclusions or prerequisites. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Results of the user's CLOSED trades executed through TraderWAI: real entry and exit price, how it closed (tp / sl / manual), realized P/L in money and in R (multiples of the risk to the stop loss), plus a summary (total P/L, wins, losses, average R). Use it to review performance, learn from past trades and report results to the user. Set onlyMine=true to see only the trades you (this AI connection) placed. Availability depends on the broker (see capabilities.closedTradesHistory in get_broker_accounts); results update a few minutes after a position closes. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back period in days (default 30, max 365) | |
| limit | No | Max trades to return (default 50, max 200) | |
| symbol | No | Filter by symbol (e.g. EUR_USD) | |
| onlyMine | No | Only trades placed by this AI connection (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's safety burden is light, but it adds real operational context: broker-dependent availability, a propagation delay (results update a few minutes after close), and the semantics of onlyMine. It does not describe pagination or return shape constraints, but the added traits are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what is returned, then usage, then the onlyMine hint, then availability/latency caveats. Dense but well ordered; the return-value enumeration is long yet earns its place given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and the summary block, plus broker availability and refresh latency. An agent has everything needed to call and to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so days/limit/symbol/onlyMine are already documented in the schema. The description restates onlyMine's meaning (already in the schema) and adds no format or default detail beyond it. Baseline 3 applies when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource (results of CLOSED trades executed through TraderWAI) and enumerates the returned fields (entry/exit price, close reason, realized P/L in money and R, summary). This clearly distinguishes it from get_positions (open) and execute_trade siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it: review performance, learn from past trades, report results to the user. It also points to get_broker_accounts for availability. It stops short of naming when NOT to use it or which sibling to prefer for related queries, so it is clear but not fully routing-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Stripe checkout URL to upgrade the user's TraderWAI plan. Plans: FREE (1 broker account, 5 executions/day, 1 new conditional order/day, 2-week backtests); PLUS (3 accounts, 25 executions/day, auto-execution, 5 new conditional orders/day, 6-month backtests, no MetaTrader); TRADER (5 accounts, unlimited executions, auto-execution, 10 conditional orders, 1 MetaTrader account, 1-year backtests); MAX (10 accounts, 30 conditional orders, full risk limits, 3 MetaTrader accounts, all history). No free trials: the first month of any monthly plan is 50% off for a first subscription. Monthly and yearly billing (yearly is cheaper). Returns a URL the user must open to pay, with the price and any discount. If the user already pays, the result has changePlan=true: it is a prorated change of the same subscription (unused days of the current plan are credited; preview.amountDue is charged today, or nothing during a trial) and url is the pricing page where the user confirms it. Downgrades are done by the user on the pricing page.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | The target plan to upgrade to (PLUS only when it is on sale: the plan-limit messages say which plan to offer) | |
| interval | No | Billing period (default month) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint/openWorldHint; the description adds far more: the return value is a URL the user must open to pay, the first month is 50% off for a first subscription, no free trials, and re-subscribing users get changePlan=true with a prorated charge (preview.amountDue today, nothing during a trial). This is exactly the mutation-adjacent behavior an agent would otherwise not anticipate from a 'read only' tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the return-value contract are front-loaded, and no sentence is pure filler. The parenthetical plan feature lists are lengthy and only marginally useful for calling the tool correctly, which keeps it out of the top band.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description covers the return shape (url plus price and discount, changePlan flag, preview.amountDue), the billing model, and the trial edge case. Nothing an agent needs to call it and explain the result to a user is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are enums with their own descriptions, so the baseline is 3. The description adds plan-limit detail and the 'yearly is cheaper' hint for interval, but it does not clarify parameter formats beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Get'), a concrete artifact ('Stripe checkout URL'), and the exact resource ('upgrade the user's TraderWAI plan'). No sibling tool in the list does anything similar, so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes when this is appropriate (upgrading the plan) and explicitly excludes an adjacent flow: 'Downgrades are done by the user on the pricing page.' It also tells the agent when PLUS is valid ('only when it is on sale: the plan-limit messages say which plan to offer'), though it never states the trigger condition in user terms, e.g. that the user must ask to upgrade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available trading symbols with their display name and category. Optionally filter by category (forex, commodities, indices, futures, crypto). Futures are CFDs that track the CME/Eurex future (NQ, ES, YM, FDAX, CL, BZ, GC): use them for charts and backtests; orders go through the user's own platform.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category: forex, commodities, indices, futures, crypto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds domain behavior not present in structured fields: that futures entries are CFDs tracking CME/Eurex contracts and that orders must go through the user's own platform. Return shape is only sketched (display name, category) and pagination/ordering is unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and return fields in the first sentence, with the filter and futures caveat following in descending importance. Three sentences with little waste, though the futures/CFD explainer is arguably domain trivia that could live in a related trading tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional-param read-only lister with annotations covering safety and no output schema, the description says what comes back and what filtering is possible. What an agent still doesn't know — ordering, whether results are large enough to need paging — is minor for this tool class.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's description already lists the exact category values, so the description merely repeats 'forex, commodities, indices, futures, crypto'. No format, casing, or default behavior is added beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all available trading symbols') and even names the returned fields (display name, category), making the resource unmistakable versus siblings like list_timeframes or get_quote. It doesn't explicitly contrast itself with any sibling, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The futures note ('use them for charts and backtests; orders go through the user's own platform') is real usage guidance for one category, and the optional category filter is described. However, there is no explicit when-to-use framing relative to alternatives (e.g., calling this before backtest_strategy or execute_trade to resolve symbol names), so routing is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available chart timeframes with their label and candle window description.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and non-destructive, so the safety profile is covered. The description adds useful behavioral context that annotations omit: the returned contents (each timeframe's label and candle-window description), which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every clause (label, candle window) earns its place by describing returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param read-only enumeration with no output schema, the description adequately conveys what will be returned. It could be complete with one clarifying note on ordering or whether the set is fixed, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no semantics to clarify and the baseline is 4. The description correctly implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('chart timeframes') and even hints at the return shape ('label and candle window description'). An agent can distinguish it from the only other enumeration sibling, list_symbols, by resource, though the description does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no named alternative. Usage is largely self-evident for a zero-parameter enumeration tool, but the description itself contributes nothing here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a pending order (limit/stop order waiting to be filled) on a broker account. You can change the entry price, quantity, stop loss, and/or take profit. At least one field must be provided. All price values are absolute levels. Use this when the user wants to move a limit order to a different price, change lot size, or adjust SL/TP on a pending order. Binance does not allow modifying pending orders: there, cancel it with cancel_broker_order and place a new one.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | No | New quantity in lots (e.g. change from 0.5 to 1.0 lots) | |
| price | No | New entry price for the limit/stop order (e.g. move limit buy from 1.0800 to 1.0750) | |
| orderId | Yes | The pending order ID (from get_positions) | |
| stopLoss | No | New stop loss price level | |
| takeProfit | No | New take profit price level | |
| brokerAccountId | Yes | The broker account ID (from get_positions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the 'at least one field must be provided' precondition, that prices are absolute levels rather than deltas, and the broker-specific restriction that Binance requires cancel-and-replace. It does not state what the call returns or whether the order ID is preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each doing distinct work: what it is, what you can change, the validation constraint, and the broker exception. Front-loaded with the core action and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with full schema coverage and annotations that carry the safety profile, the definition supplies preconditions, price semantics, and the key broker exception. The only gap is the absence of any statement about the outcome of a successful modification (e.g., new order ID, whether the order is re-queued), with no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description earns above baseline by clarifying that price values are absolute levels (not offsets or percentages), a semantic distinction the schema descriptions ('New entry price', 'New stop loss price level') do not make explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Modify a pending order') and immediately disambiguates scope by defining a pending order as a limit/stop order waiting to be filled, separating it from modify_position. It also enumerates the mutable fields, so an agent knows exactly what this tool covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger scenarios ('move a limit order to a different price, change lot size, or adjust SL/TP on a pending order') and names a concrete alternative path for a broker that does not support it, routing to cancel_broker_order plus a new order. This is textbook when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify the stop loss and/or take profit of an open position on a broker account. Use this to adjust risk management on existing trades. At least one of stopLoss or takeProfit must be provided. Values are absolute price levels (e.g. stopLoss: 1.0950, not a pip distance). Setting stopLoss to the position's avgPrice performs a "break even" — moving SL to entry to eliminate risk.
| Name | Required | Description | Default |
|---|---|---|---|
| stopLoss | No | New stop loss price level (absolute price, e.g. 1.0950) | |
| positionId | Yes | The position ID (from get_positions) | |
| takeProfit | No | New take profit price level (absolute price, e.g. 1.1100) | |
| brokerAccountId | Yes | The broker account ID (from get_positions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds behavior the annotations cannot: at least one of stopLoss/takeProfit must be supplied, values are absolute price levels rather than pip distances, and setting SL to avgPrice yields break-even. It does not say whether the change is reversible or what happens if the position is already closed, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, zero filler, purpose front-loaded before the constraint and the unit convention. Each sentence carries a distinct piece of information the agent needs to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive live-trading mutation with no output schema and full schema coverage, the description supplies the critical constraint and value semantics. It stops short of describing the response or failure modes (e.g. invalid price, closed position), which would be the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description contributes real meaning beyond the schema: the cross-parameter constraint "at least one of stopLoss or takeProfit must be provided" (absent from the schema's required list) and the absolute-price-level semantics with a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (modify) plus the exact resource and field scope: stop loss and/or take profit of an OPEN POSITION, which cleanly separates it from the order-modification siblings (modify_broker_order, update_conditional_order). An agent can tell what it does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this to adjust risk management on existing trades" gives a clear context for invocation, and the break-even note tells the agent one concrete scenario. However, no alternatives or exclusions are named (e.g. use close_position instead, or modify_broker_order for pending orders), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run: evaluate a rule-based conditional order right now against the latest market data. It does NOT execute anything — the order still fires on its own during the scheduled one-minute checks. Returns each condition with met true/false, wouldTrigger, and the current price.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The conditional order ID to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description asserts 'It does NOT execute anything,' i.e. a harmless read/dry-run, while annotations declare readOnlyHint=false and destructiveHint=true on a non-idempotent operation. This is a direct conflict that could cause an agent to call a state-changing tool believing it is side-effect free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the 'Dry-run' framing and the key negative ('does NOT execute anything') placed early. The return-value sentence is informative but slightly crowds the entry.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description usefully discloses the return shape (each condition with met true/false, wouldTrigger, current price) and the interaction with the scheduled checks. It is let down only by failing to reconcile its no-op claim with the destructive annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required orderId parameter already documented as 'The conditional order ID to analyze.' The description adds no syntax, format, or constraint detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('evaluate a rule-based conditional order right now') and immediately frames it as a dry-run, which cleanly separates it from siblings like get_conditional_order (fetch), create_conditional_order (create), and execute_trade (execute).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the context for using it — check conditions now against the latest market data rather than waiting for the scheduled one-minute checks — which gives an agent a clear trigger. It does not, however, name an alternative tool or state an explicit when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update (by name) a group of 2+ broker accounts to trade together with execute_trade_multi (all plans). Each member can have its own sizing: sizingMode "percentage" (sizingValue = % of the balance LOST if the stop is hit, typically 0.25-2; above 10 needs confirmHighRisk after the user confirms) or "fixed_lots". Confirm the accounts and sizes with the user before saving.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name, e.g. "Prop firms" | |
| members | Yes | Accounts in the group (at least 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, destructive=false, openWorld=true. The description adds genuinely new behavior: the risk gate where sizingValue above 10 requires confirmHighRisk "after the user confirms," and a mandatory user-confirmation step before saving. It does not explain what happens to existing members on an update, which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then sizing semantics, then the confirmation requirement. Dense but every sentence carries operational information; the parenthetical about percentage risk is essential rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of explaining the upsert behavior, sizing model, and the high-risk confirmation flow — enough for an agent to call it correctly. Minor omissions remain (update/replace semantics for existing members, error cases), but nothing blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the top-level params, but the nested sizing fields carry no schema descriptions, and the description fills that gap precisely: sizingMode enum meanings, sizingValue as "% of the balance LOST if the stop is hit, typically 0.25-2," and the confirmHighRisk threshold. Only brokerAccountId sourcing is left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Create or update ... a group of 2+ broker accounts") and pins down the upsert key ("by name"). It also names the downstream consumer (execute_trade_multi) and implicitly separates itself from get_account_groups and delete_account_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for when to use it: grouping 2+ broker accounts to trade together, available on all plans, with an explicit precondition ("Confirm the accounts and sizes with the user before saving"). It does not explicitly name the read/delete siblings as alternatives, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure per-symbol auto-execution. When enabled for a symbol, TraderWAI's backend automatically executes suggested orders (from suggest_order) for that symbol on the chosen broker account(s) — the user does not have to review them. This is the same configuration available on the TraderWAI website. Creates or updates the config for the given symbol. Get broker account IDs with get_broker_accounts. Note: the take profit always comes from each suggestion, not from this config. Requires the global auto-execution switch to also be ON (see set_global_auto_execution).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Trading symbol (e.g. EUR_USD). | |
| enabled | Yes | Enable (true) or disable (false) auto-execution of suggested orders for this symbol | |
| maxPerDay | No | Safety cap: max number of auto-executions per day for this symbol | |
| brokerConfigs | No | Broker account(s) where orders are auto-executed. Required when enabling. | |
| skipIfOpenPosition | No | If true (default), do not open a new order when a position already exists for the symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag mutation, destructiveness, open-world behavior, and non-idempotency; the description adds critical behavioral context beyond that, including that orders may execute without user review, that take profit comes from each suggestion rather than this config, and that a global switch is a prerequisite. Nothing contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds only material caveats: auto-execution behavior, global prerequisite, broker account lookup, and take-profit source. Each sentence contributes to correct invocation or risk understanding, with no obvious filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive per-symbol configuration mutation, the description covers the key operational context: what it configures, that it creates or updates, the global prerequisite, where broker IDs come from, and the important take-profit caveat. Given the fully documented schema and rich annotations, an agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so parameter meaning is already fully documented. The description adds useful context around broker accounts and the global switch prerequisite, but it does not add parameter-level detail beyond what the schema already supplies, making 3 the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: configuring per-symbol auto-execution. It explains what activation does (backend auto-executes suggested orders without user review) and distinguishes this per-symbol config from the sibling global auto-execution switch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: enabling causes auto-execution on chosen broker accounts, broker IDs come from get_broker_accounts, and the global auto-execution switch must also be ON via set_global_auto_execution. It does not explicitly state when not to use this tool or contrast it directly with delete/get config siblings, so it falls short of full 5-level routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Master on/off switch for ALL auto-execution. When OFF, TraderWAI does not auto-execute any suggested order for any symbol, regardless of per-symbol config (a kill-switch). When ON, per-symbol configs apply. Use this to pause or resume all auto-execution at once without touching per-symbol settings.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | true = allow auto-execution (per-symbol configs apply), false = pause all auto-execution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by explaining the actual semantics of the switch: OFF overrides per-symbol config entirely (kill-switch), ON defers to per-symbol configs. That is real behavioral context not encoded in destructiveHint/openWorldHint. It does not address idempotency or the effect on already-pending suggested orders, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place, with the master-scope claim and the kill-switch consequence front-loaded before the usage guidance. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema toggle, the description covers scope, precedence over per-symbol config, and intended usage. The only gap is behavior toward in-flight or pending suggested orders when the switch flips off, which an agent might reasonably need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single boolean parameter is fully documented in the schema itself, so the baseline is 3. The description reinforces the meaning of the flag by describing the downstream consequence (all symbols blocked vs. per-symbol rules apply), but adds no syntax or format detail beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Master on/off switch for ALL auto-execution') and immediately scopes it against per-symbol config, which is exactly the distinction needed versus sibling set_auto_execution_config. An agent can tell it apart from the per-symbol tool 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case ('Use this to pause or resume all auto-execution at once without touching per-symbol settings'), which routes the agent away from per-symbol configuration. The alternative is described functionally rather than named as a sibling tool, so it stops just 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.
PROPOSE a trade for the user to authorize, instead of placing it yourself. You never move the user's money with this tool: you only create an "order to authorize" (entry, stop loss, take profit, expiration) and the USER authorizes its execution. Use it whenever you should not or cannot place trades directly — e.g. your policy does not allow executing real-money trades, or the user wants to review first. (To place an order directly and immediately, when allowed and requested, use execute_trade.) Get the broker's current price with get_quote first and compute entry, stop loss and take profit from it (a SELL LIMIT above the bid, a BUY LIMIT below the ask). For breakout entries use create_conditional_order.
What happens next depends on the user's own settings in TraderWAI: (1) No auto-execution for this symbol: TraderWAI notifies the user (email / browser) and the order waits in "Orders to authorize" until they authorize it, reject it, or it expires. Nothing is executed without their action. (2) The user enabled auto-execution for this symbol: TraderWAI executes it on their broker following the rules the user configured (account, size, daily limits), and notifies them.
Tell the user which case applies if you know it, and remind them they can automate a symbol from the notification. Provide concrete price levels as full numbers (e.g. 1.09542 / 95432.50) and an expiration. Available on all plans.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Brief trade rationale shown to the user | |
| source | No | Identifier of the AI making the suggestion (e.g. "claude", "fable") | |
| symbol | Yes | Trading symbol (e.g. EUR_USD). | |
| stopLoss | Yes | Stop loss price level (full price, no abbreviations) | |
| expiresAt | No | Absolute ISO 8601 expiration (overrides expiresInHours) | |
| orderType | Yes | LONG = buy, SHORT = sell | |
| confidence | No | Confidence 0-100 | |
| entryPrice | No | Reference/expected entry price (current market price for MARKET) | |
| limitPrice | No | Required for LIMIT orders: the desired entry price level | |
| takeProfit | Yes | Take profit price level (full price, no abbreviations) | |
| executionType | Yes | MARKET = at current price, LIMIT = at a specific price | |
| expiresInHours | No | Hours until the suggestion expires (1-72, default 24). Ignored if expiresAt is set | |
| riskRewardRatio | No | Computed risk:reward ratio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it explains the authorization flow, notification behavior, expiry, and user-configurable auto-execution. The phrase 'you never move the user's money' is slightly overbroad because case 2 can execute on the broker, but the description immediately qualifies that behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and alternatives are front-loaded, and the numbered case breakdown is structured and useful for explaining auto-execution. It is somewhat long and repeats the user-authorization idea, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema, the description covers the critical decision context and post-call behavior, including both authorization and auto-execution paths. An agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds practical semantics: compute entry, stop loss, and take profit from get_quote; use SELL LIMIT above the bid and BUY LIMIT below the ask; provide full numbers and an expiration. It does not elaborate on notes, source, confidence, or riskRewardRatio, though those are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource: 'PROPOSE a trade for the user to authorize, instead of placing it yourself.' It explicitly contrasts this with execute_trade and create_conditional_order, so an agent can distinguish it from sibling order-placement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states explicit conditions for use: when policy forbids real-money execution or the user wants to review first. It also names the alternative for direct placement and the sibling for breakout entries, and gives a required pre-step to call get_quote before computing price levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the connection to a broker account by attempting to authenticate and retrieve the list of trading sub-accounts. Returns success with available accounts if connection works, or an error message if it fails. Use this after creating or updating credentials to verify.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The broker account ID to test |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds real value beyond that by disclosing the return behavior: it yields available sub-accounts on success or an error message on failure. It does not mention auth failure modes or rate limits, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it does, what it returns, and when to use it. The core purpose is front-loaded and every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly compensates by describing the success and failure return shapes. Combined with 100% schema coverage on the sole parameter and annotations covering the safety profile, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single accountId parameter is documented in the schema, so the schema carries the burden. The description adds no syntax or format detail beyond what is already structured; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (test) and resource (broker account connection), and explains the mechanism: authenticate and retrieve trading sub-accounts. This clearly separates it from data-fetch siblings like get_broker_accounts, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this after creating or updating credentials to verify" gives a concrete triggering condition, which is genuinely useful next-step guidance. It stops short of naming alternatives (e.g., connect_ctrader) or stating when not to use it, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a broker account configuration. Can change label, environment, credentials, server, active status, or (TradeLocker) which account of the login it uses (subAccountId). Setting isActive to false disables the account for trade execution without deleting it. MetaTrader: a new password or server of the same account is updated for free (it reconnects in about a minute); a different account number (email = new login, with password and server) switches to another account, which counts as an add (every 30 days per plan account, or 3 USD).
| Name | Required | Description | Default |
|---|---|---|---|
| No | New broker login email | ||
| label | No | New friendly name | |
| server | No | New broker server | |
| isActive | No | Enable/disable account. false = disabled, true = active | |
| password | No | New broker login password | |
| accountId | Yes | The broker account ID to update | |
| environment | No | New environment | |
| subAccountId | No | TradeLocker: switch this connection to another account of the same login, by its id or accNum (test_broker_account lists them; the one in use is marked usedByThisConnection). Empty string = back to the first account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and non-idempotency, and the description adds real operational context on top: reconnects take ~1 minute, credential/server changes are free, but a different account number counts as an add billed every 30 days or 3 USD. That cost/side-effect disclosure is exactly the kind of thing an agent can't get from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then grouped by scenario (disable, MetaTrader free vs paid). Dense but every clause carries operational meaning; the parenthetical pricing/billing detail is slightly compressed but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter destructive mutation with no output schema and full schema coverage, the description covers cost, reconnect timing, and the disable-vs-delete distinction. It doesn't state whether unspecified fields are left untouched or that accountId must reference an existing account, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a 3 is the floor; the description earns above that by explaining the interaction between parameters — that email effectively defines a new login and only becomes a paid account switch when combined with password and server. subAccountId semantics are repeated from the schema, limiting the upside.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Update a broker account configuration") and enumerates what is mutable: label, environment, credentials, server, active status, subAccountId. This clearly separates it from create_broker_account/delete_broker_account/get_broker_accounts, though those siblings are never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies alternatives through concrete conditions: "Setting isActive to false disables the account for trade execution without deleting it" steers the agent away from delete_broker_account when it only wants to suspend trading. The MetaTrader paragraph explains when an update becomes a paid add versus a free reconnect. No explicit when-not guidance or named sibling routing, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an active rule-based conditional order. Fields not sent keep their current value; "conditions" replaces the whole list, "action" is merged field by field (sending a different action.type replaces the whole action, e.g. turning a close_position exit into a modify_position). The symbol cannot be changed (cancel and create a new order instead).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New short descriptive name | |
| action | No | Fields of the action to change | |
| orderId | Yes | The conditional order ID to update | |
| expiresAt | No | New expiration (ISO 8601). Never later than 24h after the order was created (exit rules: 7 days); null resets to that maximum | |
| conditions | No | Conditions combined with AND (max 5; up to 8 when using level references, compare or candle_direction). At least one must be a price/candle condition or a compare with crosses_above/crosses_below. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: omitted fields persist, "conditions" replaces the whole list, "action" merges field-by-field, and a changed action.type wipes the prior action — exactly the kind of silent-destruction detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, zero filler, with the merge rules front-loaded ahead of the constraint about symbols. Every sentence conveys actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with a very deep nested schema, the description covers the hardest thing to infer (patch semantics per field). It omits whether updating re-arms a triggered rule, the 24h/7-day expiry interaction, and what the response contains, but the schema and annotations carry most of that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline would be 3, but the description adds merge/replace semantics for the two object parameters that the schema cannot express (partial patch vs full replacement). It does not restate orderId or expiresAt behavior, which the schema already handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Update an active rule-based conditional order") and scopes it to active orders. It is clearly separable from create_conditional_order, cancel_conditional_order, and get_conditional_order in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent away from an unsupported use case: "The symbol cannot be changed (cancel and create a new order instead)" names the alternative path. It stops short of naming sibling tools directly or saying when to prefer update over cancel+recreate for other fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_ohlc1 field changedInput schema / properties / from / descriptionPrevious value: -"Start of time range. ISO 8601 (e.g. \"2026-04-01T00:00:00Z\") or unix seconds. Only candles at or after this time are included. How far back you can go depends on the plan (Free: last 7 days, Trader: 90 days, Max: all history); the latest candles (without from/to) are available on every plan."New value: +"Start of time range. ISO 8601 (e.g. \"2026-04-01T00:00:00Z\") or unix seconds. Only candles at or after this time are included. How far back you can go depends on the plan (Free: last 14 days, Plus: 6 months, Trader: 1 year, Max: all history, 2 years); the latest candles (without from/to) are available on every plan."backtest_strategy34 fields changedInput schema / properties / conditions / items / properties / baseCandlesAdded value: +{
+ "description": "flip_zone: minimum candles of the base (2-20, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / baseRangeAtrAdded value: +{
+ "description": "flip_zone: maximum range of the base in ATR(14) (0.2-5, default 1)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / confirmStrengthAdded value: +{
+ "description": "trigger \"choch\": swing strength on the confirmTimeframe (1-10, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / confirmTimeframeAdded value: +{
+ "description": "zone/confluence with trigger close/rejection (default the zone timeframe) or choch (required, lower than the zone timeframe)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / fromAdded value: +{
+ "description": "fib_zone: lower retracement level (default 0.5)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- },
- "timezone": {
- "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "direction": {
+ "description": "ref \"fib\": only if the last impulse goes this way (default any)",
+ "enum": [
+ "bullish",
+ "bearish",
+ "any"
+ ],
+ "type": "string"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "description": "ref \"fib\": the Fibonacci level (e.g. 0.618, 1, -0.27)",
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "description": "ref \"fib\": only impulses of at least this × ATR(14)",
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "description": "swing_high/swing_low/fib: ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+ },
+ "nth": {
+ "description": "swing_high/swing_low: 1 = the last confirmed swing (default), 2 = the one before…",
+ "type": "integer"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "description": "Daily references, indicators, price, or MARKET STRUCTURE (M5-D1, closed candles only, no look-ahead): swing_high / swing_low = the last confirmed swing high/low (nth 2 = the one before…; a swing is a high/low with `strength` candles on each side, default 3, confirmed when those candles close); fib = a Fibonacci level of the LAST IMPULSE (the move between the last two opposite swings), measured from its end: 0.5 / 0.618 / 0.786 retracements, 1 = the impulse start, -0.27 / -0.618 = extensions beyond its end (targets).",
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price",
+ "swing_high",
+ "swing_low",
+ "fib"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "strength": {
+ "description": "swing_high/swing_low/fib: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe; swing_high/swing_low/fib: structure timeframe (M5-D1)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / maxAgeCandlesAdded value: +{
+ "description": "zone: only zones created in the last N candles of its timeframe (1-500, default 50)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / maxTouchesAdded value: +{
+ "description": "zone/confluence: 1 = first retest only (default), 2 = up to the second visit… (1-10)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minAdded value: +{
+ "description": "confluence: how many zones must overlap (default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minCountAdded value: +{
+ "description": "equal_highs/equal_lows: swings needed (2-5, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minImpulseAtrAdded value: +{
+ "description": "bos/choch/order_block/fib_zone: minimum size of the impulse (displacement) in ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minOverlapPipsAdded value: +{
+ "description": "confluence: minimum height of the overlap in pips (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minSwingAtrAdded value: +{
+ "description": "Ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / patternAdded value: +{
+ "description": "candle_pattern and trigger \"rejection\": pin_bar, engulfing or any (default)",
+ "enum": [
+ "pin_bar",
+ "engulfing",
+ "any"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / shift / descriptionPrevious value: -"candle_direction: 1 = last closed candle (default), 2 = the one before…"New value: +"candle_direction / candle_pattern: 1 = last closed candle (default), 2 = the one before…"Input schema / properties / conditions / items / properties / strengthAdded value: +{
+ "description": "bos/choch/structure_trend/order_block/fib_zone/equal_*: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / toAdded value: +{
+ "description": "fib_zone: upper retracement level (default 0.618)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / tolerancePips / descriptionPrevious value: -"retest: how close to the level (in pips) counts as a retest (default 0)"New value: +"retest: how close to the level (in pips) counts as a retest (default 0); equal_highs/equal_lows: max distance between the swings (default 0.1 × ATR)"Input schema / properties / conditions / items / properties / trigger / descriptionPrevious value: -"fvg_retest: touch = enter as soon as price reaches the gap (default); close = when the candle that returns to the gap closes"New value: +"fvg_retest: touch (default) or close. zone/confluence: touch (default), close, rejection or choch"Input schema / properties / conditions / items / properties / trigger / enumPrevious value: -[
- "touch",
- "close"
-]New value: +[
+ "touch",
+ "close",
+ "rejection",
+ "choch"
+]Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, fvg_formed = a new gap just formed (pair it with a limit entry in the gap), time_window, days_of_week, retest {level, direction up|down, timeframe, maxCandles, tolerancePips} = break and retest of a level: a candle closes beyond the level (breakout), then within maxCandles candles (1-50, default 10) the first candle that comes back to it (within tolerancePips, default 0) and closes on the breakout side fires at its close; a close back inside before that cancels the breakout) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."New value: +"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, fvg_formed = a new gap just formed (pair it with a limit entry in the gap), time_window, days_of_week, retest {level, direction up|down, timeframe, maxCandles, tolerancePips} = break and retest of a level: a candle closes beyond the level (breakout), then within maxCandles candles (1-50, default 10) the first candle that comes back to it (within tolerancePips, default 0) and closes on the breakout side fires at its close; a close back inside before that cancels the breakout) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". MARKET STRUCTURE (M5-D1, closed candles, no look-ahead; a swing = a high/low with `strength` candles on each side, default 3, known when those candles close): bos {timeframe, direction bullish|bearish, maxCandles, minImpulseAtr} = filter: the last break of structure (a close beyond the last swing) was in that direction within maxCandles candles (default 20); choch = the same but it reversed the previous break (change of character); structure_trend {timeframe, direction} = higher highs and higher lows (bullish) / lower highs and lower lows (bearish); candle_pattern {timeframe, pattern pin_bar|engulfing|any, direction, shift} = the last closed candle is a rejection candle. zone {zone, timeframe, direction, trigger, …} = ENTRY TRIGGER when price comes back to a live zone: zone order_block (last opposite candle before the impulse that broke structure; minImpulseAtr for displacement), flip_zone (a base of baseCandles+ candles within baseRangeAtr × ATR, default 3 and 1, broken by a close: broken support becomes resistance and vice versa), fib_zone (between the from/to retracements of the LAST impulse, default 0.5-0.618; OTE 0.62-0.79), fvg (fair value gap), equal_highs / equal_lows (2+ swing highs/lows within tolerancePips, default 0.1 × ATR: liquidity). A zone dies when a candle closes beyond it; maxAgeCandles (default 50) = how recent; maxTouches (default 1) = first retest only, 2 = up to the second visit… trigger: touch (default: the minute price reaches it), close (a confirmTimeframe candle touches it and closes back outside), rejection (same, with a pin bar / engulfing candle), choch (a CHoCH on a LOWER confirmTimeframe while price is in the zone: multi-timeframe entry). confluence {direction, zones:[{zone, timeframe, …}, …] (2-4), min (default 2), minOverlapPips, trigger…} = ENTRY TRIGGER at the OVERLAP of at least `min` live zones (the entry zone is their intersection; results are broken down by combination). The zone of the trigger is used by stop/limit \"zone\" (stop beyond its far edge, limit at its near edge / midpoint / far edge)."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction",
- "retest"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction",
+ "retest",
+ "bos",
+ "choch",
+ "structure_trend",
+ "zone",
+ "confluence",
+ "candle_pattern"
+]Input schema / properties / conditions / items / properties / zoneAdded value: +{
+ "description": "zone: the zone kind",
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / zonesAdded value: +{
+ "description": "confluence: 2-4 zones, e.g. [{\"zone\":\"order_block\",\"timeframe\":\"M15\"},{\"zone\":\"flip_zone\",\"timeframe\":\"M15\"},{\"zone\":\"fib_zone\",\"timeframe\":\"M15\",\"from\":0.5,\"to\":0.618}]",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "baseCandles": {
+ "type": "integer"
+ },
+ "baseRangeAtr": {
+ "type": "number"
+ },
+ "from": {
+ "type": "number"
+ },
+ "maxAgeCandles": {
+ "type": "integer"
+ },
+ "minCount": {
+ "type": "integer"
+ },
+ "minGap": {
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "type": "number"
+ },
+ "strength": {
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "to": {
+ "type": "number"
+ },
+ "tolerancePips": {
+ "type": "number"
+ },
+ "zone": {
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "zone",
+ "timeframe"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / sensitivityAdded value: +{
+ "description": "true: also run the rule with neighbouring parameters (swing strength ±1 for structure conditions, target ±0.5R) and report each result, to check it is not fitted to the past",
+ "type": "boolean"
+}Input schema / properties / trade / properties / entry / properties / at / properties / point / descriptionPrevious value: -"type \"fvg\": near edge, midpoint (default) or far edge"New value: +"type \"fvg\" / \"zone\": near edge, midpoint (default) or far edge"Input schema / properties / trade / properties / entry / properties / at / properties / type / descriptionPrevious value: -"offset: N pips better than the signal price; price: fixed; level: a reference (Asian low, EMA…); fvg: inside the gap of an fvg condition"New value: +"offset: N pips better than the signal price; price: fixed; level: a reference (Asian low, EMA, Fibonacci level…); fvg: inside the gap of an fvg condition; zone: inside the zone of a zone/confluence condition"Input schema / properties / trade / properties / entry / properties / at / properties / type / enumPrevious value: -[
- "offset",
- "price",
- "level",
- "fvg"
-]New value: +[
+ "offset",
+ "price",
+ "level",
+ "fvg",
+ "zone"
+]Input schema / properties / trade / properties / management / descriptionPrevious value: -"Trade management while open: break-even and partial closes (checked after the stop on each 1-minute candle: worst case)"New value: +"Trade management while open: break-even and partial closes (checked after the stop on each 1-minute candle: worst case) and exits by price behaviour (no progress, compression). The same exits exist on live conditional orders (action.exitIfNoProgress / exitOnCompression)"Input schema / properties / trade / properties / management / properties / exitIfNoProgressAdded value: +{
+ "additionalProperties": false,
+ "description": "Close at the close of the candle when price has made no new high (buy) / low (sell) for N closed candles of that timeframe since entry, e.g. {\"candles\":6,\"timeframe\":\"M5\"}",
+ "properties": {
+ "candles": {
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe"
+ ],
+ "type": "object"
+}Input schema / properties / trade / properties / management / properties / exitOnCompressionAdded value: +{
+ "additionalProperties": false,
+ "description": "Close when the last N closed candles span less than maxRangeAtr × ATR(14) of that timeframe (price accumulating instead of moving), e.g. {\"candles\":6,\"timeframe\":\"M5\",\"maxRangeAtr\":0.8}",
+ "properties": {
+ "candles": {
+ "type": "integer"
+ },
+ "maxRangeAtr": {
+ "type": "number"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe",
+ "maxRangeAtr"
+ ],
+ "type": "object"
+}Input schema / properties / trade / properties / stop / properties / edge / descriptionPrevious value: -"type \"fvg\": far edge (default; below a bullish gap / above a bearish gap), near edge, midpoint, or pattern = beyond the low/high of the three candles that form the gap"New value: +"type \"fvg\" / \"zone\": far edge (default; below a bullish zone / above a bearish zone), near edge, midpoint, or pattern = beyond the low/high of the three candles that form the gap (fvg)"Input schema / properties / trade / properties / stop / properties / type / descriptionPrevious value: -"pips: distance from entry; price: fixed price; level: a reference (the Asian low, an EMA…); wick: beyond the sweep wick (or the trigger candle extreme); atr: multiple × ATR from the entry; fvg: at an edge of the gap of the fvg_retest/fvg_formed condition (edge far by default) plus bufferPips"New value: +"pips: distance from entry; price: fixed price; level: a reference (the Asian low, an EMA, the last swing high…); wick: beyond the sweep wick (or the trigger / confirmation candle extreme); atr: multiple × ATR from the entry; fvg: at an edge of the gap of the fvg_retest/fvg_formed condition (edge far by default) plus bufferPips; zone: at an edge of the zone of the zone/confluence condition (edge far by default) plus bufferPips"Input schema / properties / trade / properties / stop / properties / type / enumPrevious value: -[
- "pips",
- "price",
- "level",
- "wick",
- "atr",
- "fvg"
-]New value: +[
+ "pips",
+ "price",
+ "level",
+ "wick",
+ "atr",
+ "fvg",
+ "zone"
+]create_conditional_order35 fields changedInput schema / properties / action / properties / exitIfNoProgressAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries with mode \"execute\": close the position at the close of the candle when price has made no new high (buy) / low (sell) for N closed candles since entry. Same rule as backtest_strategy trade.management.exitIfNoProgress",
+ "properties": {
+ "candles": {
+ "description": "Candles without a new extreme in favour (1-100)",
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / exitOnCompressionAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries with mode \"execute\": close the position when price compresses (accumulates) instead of moving. Same rule as backtest_strategy",
+ "properties": {
+ "candles": {
+ "description": "Last N closed candles (2-100)",
+ "type": "integer"
+ },
+ "maxRangeAtr": {
+ "description": "Close when their total range is below this × ATR(14) of that timeframe (e.g. 0.8)",
+ "type": "number"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe",
+ "maxRangeAtr"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / limitAt / properties / point / descriptionPrevious value: -"type \"fvg\": near edge, midpoint (default) or far edge of the gap"New value: +"type \"fvg\" / \"zone\": near edge, midpoint (default) or far edge"Input schema / properties / action / properties / limitAt / properties / ref / descriptionPrevious value: -"type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"})"New value: +"type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"}, {\"ref\":\"fib\",\"timeframe\":\"M15\",\"level\":0.618})"Input schema / properties / action / properties / limitAt / properties / type / descriptionPrevious value: -"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"New value: +"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; zone: inside the zone of a zone / confluence condition; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"Input schema / properties / action / properties / limitAt / properties / type / enumPrevious value: -[
- "offset",
- "fvg",
- "level"
-]New value: +[
+ "offset",
+ "fvg",
+ "zone",
+ "level"
+]Input schema / properties / action / properties / stopAt / descriptionPrevious value: -"Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio)"New value: +"Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio or takeProfitAt)"Input schema / properties / action / properties / stopAt / properties / refAdded value: +{
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1",
+ "description": "type \"level\": the level reference"
+}Input schema / properties / action / properties / stopAt / properties / type / descriptionPrevious value: -"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick, the gap or the retest candle wick"New value: +"fvg: beyond the far edge of the gap; zone: beyond the far edge of the zone of a zone/confluence condition; signal_extreme: beyond the sweep wick, the gap, the retest or the confirmation candle wick; level: beyond a level reference computed when the rule fires (e.g. {\"ref\":\"swing_high\",\"timeframe\":\"M15\"})"Input schema / properties / action / properties / stopAt / properties / type / enumPrevious value: -[
- "fvg",
- "signal_extreme"
-]New value: +[
+ "fvg",
+ "zone",
+ "signal_extreme",
+ "level"
+]Input schema / properties / action / properties / takeProfitAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries: a take profit at a level computed when the rule fires (instead of takeProfit / tpRrRatio)",
+ "properties": {
+ "pips": {
+ "description": "Offset from the level in pips (positive above, negative below)",
+ "type": "number"
+ },
+ "ref": {
+ "additionalProperties": false,
+ "description": "The level reference: e.g. the last swing low {\"ref\":\"swing_low\",\"timeframe\":\"M15\"} or a Fibonacci extension {\"ref\":\"fib\",\"timeframe\":\"M15\",\"level\":-0.27}",
+ "properties": {
+ "daysAgo": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/daysAgo"
+ },
+ "direction": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/direction"
+ },
+ "end": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/end"
+ },
+ "indicator": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/indicator"
+ },
+ "level": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/level"
+ },
+ "minImpulseAtr": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/minImpulseAtr"
+ },
+ "minSwingAtr": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/minSwingAtr"
+ },
+ "nth": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/nth"
+ },
+ "period": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/period"
+ },
+ "ref": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/ref"
+ },
+ "session": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/session"
+ },
+ "shift": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/shift"
+ },
+ "start": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/start"
+ },
+ "strength": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/strength"
+ },
+ "timeframe": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/timeframe"
+ },
+ "timezone": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/timezone"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "const": "level",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "ref"
+ ],
+ "type": "object"
+}Input schema / properties / conditions / items / properties / baseCandlesAdded value: +{
+ "description": "flip_zone: minimum candles of the base (2-20, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / baseRangeAtrAdded value: +{
+ "description": "flip_zone: maximum range of the base in ATR(14) (0.2-5, default 1)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / confirmStrengthAdded value: +{
+ "description": "trigger \"choch\": swing strength on the confirmTimeframe (1-10, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / confirmTimeframeAdded value: +{
+ "description": "zone/confluence with trigger close/rejection (default the zone timeframe) or choch (required, lower than the zone timeframe)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / fromAdded value: +{
+ "description": "fib_zone: lower retracement level (default 0.5)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- },
- "timezone": {
- "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "direction": {
+ "description": "ref \"fib\": only if the last impulse goes this way (default any)",
+ "enum": [
+ "bullish",
+ "bearish",
+ "any"
+ ],
+ "type": "string"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "description": "ref \"fib\": the Fibonacci level (e.g. 0.618, 1, -0.27)",
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "description": "ref \"fib\": only impulses of at least this × ATR(14)",
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "description": "swing_high/swing_low/fib: ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+ },
+ "nth": {
+ "description": "swing_high/swing_low: 1 = the last confirmed swing (default), 2 = the one before…",
+ "type": "integer"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "description": "Daily references, indicators, price, or MARKET STRUCTURE (M5-D1, closed candles only, no look-ahead): swing_high / swing_low = the last confirmed swing high/low (nth 2 = the one before…; a swing is a high/low with `strength` candles on each side, default 3, confirmed when those candles close); fib = a Fibonacci level of the LAST IMPULSE (the move between the last two opposite swings), measured from its end: 0.5 / 0.618 / 0.786 retracements, 1 = the impulse start, -0.27 / -0.618 = extensions beyond its end (targets).",
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price",
+ "swing_high",
+ "swing_low",
+ "fib"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "strength": {
+ "description": "swing_high/swing_low/fib: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe; swing_high/swing_low/fib: structure timeframe (M5-D1)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / maxAgeCandlesAdded value: +{
+ "description": "zone: only zones created in the last N candles of its timeframe (1-500, default 50)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / maxTouchesAdded value: +{
+ "description": "zone/confluence: 1 = first retest only (default), 2 = up to the second visit… (1-10)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minAdded value: +{
+ "description": "confluence: how many zones must overlap (default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minCountAdded value: +{
+ "description": "equal_highs/equal_lows: swings needed (2-5, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minImpulseAtrAdded value: +{
+ "description": "bos/choch/order_block/fib_zone: minimum size of the impulse (displacement) in ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minOverlapPipsAdded value: +{
+ "description": "confluence: minimum height of the overlap in pips (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minSwingAtrAdded value: +{
+ "description": "Ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / patternAdded value: +{
+ "description": "candle_pattern and trigger \"rejection\": pin_bar, engulfing or any (default)",
+ "enum": [
+ "pin_bar",
+ "engulfing",
+ "any"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / shift / descriptionPrevious value: -"candle_direction: 1 = last closed candle (default), 2 = the one before…"New value: +"candle_direction / candle_pattern: 1 = last closed candle (default), 2 = the one before…"Input schema / properties / conditions / items / properties / strengthAdded value: +{
+ "description": "bos/choch/structure_trend/order_block/fib_zone/equal_*: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / toAdded value: +{
+ "description": "fib_zone: upper retracement level (default 0.618)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / tolerancePips / descriptionPrevious value: -"retest: how close to the level (in pips) counts as a retest (default 0 = must touch it)"New value: +"retest: how close to the level (in pips) counts as a retest (default 0 = must touch it); equal_highs/equal_lows: max distance between the swings (default 0.1 × ATR)"Input schema / properties / conditions / items / properties / trigger / descriptionPrevious value: -"fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes"New value: +"fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes. zone/confluence: touch (default), close, rejection or choch"Input schema / properties / conditions / items / properties / trigger / enumPrevious value: -[
- "touch",
- "close"
-]New value: +[
+ "touch",
+ "close",
+ "rejection",
+ "choch"
+]Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". MARKET STRUCTURE (M5-D1, closed candles, no look-ahead; a swing = a high/low with `strength` candles on each side, default 3, known when those candles close): bos {timeframe, direction bullish|bearish, maxCandles, minImpulseAtr} = filter: the last break of structure (a close beyond the last swing) was in that direction within maxCandles candles (default 20); choch = the same but it reversed the previous break (change of character); structure_trend {timeframe, direction} = higher highs and higher lows (bullish) / lower highs and lower lows (bearish); candle_pattern {timeframe, pattern pin_bar|engulfing|any, direction, shift} = the last closed candle is a rejection candle. zone {zone, timeframe, direction, trigger, …} = ENTRY TRIGGER when price comes back to a live zone: zone order_block (last opposite candle before the impulse that broke structure; minImpulseAtr for displacement), flip_zone (a base of baseCandles+ candles within baseRangeAtr × ATR, default 3 and 1, broken by a close: broken support becomes resistance and vice versa), fib_zone (between the from/to retracements of the LAST impulse, default 0.5-0.618; OTE 0.62-0.79), fvg (fair value gap), equal_highs / equal_lows (2+ swing highs/lows within tolerancePips, default 0.1 × ATR: liquidity). A zone dies when a candle closes beyond it; maxAgeCandles (default 50) = how recent; maxTouches (default 1) = first retest only, 2 = up to the second visit… trigger: touch (default: the minute price reaches it), close (a confirmTimeframe candle touches it and closes back outside), rejection (same, with a pin bar / engulfing candle), choch (a CHoCH on a LOWER confirmTimeframe while price is in the zone: multi-timeframe entry). confluence {direction, zones:[{zone, timeframe, …}, …] (2-4), min (default 2), minOverlapPips, trigger…} = ENTRY TRIGGER at the OVERLAP of at least `min` live zones (the entry zone is their intersection; results are broken down by combination). The zone of the trigger is used by stop/limit \"zone\" (stop beyond its far edge, limit at its near edge / midpoint / far edge). Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "retest",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction",
+ "bos",
+ "choch",
+ "structure_trend",
+ "zone",
+ "confluence",
+ "candle_pattern"
+]Input schema / properties / conditions / items / properties / zoneAdded value: +{
+ "description": "zone: the zone kind",
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / zonesAdded value: +{
+ "description": "confluence: 2-4 zones, e.g. [{\"zone\":\"order_block\",\"timeframe\":\"M15\"},{\"zone\":\"flip_zone\",\"timeframe\":\"M15\"},{\"zone\":\"fib_zone\",\"timeframe\":\"M15\",\"from\":0.5,\"to\":0.618}]",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "baseCandles": {
+ "type": "integer"
+ },
+ "baseRangeAtr": {
+ "type": "number"
+ },
+ "from": {
+ "type": "number"
+ },
+ "maxAgeCandles": {
+ "type": "integer"
+ },
+ "minCount": {
+ "type": "integer"
+ },
+ "minGap": {
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "type": "number"
+ },
+ "strength": {
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "to": {
+ "type": "number"
+ },
+ "tolerancePips": {
+ "type": "number"
+ },
+ "zone": {
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "zone",
+ "timeframe"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}get_market_structureupdate_conditional_order35 fields changedInput schema / properties / action / properties / exitIfNoProgressAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries with mode \"execute\": close the position at the close of the candle when price has made no new high (buy) / low (sell) for N closed candles since entry. Same rule as backtest_strategy trade.management.exitIfNoProgress",
+ "properties": {
+ "candles": {
+ "description": "Candles without a new extreme in favour (1-100)",
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / exitOnCompressionAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries with mode \"execute\": close the position when price compresses (accumulates) instead of moving. Same rule as backtest_strategy",
+ "properties": {
+ "candles": {
+ "description": "Last N closed candles (2-100)",
+ "type": "integer"
+ },
+ "maxRangeAtr": {
+ "description": "Close when their total range is below this × ATR(14) of that timeframe (e.g. 0.8)",
+ "type": "number"
+ },
+ "timeframe": {
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "candles",
+ "timeframe",
+ "maxRangeAtr"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / limitAt / properties / point / descriptionPrevious value: -"type \"fvg\": near edge, midpoint (default) or far edge of the gap"New value: +"type \"fvg\" / \"zone\": near edge, midpoint (default) or far edge"Input schema / properties / action / properties / limitAt / properties / ref / descriptionPrevious value: -"type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"})"New value: +"type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"}, {\"ref\":\"fib\",\"timeframe\":\"M15\",\"level\":0.618})"Input schema / properties / action / properties / limitAt / properties / type / descriptionPrevious value: -"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"New value: +"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; zone: inside the zone of a zone / confluence condition; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"Input schema / properties / action / properties / limitAt / properties / type / enumPrevious value: -[
- "offset",
- "fvg",
- "level"
-]New value: +[
+ "offset",
+ "fvg",
+ "zone",
+ "level"
+]Input schema / properties / action / properties / stopAt / descriptionPrevious value: -"Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio)"New value: +"Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio or takeProfitAt)"Input schema / properties / action / properties / stopAt / properties / refAdded value: +{
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1",
+ "description": "type \"level\": the level reference"
+}Input schema / properties / action / properties / stopAt / properties / type / descriptionPrevious value: -"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick, the gap or the retest candle wick"New value: +"fvg: beyond the far edge of the gap; zone: beyond the far edge of the zone of a zone/confluence condition; signal_extreme: beyond the sweep wick, the gap, the retest or the confirmation candle wick; level: beyond a level reference computed when the rule fires (e.g. {\"ref\":\"swing_high\",\"timeframe\":\"M15\"})"Input schema / properties / action / properties / stopAt / properties / type / enumPrevious value: -[
- "fvg",
- "signal_extreme"
-]New value: +[
+ "fvg",
+ "zone",
+ "signal_extreme",
+ "level"
+]Input schema / properties / action / properties / takeProfitAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries: a take profit at a level computed when the rule fires (instead of takeProfit / tpRrRatio)",
+ "properties": {
+ "pips": {
+ "description": "Offset from the level in pips (positive above, negative below)",
+ "type": "number"
+ },
+ "ref": {
+ "additionalProperties": false,
+ "description": "The level reference: e.g. the last swing low {\"ref\":\"swing_low\",\"timeframe\":\"M15\"} or a Fibonacci extension {\"ref\":\"fib\",\"timeframe\":\"M15\",\"level\":-0.27}",
+ "properties": {
+ "daysAgo": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/daysAgo"
+ },
+ "direction": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/direction"
+ },
+ "end": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/end"
+ },
+ "indicator": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/indicator"
+ },
+ "level": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/level"
+ },
+ "minImpulseAtr": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/minImpulseAtr"
+ },
+ "minSwingAtr": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/minSwingAtr"
+ },
+ "nth": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/nth"
+ },
+ "period": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/period"
+ },
+ "ref": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/ref"
+ },
+ "session": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/session"
+ },
+ "shift": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/shift"
+ },
+ "start": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/start"
+ },
+ "strength": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/strength"
+ },
+ "timeframe": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/timeframe"
+ },
+ "timezone": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1/properties/timezone"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "const": "level",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "ref"
+ ],
+ "type": "object"
+}Input schema / properties / conditions / items / properties / baseCandlesAdded value: +{
+ "description": "flip_zone: minimum candles of the base (2-20, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / baseRangeAtrAdded value: +{
+ "description": "flip_zone: maximum range of the base in ATR(14) (0.2-5, default 1)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / confirmStrengthAdded value: +{
+ "description": "trigger \"choch\": swing strength on the confirmTimeframe (1-10, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / confirmTimeframeAdded value: +{
+ "description": "zone/confluence with trigger close/rejection (default the zone timeframe) or choch (required, lower than the zone timeframe)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / fromAdded value: +{
+ "description": "fib_zone: lower retracement level (default 0.5)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- },
- "timezone": {
- "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "direction": {
+ "description": "ref \"fib\": only if the last impulse goes this way (default any)",
+ "enum": [
+ "bullish",
+ "bearish",
+ "any"
+ ],
+ "type": "string"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "description": "ref \"fib\": the Fibonacci level (e.g. 0.618, 1, -0.27)",
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "description": "ref \"fib\": only impulses of at least this × ATR(14)",
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "description": "swing_high/swing_low/fib: ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+ },
+ "nth": {
+ "description": "swing_high/swing_low: 1 = the last confirmed swing (default), 2 = the one before…",
+ "type": "integer"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "description": "Daily references, indicators, price, or MARKET STRUCTURE (M5-D1, closed candles only, no look-ahead): swing_high / swing_low = the last confirmed swing high/low (nth 2 = the one before…; a swing is a high/low with `strength` candles on each side, default 3, confirmed when those candles close); fib = a Fibonacci level of the LAST IMPULSE (the move between the last two opposite swings), measured from its end: 0.5 / 0.618 / 0.786 retracements, 1 = the impulse start, -0.27 / -0.618 = extensions beyond its end (targets).",
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price",
+ "swing_high",
+ "swing_low",
+ "fib"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "strength": {
+ "description": "swing_high/swing_low/fib: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe; swing_high/swing_low/fib: structure timeframe (M5-D1)",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / maxAgeCandlesAdded value: +{
+ "description": "zone: only zones created in the last N candles of its timeframe (1-500, default 50)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / maxTouchesAdded value: +{
+ "description": "zone/confluence: 1 = first retest only (default), 2 = up to the second visit… (1-10)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minAdded value: +{
+ "description": "confluence: how many zones must overlap (default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minCountAdded value: +{
+ "description": "equal_highs/equal_lows: swings needed (2-5, default 2)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / minImpulseAtrAdded value: +{
+ "description": "bos/choch/order_block/fib_zone: minimum size of the impulse (displacement) in ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minOverlapPipsAdded value: +{
+ "description": "confluence: minimum height of the overlap in pips (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / minSwingAtrAdded value: +{
+ "description": "Ignore swings that stand out less than this × ATR(14) (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / patternAdded value: +{
+ "description": "candle_pattern and trigger \"rejection\": pin_bar, engulfing or any (default)",
+ "enum": [
+ "pin_bar",
+ "engulfing",
+ "any"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / shift / descriptionPrevious value: -"candle_direction: 1 = last closed candle (default), 2 = the one before…"New value: +"candle_direction / candle_pattern: 1 = last closed candle (default), 2 = the one before…"Input schema / properties / conditions / items / properties / strengthAdded value: +{
+ "description": "bos/choch/structure_trend/order_block/fib_zone/equal_*: candles on each side of a swing (1-10, default 3)",
+ "type": "integer"
+}Input schema / properties / conditions / items / properties / toAdded value: +{
+ "description": "fib_zone: upper retracement level (default 0.618)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / tolerancePips / descriptionPrevious value: -"retest: how close to the level (in pips) counts as a retest (default 0 = must touch it)"New value: +"retest: how close to the level (in pips) counts as a retest (default 0 = must touch it); equal_highs/equal_lows: max distance between the swings (default 0.1 × ATR)"Input schema / properties / conditions / items / properties / trigger / descriptionPrevious value: -"fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes"New value: +"fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes. zone/confluence: touch (default), close, rejection or choch"Input schema / properties / conditions / items / properties / trigger / enumPrevious value: -[
- "touch",
- "close"
-]New value: +[
+ "touch",
+ "close",
+ "rejection",
+ "choch"
+]Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". MARKET STRUCTURE (M5-D1, closed candles, no look-ahead; a swing = a high/low with `strength` candles on each side, default 3, known when those candles close): bos {timeframe, direction bullish|bearish, maxCandles, minImpulseAtr} = filter: the last break of structure (a close beyond the last swing) was in that direction within maxCandles candles (default 20); choch = the same but it reversed the previous break (change of character); structure_trend {timeframe, direction} = higher highs and higher lows (bullish) / lower highs and lower lows (bearish); candle_pattern {timeframe, pattern pin_bar|engulfing|any, direction, shift} = the last closed candle is a rejection candle. zone {zone, timeframe, direction, trigger, …} = ENTRY TRIGGER when price comes back to a live zone: zone order_block (last opposite candle before the impulse that broke structure; minImpulseAtr for displacement), flip_zone (a base of baseCandles+ candles within baseRangeAtr × ATR, default 3 and 1, broken by a close: broken support becomes resistance and vice versa), fib_zone (between the from/to retracements of the LAST impulse, default 0.5-0.618; OTE 0.62-0.79), fvg (fair value gap), equal_highs / equal_lows (2+ swing highs/lows within tolerancePips, default 0.1 × ATR: liquidity). A zone dies when a candle closes beyond it; maxAgeCandles (default 50) = how recent; maxTouches (default 1) = first retest only, 2 = up to the second visit… trigger: touch (default: the minute price reaches it), close (a confirmTimeframe candle touches it and closes back outside), rejection (same, with a pin bar / engulfing candle), choch (a CHoCH on a LOWER confirmTimeframe while price is in the zone: multi-timeframe entry). confluence {direction, zones:[{zone, timeframe, …}, …] (2-4), min (default 2), minOverlapPips, trigger…} = ENTRY TRIGGER at the OVERLAP of at least `min` live zones (the entry zone is their intersection; results are broken down by combination). The zone of the trigger is used by stop/limit \"zone\" (stop beyond its far edge, limit at its near edge / midpoint / far edge). Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "retest",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction",
+ "bos",
+ "choch",
+ "structure_trend",
+ "zone",
+ "confluence",
+ "candle_pattern"
+]Input schema / properties / conditions / items / properties / zoneAdded value: +{
+ "description": "zone: the zone kind",
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / zonesAdded value: +{
+ "description": "confluence: 2-4 zones, e.g. [{\"zone\":\"order_block\",\"timeframe\":\"M15\"},{\"zone\":\"flip_zone\",\"timeframe\":\"M15\"},{\"zone\":\"fib_zone\",\"timeframe\":\"M15\",\"from\":0.5,\"to\":0.618}]",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "baseCandles": {
+ "type": "integer"
+ },
+ "baseRangeAtr": {
+ "type": "number"
+ },
+ "from": {
+ "type": "number"
+ },
+ "maxAgeCandles": {
+ "type": "integer"
+ },
+ "minCount": {
+ "type": "integer"
+ },
+ "minGap": {
+ "type": "number"
+ },
+ "minImpulseAtr": {
+ "type": "number"
+ },
+ "minSwingAtr": {
+ "type": "number"
+ },
+ "strength": {
+ "type": "integer"
+ },
+ "timeframe": {
+ "enum": [
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "to": {
+ "type": "number"
+ },
+ "tolerancePips": {
+ "type": "number"
+ },
+ "zone": {
+ "enum": [
+ "order_block",
+ "flip_zone",
+ "fib_zone",
+ "fvg",
+ "equal_highs",
+ "equal_lows"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "zone",
+ "timeframe"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}backtest_strategy16 fields changedInput schema / properties / allTradesAdded value: +{
+ "description": "true: list every trade of the period (up to 300) instead of the latest 40",
+ "type": "boolean"
+}Input schema / properties / conditions / items / properties / end / descriptionPrevious value: -"time_window: HH:MM UTC"New value: +"time_window: HH:MM (UTC, or local time of timezone)"Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / start / descriptionPrevious value: -"time_window: HH:MM UTC"New value: +"time_window: HH:MM (UTC, or local time of timezone)"Input schema / properties / conditions / items / properties / timezoneAdded value: +{
+ "description": "time_window: IANA time zone (e.g. Europe/London) so start/end are local market time in summer and winter (default UTC)",
+ "type": "string"
+}Input schema / properties / costsAdded value: +{
+ "additionalProperties": false,
+ "description": "Trading costs charged on every trade (buys and sells): the result shows R gross and net of costs. E.g. gold {\"spreadPips\":30,\"commissionPerLot\":7}",
+ "properties": {
+ "commissionPerLot": {
+ "description": "Round-turn commission in USD per standard lot (gold, silver and forex pairs with USD)",
+ "type": "number"
+ },
+ "commissionPips": {
+ "description": "Or the round-turn commission in pips (any symbol)",
+ "type": "number"
+ },
+ "slippagePips": {
+ "description": "Slippage in pips per fill (charged on entry and exit)",
+ "type": "number"
+ },
+ "spreadPips": {
+ "description": "Spread in pips, charged on buys AND sells",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / spreadPips / descriptionPrevious value: -"Spread in pips added to buy entries (default 0)"New value: +"Spread in pips, charged on buys and sells (same as costs.spreadPips)"Input schema / properties / trade / properties / closeAt / descriptionPrevious value: -"HH:MM UTC: close any open trade at this time and take no new entries after it"New value: +"HH:MM (UTC, or local time of trade.timezone): close any open trade at this time and take no new entries after it"Input schema / properties / trade / properties / managementAdded value: +{
+ "additionalProperties": false,
+ "description": "Trade management while open: break-even and partial closes (checked after the stop on each 1-minute candle: worst case)",
+ "properties": {
+ "breakevenAtR": {
+ "description": "Move the stop to the entry once price reaches +N R (e.g. 1)",
+ "type": "number"
+ },
+ "partials": {
+ "description": "Up to 3 partial closes, e.g. [{\"atR\":1,\"closePct\":50}]",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "atR": {
+ "description": "Close part of the trade at +N R (below the target)",
+ "type": "number"
+ },
+ "closePct": {
+ "description": "Percent of the position closed there (1-99; all partials together < 100)",
+ "type": "number"
+ }
+ },
+ "required": [
+ "atR",
+ "closePct"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / trade / properties / maxStopPipsAdded value: +{
+ "description": "Skip signals whose stop is farther than this many pips",
+ "type": "number"
+}Input schema / properties / trade / properties / minStopPipsAdded value: +{
+ "description": "Skip signals whose stop is closer than this many pips (counted as \"discarded by stop size\")",
+ "type": "number"
+}Input schema / properties / trade / properties / stop / properties / edgeAdded value: +{
+ "description": "type \"fvg\": far edge (default; below a bullish gap / above a bearish gap), near edge, midpoint, or pattern = beyond the low/high of the three candles that form the gap",
+ "enum": [
+ "far",
+ "near",
+ "midpoint",
+ "pattern"
+ ],
+ "type": "string"
+}Input schema / properties / trade / properties / stop / properties / type / descriptionPrevious value: -"pips: distance from entry; price: fixed price; level: a reference (the Asian low, an EMA…); wick: beyond the sweep wick (or the trigger candle extreme); atr: multiple × ATR from the entry"New value: +"pips: distance from entry; price: fixed price; level: a reference (the Asian low, an EMA…); wick: beyond the sweep wick (or the trigger candle extreme); atr: multiple × ATR from the entry; fvg: at an edge of the gap of the fvg_retest/fvg_formed condition (edge far by default) plus bufferPips"Input schema / properties / trade / properties / stop / properties / type / enumPrevious value: -[
- "pips",
- "price",
- "level",
- "wick",
- "atr"
-]New value: +[
+ "pips",
+ "price",
+ "level",
+ "wick",
+ "atr",
+ "fvg"
+]Input schema / properties / trade / properties / timezoneAdded value: +{
+ "$ref": "#/properties/conditions/items/properties/timezone",
+ "description": "IANA time zone for closeAt (e.g. Europe/London); default UTC"
+}Input schema / properties / trade / properties / trailingAdded value: +{
+ "description": "true: trailing stop — after each 1-minute candle the stop moves to best price minus the initial stop distance, only in favour (the same rule the broker applies to a live order or conditional with trailing: true)",
+ "type": "boolean"
+}create_conditional_order3 fields changedInput schema / properties / action / properties / trailingAdded value: +{
+ "description": "Entries with mode \"execute\": 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. Checked when the order is created.",
+ "type": "boolean"
+}Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / timezoneAdded value: +{
+ "description": "time_window: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC)",
+ "type": "string"
+}execute_trade1 field changedInput schema / properties / trailingAdded 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"
+}update_conditional_order3 fields changedInput schema / properties / action / properties / trailingAdded value: +{
+ "description": "Entries with mode \"execute\": 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. Checked when the order is created.",
+ "type": "boolean"
+}Input schema / properties / conditions / items / properties / level / anyOfPrevious value: -[
- {
- "type": "number"
- },
- {
- "additionalProperties": false,
- "properties": {
- "daysAgo": {
- "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
- "type": "integer"
- },
- "end": {
- "description": "range_high/range_low: HH:MM UTC (same day, after start)",
- "type": "string"
- },
- "indicator": {
- "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
- "enum": [
- "sma",
- "ema",
- "rsi",
- "atr",
- "highest",
- "lowest"
- ],
- "type": "string"
- },
- "period": {
- "description": "ref \"indicator\": period (e.g. 50)",
- "type": "integer"
- },
- "ref": {
- "enum": [
- "session_high",
- "session_low",
- "range_high",
- "range_low",
- "prev_day_high",
- "prev_day_low",
- "prev_day_close",
- "day_high",
- "day_low",
- "day_open",
- "day_close",
- "indicator",
- "price"
- ],
- "type": "string"
- },
- "session": {
- "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
- "enum": [
- "asia",
- "london",
- "new_york"
- ],
- "type": "string"
- },
- "shift": {
- "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
- "type": "integer"
- },
- "start": {
- "description": "range_high/range_low: HH:MM UTC",
- "type": "string"
- },
- "timeframe": {
- "description": "ref \"indicator\": candle timeframe",
- "enum": [
- "M1",
- "M5",
- "M15",
- "M30",
- "H1",
- "H4",
- "D1"
- ],
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "daysAgo": {
+ "description": "day_high/day_low/day_close: 1 = yesterday, 2 = the day before…; day_open: 0 = today",
+ "type": "integer"
+ },
+ "end": {
+ "description": "range_high/range_low: HH:MM UTC (same day, after start)",
+ "type": "string"
+ },
+ "indicator": {
+ "description": "ref \"indicator\": highest/lowest = highest high / lowest low of the last N candles",
+ "enum": [
+ "sma",
+ "ema",
+ "rsi",
+ "atr",
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+ },
+ "period": {
+ "description": "ref \"indicator\": period (e.g. 50)",
+ "type": "integer"
+ },
+ "ref": {
+ "enum": [
+ "session_high",
+ "session_low",
+ "range_high",
+ "range_low",
+ "prev_day_high",
+ "prev_day_low",
+ "prev_day_close",
+ "day_high",
+ "day_low",
+ "day_open",
+ "day_close",
+ "indicator",
+ "price"
+ ],
+ "type": "string"
+ },
+ "session": {
+ "description": "session_high/session_low: asia 00:00-07:00, london 07:00-16:00, new_york 13:00-21:00 UTC",
+ "enum": [
+ "asia",
+ "london",
+ "new_york"
+ ],
+ "type": "string"
+ },
+ "shift": {
+ "description": "ref \"indicator\": 0 = last closed candle (default), 1 = the one before…",
+ "type": "integer"
+ },
+ "start": {
+ "description": "range_high/range_low: HH:MM UTC",
+ "type": "string"
+ },
+ "timeframe": {
+ "description": "ref \"indicator\": candle timeframe",
+ "enum": [
+ "M1",
+ "M5",
+ "M15",
+ "M30",
+ "H1",
+ "H4",
+ "D1"
+ ],
+ "type": "string"
+ },
+ "timezone": {
+ "description": "range_high/range_low: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC); the range must fall within the UTC day",
+ "type": "string"
+ }
+ },
+ "required": [
+ "ref"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / conditions / items / properties / timezoneAdded value: +{
+ "description": "time_window: IANA time zone (e.g. Europe/London, America/New_York): the HH:MM times are local market time, so the same window follows the market in summer and winter (default UTC)",
+ "type": "string"
+}backtest_strategy5 fields changedInput schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"New value: +"range_breakout: up/down/any; retest: up/down; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside (1-10, default 3); fvg_retest: how recent the gap must be (3-100 candles, default 20)"New value: +"sweep_above/sweep_below: candles allowed to close back inside (1-10, default 3); fvg_retest: how recent the gap must be (3-100 candles, default 20); retest: max candles between the breakout and the retest (1-50, default 10)"Input schema / properties / conditions / items / properties / tolerancePipsAdded value: +{
+ "description": "retest: how close to the level (in pips) counts as a retest (default 0)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, fvg_formed = a new gap just formed (pair it with a limit entry in the gap), time_window, days_of_week) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."New value: +"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, fvg_formed = a new gap just formed (pair it with a limit entry in the gap), time_window, days_of_week, retest {level, direction up|down, timeframe, maxCandles, tolerancePips} = break and retest of a level: a candle closes beyond the level (breakout), then within maxCandles candles (1-50, default 10) the first candle that comes back to it (within tolerancePips, default 0) and closes on the breakout side fires at its close; a close back inside before that cancels the breakout) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction",
+ "retest"
+]create_conditional_order10 fields changedInput schema / properties / action / properties / limitAt / properties / pips / descriptionPrevious value: -"type \"offset\": pips below (buy) / above (sell) the trigger price"New value: +"type \"offset\": pips below (buy) / above (sell) the trigger price; type \"level\": optional offset from the level in pips (positive above, negative below)"Input schema / properties / action / properties / limitAt / properties / refAdded value: +{
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1",
+ "description": "type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"})"
+}Input schema / properties / action / properties / limitAt / properties / type / descriptionPrevious value: -"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed"New value: +"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"Input schema / properties / action / properties / limitAt / properties / type / enumPrevious value: -[
- "offset",
- "fvg"
-]New value: +[
+ "offset",
+ "fvg",
+ "level"
+]Input schema / properties / action / properties / stopAt / properties / type / descriptionPrevious value: -"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick or the gap"New value: +"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick, the gap or the retest candle wick"Input schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"New value: +"range_breakout: up/down/any; retest: up/down; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20)"New value: +"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20); retest: max candles between the breakout candle and the retest candle (1-50, default 10)"Input schema / properties / conditions / items / properties / tolerancePipsAdded value: +{
+ "description": "retest: how close to the level (in pips) counts as a retest (default 0 = must touch it)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]update_conditional_order10 fields changedInput schema / properties / action / properties / limitAt / properties / pips / descriptionPrevious value: -"type \"offset\": pips below (buy) / above (sell) the trigger price"New value: +"type \"offset\": pips below (buy) / above (sell) the trigger price; type \"level\": optional offset from the level in pips (positive above, negative below)"Input schema / properties / action / properties / limitAt / properties / refAdded value: +{
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1",
+ "description": "type \"level\": the level reference, same forms as in the conditions (e.g. {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, {\"ref\":\"session_high\",\"session\":\"asia\"}, {\"ref\":\"prev_day_high\"})"
+}Input schema / properties / action / properties / limitAt / properties / type / descriptionPrevious value: -"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed"New value: +"offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed; level: at a level reference computed when the rule fires (e.g. today's 08:00-10:00 UTC range high after a breakout of it)"Input schema / properties / action / properties / limitAt / properties / type / enumPrevious value: -[
- "offset",
- "fvg"
-]New value: +[
+ "offset",
+ "fvg",
+ "level"
+]Input schema / properties / action / properties / stopAt / properties / type / descriptionPrevious value: -"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick or the gap"New value: +"fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick, the gap or the retest candle wick"Input schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"New value: +"range_breakout: up/down/any; retest: up/down; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20)"New value: +"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20); retest: max candles between the breakout candle and the retest candle (1-50, default 10)"Input schema / properties / conditions / items / properties / tolerancePipsAdded value: +{
+ "description": "retest: how close to the level (in pips) counts as a retest (default 0 = must touch it)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. retest {level, direction up|down, timeframe, maxCandles, tolerancePips}: BREAK AND RETEST of a level on closed candles of that timeframe. up: a candle closes above the level after a close at or below it (the breakout), then within maxCandles candles (1-50, default 10) the FIRST candle that comes back to the level (low <= level + tolerancePips, default 0) and still closes above it is the retest: it fires at the close of that candle. If a candle closes back at or below the level before the retest, that breakout is cancelled (a new one can start later). down = the mirror (break below, retest from below, close below). up → typically a BUY, down → a SELL; action.stopAt {\"type\":\"signal_extreme\"} puts the stop beyond the retest candle wick. Levels can be references (e.g. the 08:00-10:00 UTC range high: {\"ref\":\"range_high\",\"start\":\"08:00\",\"end\":\"10:00\"}, the Asian session high, the previous day high). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "fvg_formed",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]execute_trade1 field changedInput schema / properties / executionType / descriptionPrevious 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\"."backtest_strategy2 fields changedInput schema / properties / conditions / items / properties / triggerAdded value: +{
+ "description": "fvg_retest: touch = enter as soon as price reaches the gap (default); close = when the candle that returns to the gap closes",
+ "enum": [
+ "touch",
+ "close"
+ ],
+ "type": "string"
+}Input schema / properties / symbol / descriptionPrevious value: -"Symbol (e.g. EUR_USD, XAU_USD, NAS100_USD). Use list_symbols"New value: +"Symbol (e.g. EUR_USD, XAU_USD, NAS100_USD)."create_conditional_order3 fields changedInput schema / properties / conditions / items / properties / triggerAdded value: +{
+ "description": "fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes",
+ "enum": [
+ "touch",
+ "close"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / symbol / descriptionPrevious value: -"Trading symbol (e.g. EUR_USD). Use list_symbols"New value: +"Trading symbol (e.g. EUR_USD)."draw_chart3 fields changedInput schema / properties / marks / items / properties / from / descriptionPrevious value: -"Candle open time in UTC, ISO 8601 (e.g. \"2026-10-15T10:35:00Z\"), taken from get_ohlc"New value: +"Candle open time in UTC, ISO 8601 (e.g. \"2026-10-15T10:35:00Z\")"Input schema / properties / marks / items / properties / to / descriptionPrevious value: -"Candle open time in UTC, ISO 8601 (e.g. \"2026-10-15T10:35:00Z\"), taken from get_ohlc"New value: +"Candle open time in UTC, ISO 8601 (e.g. \"2026-10-15T10:35:00Z\")"Input schema / properties / symbol / descriptionPrevious value: -"Symbol (e.g. XAU_USD, NAS100_USD, EUR_USD). Use list_symbols"New value: +"Symbol (e.g. XAU_USD, NAS100_USD, EUR_USD)."get_chart2 fields changedInput schema / properties / symbol / descriptionPrevious value: -"Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD). Use list_symbols to see all available."New value: +"Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD)."Input schema / properties / timeframe / descriptionPrevious value: -"Chart timeframe: M1, M5, M15, H1, H4, or D. Use list_timeframes for details."New value: +"Chart timeframe: M1, M5, M15, H1, H4, or D."get_ohlc2 fields changedInput schema / properties / from / descriptionPrevious value: -"Start of time range. ISO 8601 (e.g. \"2026-04-01T00:00:00Z\") or unix seconds. Only candles at or after this time are included. How far back you can go depends on the plan (Free: last 7 days, Trader: 90 days, Max: all history); the latest candles without from/to are never limited."New value: +"Start of time range. ISO 8601 (e.g. \"2026-04-01T00:00:00Z\") or unix seconds. Only candles at or after this time are included. How far back you can go depends on the plan (Free: last 7 days, Trader: 90 days, Max: all history); the latest candles (without from/to) are available on every plan."Input schema / properties / symbol / descriptionPrevious value: -"Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD, NAS100_USD). Use list_symbols to see all available."New value: +"Trading symbol (e.g. EUR_USD, XAU_USD, BTC_USD, NAS100_USD)."set_auto_execution_config1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Trading symbol (e.g. EUR_USD). Use list_symbols for options"New value: +"Trading symbol (e.g. EUR_USD)."suggest_order1 field changedInput schema / properties / symbol / descriptionPrevious value: -"Trading symbol (e.g. EUR_USD). Use list_symbols for options"New value: +"Trading symbol (e.g. EUR_USD)."update_conditional_order2 fields changedInput schema / properties / conditions / items / properties / triggerAdded value: +{
+ "description": "fvg_retest: touch = fire as soon as price reaches the gap, without waiting for the candle to close (default); close = fire when the candle that returns to the gap closes",
+ "enum": [
+ "touch",
+ "close"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, trigger, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when price returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without going beyond its far edge. trigger \"touch\" (default) fires in the minute price reaches the gap, inside the candle; trigger \"close\" waits for that candle to close and requires it not to close beyond the far edge (more confirmation, later and worse entry). maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."list_symbols1 field changedInput schema / properties / category / descriptionPrevious value: -"Filter by category: forex, commodities, indices, crypto"New value: +"Filter by category: forex, commodities, indices, futures, crypto"create_conditional_order3 fields changedInput schema / properties / action / properties / brokerConfigs / items / properties / confirmHighRiskAdded value: +{
+ "description": "Only after the user explicitly confirmed a percentage risk above 10% per order",
+ "type": "boolean"
+}Input schema / properties / action / properties / brokerConfigs / items / properties / sizingMode / descriptionPrevious value: -"\"percentage\" = % of balance to risk (max 10), \"fixed_lots\" = lot size"New value: +"\"percentage\" = % of the balance LOST if the stop loss is hit (not the share of the balance used); \"fixed_lots\" = lot size"Input schema / properties / action / properties / brokerConfigs / items / properties / sizingValue / descriptionPrevious value: -"Percentage (e.g. 1) or lots (e.g. 0.01)"New value: +"Percentage (typically 0.25-2, up to 100; above 10 needs confirmHighRisk after the user confirms) or lots (e.g. 0.01)"execute_trade2 fields changedInput schema / properties / confirmHighRiskAdded value: +{
+ "description": "Only after the user explicitly confirmed a percentage risk above 10% per order.",
+ "type": "boolean"
+}Input schema / properties / sizingValue / descriptionPrevious 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."execute_trade_multi2 fields changedInput schema / properties / confirmHighRiskAdded value: +{
+ "description": "Only after the user explicitly confirmed a percentage risk above 10% per order (tell them the total across accounts).",
+ "type": "boolean"
+}Input schema / properties / sizingValue / descriptionPrevious value: -"When sizingMode=\"percentage\", the % of each account balance to risk"New value: +"When sizingMode=\"percentage\", the % of each account balance LOST if the stop loss is hit (not the share of the balance used). Above 10 requires confirmHighRisk."set_account_group1 field changedInput schema / properties / members / items / properties / confirmHighRiskAdded value: +{
+ "type": "boolean"
+}set_auto_execution_config3 fields changedInput schema / properties / brokerConfigs / items / properties / confirmHighRiskAdded value: +{
+ "description": "Only after the user explicitly confirmed a percentage risk above 10% per order",
+ "type": "boolean"
+}Input schema / properties / brokerConfigs / items / properties / sizingMode / descriptionPrevious value: -"\"percentage\" = % of balance to risk (max 10), \"fixed_lots\" = fixed lot size"New value: +"\"percentage\" = % of the balance LOST if each order's stop loss is hit (not the share of the balance used); \"fixed_lots\" = fixed lot size"Input schema / properties / brokerConfigs / items / properties / sizingValue / descriptionPrevious value: -"For percentage: 0.5-10 (%). For fixed_lots: lot size (e.g. 0.01)"New value: +"For percentage: typically 0.25-2 (%), up to 100; above 10 needs confirmHighRisk after the user confirms (each auto-executed order risks this %, so 10 orders at once = 10×). For fixed_lots: lot size (e.g. 0.01)"update_conditional_order3 fields changedInput schema / properties / action / properties / brokerConfigs / items / properties / confirmHighRiskAdded value: +{
+ "description": "Only after the user explicitly confirmed a percentage risk above 10% per order",
+ "type": "boolean"
+}Input schema / properties / action / properties / brokerConfigs / items / properties / sizingMode / descriptionPrevious value: -"\"percentage\" = % of balance to risk (max 10), \"fixed_lots\" = lot size"New value: +"\"percentage\" = % of the balance LOST if the stop loss is hit (not the share of the balance used); \"fixed_lots\" = lot size"Input schema / properties / action / properties / brokerConfigs / items / properties / sizingValue / descriptionPrevious value: -"Percentage (e.g. 1) or lots (e.g. 0.01)"New value: +"Percentage (typically 0.25-2, up to 100; above 10 needs confirmHighRisk after the user confirms) or lots (e.g. 0.01)"backtest_strategy8 fields changedInput schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, time_window, days_of_week) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."New value: +"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, fvg_formed = a new gap just formed (pair it with a limit entry in the gap), time_window, days_of_week) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]Input schema / properties / trade / properties / entryAdded value: +{
+ "additionalProperties": false,
+ "description": "How to enter once the rule fires",
+ "properties": {
+ "at": {
+ "additionalProperties": false,
+ "properties": {
+ "pips": {
+ "type": "number"
+ },
+ "point": {
+ "description": "type \"fvg\": near edge, midpoint (default) or far edge",
+ "enum": [
+ "near",
+ "midpoint",
+ "far"
+ ],
+ "type": "string"
+ },
+ "ref": {
+ "$ref": "#/properties/conditions/items/properties/level/anyOf/1"
+ },
+ "type": {
+ "description": "offset: N pips better than the signal price; price: fixed; level: a reference (Asian low, EMA…); fvg: inside the gap of an fvg condition",
+ "enum": [
+ "offset",
+ "price",
+ "level",
+ "fvg"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+ },
+ "expiryMinutes": {
+ "description": "limit: cancel if not filled after N minutes (1-1440, default 60); unfilled signals are counted",
+ "type": "integer"
+ },
+ "type": {
+ "description": "market (default): enter at the close of the signal candle; limit: wait for price to reach a limit price",
+ "enum": [
+ "market",
+ "limit"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / trade / properties / maxMinutesAdded value: +{
+ "description": "Time exit: close the trade N minutes after entry (1-10080)",
+ "type": "integer"
+}Input schema / properties / trade / properties / target / descriptionAdded value: +"Take profit (optional when the trade has a time exit)"Input schema / properties / trade / properties / target / properties / type / descriptionPrevious value: -"rr: multiple of the risk (2 = 2R)"New value: +"rr: multiple of the risk (2 = 2R); none: no take profit (needs maxMinutes or closeAt)"Input schema / properties / trade / properties / target / properties / type / enumPrevious value: -[
- "rr",
- "pips",
- "price",
- "level"
-]New value: +[
+ "rr",
+ "pips",
+ "price",
+ "level",
+ "none"
+]Input schema / properties / trade / requiredPrevious value: -[
- "side",
- "stop",
- "target"
-]New value: +[
+ "side",
+ "stop"
+]create_conditional_order7 fields changedInput schema / properties / action / properties / expiryMinutesAdded value: +{
+ "description": "Only for type \"limit\": cancel the pending order if it has not filled after this many minutes (1-1440)",
+ "type": "integer"
+}Input schema / properties / action / properties / limitAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Only for type \"limit\": a RELATIVE limit price computed when the rule fires, instead of a fixed limitPrice",
+ "properties": {
+ "pips": {
+ "description": "type \"offset\": pips below (buy) / above (sell) the trigger price",
+ "type": "number"
+ },
+ "point": {
+ "description": "type \"fvg\": near edge, midpoint (default) or far edge of the gap",
+ "enum": [
+ "near",
+ "midpoint",
+ "far"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "description": "offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed",
+ "enum": [
+ "offset",
+ "fvg"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / maxMinutesAdded value: +{
+ "description": "Entries: close the position this many minutes after it opens (1-10080), whatever the result — a time exit; with it the take profit is optional",
+ "type": "integer"
+}Input schema / properties / action / properties / stopAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio)",
+ "properties": {
+ "bufferPips": {
+ "description": "Extra pips beyond that level (default 0)",
+ "type": "number"
+ },
+ "type": {
+ "description": "fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick or the gap",
+ "enum": [
+ "fvg",
+ "signal_extreme"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / stopLoss / descriptionPrevious value: -"Entries: stop loss price (required). modify_position: new stop loss price, or \"break_even\" to move it to the entry price"New value: +"Entries: stop loss price (required unless stopAt). modify_position: new stop loss price, or \"break_even\" to move it to the entry price"Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]update_conditional_order7 fields changedInput schema / properties / action / properties / expiryMinutesAdded value: +{
+ "description": "Only for type \"limit\": cancel the pending order if it has not filled after this many minutes (1-1440)",
+ "type": "integer"
+}Input schema / properties / action / properties / limitAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Only for type \"limit\": a RELATIVE limit price computed when the rule fires, instead of a fixed limitPrice",
+ "properties": {
+ "pips": {
+ "description": "type \"offset\": pips below (buy) / above (sell) the trigger price",
+ "type": "number"
+ },
+ "point": {
+ "description": "type \"fvg\": near edge, midpoint (default) or far edge of the gap",
+ "enum": [
+ "near",
+ "midpoint",
+ "far"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "description": "offset: N pips better than the price when the rule fires; fvg: inside the gap found by fvg_retest / fvg_formed",
+ "enum": [
+ "offset",
+ "fvg"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / maxMinutesAdded value: +{
+ "description": "Entries: close the position this many minutes after it opens (1-10080), whatever the result — a time exit; with it the take profit is optional",
+ "type": "integer"
+}Input schema / properties / action / properties / stopAtAdded value: +{
+ "additionalProperties": false,
+ "description": "Entries: a RELATIVE stop loss computed when the rule fires, instead of a fixed stopLoss (use with tpRrRatio)",
+ "properties": {
+ "bufferPips": {
+ "description": "Extra pips beyond that level (default 0)",
+ "type": "number"
+ },
+ "type": {
+ "description": "fvg: beyond the far edge of the gap; signal_extreme: beyond the sweep wick or the gap",
+ "enum": [
+ "fvg",
+ "signal_extreme"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+}Input schema / properties / action / properties / stopLoss / descriptionPrevious value: -"Entries: stop loss price (required). modify_position: new stop loss price, or \"break_even\" to move it to the entry price"New value: +"Entries: stop loss price (required unless stopAt). modify_position: new stop loss price, or \"break_even\" to move it to the entry price"Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). fvg_formed {timeframe, direction, minGap}: fires as soon as a NEW fair value gap forms (the last closed candle completes it) — pair it with a LIMIT entry inside the gap (action.limitAt {\"type\":\"fvg\",\"point\":\"midpoint\"}) and an expiry, which is how FVG entries are usually traded. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "fvg_retest",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "fvg_formed",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]backtest_strategy6 fields changedInput schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction: bullish/bearish"New value: +"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / entryAdded value: +{
+ "description": "fvg_retest: touch (default) or midpoint of the gap",
+ "enum": [
+ "touch",
+ "midpoint"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside (1-10, default 3)"New value: +"sweep_above/sweep_below: candles allowed to close back inside (1-10, default 3); fvg_retest: how recent the gap must be (3-100 candles, default 20)"Input schema / properties / conditions / items / properties / minGapAdded value: +{
+ "description": "fvg_retest: minimum gap size in price units",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, time_window, days_of_week) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."New value: +"Same as create_conditional_order (price_above/below, crosses_above/below, close_above/below, range_breakout, consecutive_closes, sweep_above/below, fvg_retest = first retest of a fair value gap, time_window, days_of_week) plus two backtest conditions: compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, D1 EMA 20 above D1 EMA 50, H1 RSI below 30, yesterday's high above the day before's; crosses_* can be the entry trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\"."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]create_conditional_order6 fields changedInput schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction: bullish/bearish"New value: +"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / entryAdded value: +{
+ "description": "fvg_retest: touch = price reaches the gap (default); midpoint = price reaches its 50%",
+ "enum": [
+ "touch",
+ "midpoint"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3)"New value: +"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20)"Input schema / properties / conditions / items / properties / minGapAdded value: +{
+ "description": "fvg_retest: minimum gap size in price units (default: any size)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]update_conditional_order6 fields changedInput schema / properties / conditions / items / properties / direction / descriptionPrevious value: -"range_breakout: up/down/any; candle_direction: bullish/bearish"New value: +"range_breakout: up/down/any; candle_direction and fvg_retest: bullish/bearish"Input schema / properties / conditions / items / properties / entryAdded value: +{
+ "description": "fvg_retest: touch = price reaches the gap (default); midpoint = price reaches its 50%",
+ "enum": [
+ "touch",
+ "midpoint"
+ ],
+ "type": "string"
+}Input schema / properties / conditions / items / properties / maxCandles / descriptionPrevious value: -"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3)"New value: +"sweep_above/sweep_below: candles allowed to close back inside after the wick (1-10, default 3); fvg_retest: how recent the gap must be, in candles (3-100, default 20)"Input schema / properties / conditions / items / properties / minGapAdded value: +{
+ "description": "fvg_retest: minimum gap size in price units (default: any size)",
+ "type": "number"
+}Input schema / properties / conditions / items / properties / type / descriptionPrevious value: -"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."New value: +"price_above/price_below {level}: current price beyond level. crosses_above/crosses_below {level}: price crosses the level after creation. close_above/close_below {level,timeframe}: a candle of that timeframe CLOSES beyond level. range_breakout {low,high,timeframe,direction}: a candle closes outside the range. consecutive_closes {level,side,count,timeframe}: N consecutive closes above/below level. sweep_above / sweep_below {level,timeframe,maxCandles}: LIQUIDITY SWEEP (stop hunt / fake breakout): price wicks beyond a known level (previous day high/low, Asian session high/low, equal highs…) coming from the other side, and a candle of that timeframe closes back inside within maxCandles candles (1-10, default 3; the wick candle itself counts). sweep_above → typically a SELL; sweep_below → typically a BUY. fvg_retest {timeframe, direction bullish|bearish, maxCandles, entry, minGap}: FAIR VALUE GAP (FVG / imbalance, ICT/SMC) retest: three consecutive candles where the 1st and 3rd do not overlap leave a gap (bullish: 3rd low above 1st high; bearish: 3rd high below 1st low); it fires when a closed candle returns to the gap for the FIRST time (entry \"touch\" = reaches its near edge, default; \"midpoint\" = its 50%) without closing beyond its far edge. maxCandles = how recent the gap must be (3-100 candles, default 20); minGap = minimum gap size in price (e.g. 1.5 on gold), default any. bullish → typically a BUY with the stop below the gap (backtest stop type \"wick\" uses the gap's far edge); bearish → typically a SELL. Combine with filters (time_window for London/New York, compare for trend). at_time {at}: at a given ISO datetime. time_window {start,end}: only between HH:MM–HH:MM UTC. days_of_week {days}: only on those days. Time filters alone never trigger an order. LEVELS CAN BE REFERENCES instead of numbers (recomputed every minute, same as backtest_strategy): Asian/London/New York session high/low, previous day high/low/close, day_high/low N days ago, a custom HH:MM range, or an indicator (SMA, EMA, RSI, ATR, highest/lowest of N candles on M1-D1, closed candles only). compare {left, op, right}: compares two values (numbers or references), op above / below / crosses_above / crosses_below — e.g. trend filters: price above the D1 EMA 50, H1 RSI below 30; crosses_* can be the trigger (moving-average crossover). candle_direction {timeframe, direction bullish|bearish, shift}: the last closed candle of that timeframe (shift 1) closed up/down — e.g. \"yesterday was bullish\". Test the same rule first with backtest_strategy: the conditions are the same."Input schema / properties / conditions / items / properties / type / enumPrevious value: -[
- "price_above",
- "price_below",
- "crosses_above",
- "crosses_below",
- "close_above",
- "close_below",
- "range_breakout",
- "consecutive_closes",
- "sweep_above",
- "sweep_below",
- "at_time",
- "time_window",
- "days_of_week",
- "compare",
- "candle_direction"
-]New value: +[
+ "price_above",
+ "price_below",
+ "crosses_above",
+ "crosses_below",
+ "close_above",
+ "close_below",
+ "range_breakout",
+ "consecutive_closes",
+ "sweep_above",
+ "sweep_below",
+ "fvg_retest",
+ "at_time",
+ "time_window",
+ "days_of_week",
+ "compare",
+ "candle_direction"
+]backtest_strategycancel_broker_ordercancel_conditional_ordercancel_suggested_orderclose_positionconnect_ctradercreate_broker_accountcreate_conditional_orderdelete_account_groupdelete_auto_execution_configdelete_broker_accountdelete_conditional_orderdraw_chartexecute_tradeexecute_trade_multiget_account_groupsget_account_infoget_auto_execution_configget_broker_account_stateget_broker_accountsget_chartget_conditional_orderget_conditional_ordersget_ohlcget_positionsget_quoteget_risk_limitsget_suggested_ordersget_trade_resultsget_upgrade_urllist_symbolslist_timeframesmodify_broker_ordermodify_positionrun_conditional_orderset_account_groupset_auto_execution_configset_global_auto_executionsuggest_ordertest_broker_accountupdate_broker_accountupdate_conditional_orderAI-powered Pine Script v6 strategy generator built for prop-firm futures traders.
Trade Papertrade BTC and ETH perps from Claude, ChatGPT, Codex, Cursor and any MCP client.
LuxAlgo for AI agents: the Library, prop firms, Market Trackers, Edge Stats, and your Trade Journal
Design trading strategies with your AI and open them in a visual no-code Strategy Builder.
Add one secure layer between your agents and this server.
