Tradestaq Mcp

Log in to TradeStaq with email and password and store the returned access token locally. Simple credential login for automation and headless use; for interactive users prefer authenticate (browser OAuth, where credentials never enter the chat). Credentials are sent directly to the TradeStaq API over HTTPS and are not persisted — only the returned token is saved.

Log in to TradeStaq via browser. Opens a login page in your browser — you authenticate there and the token is saved automatically. No credentials enter the chat. Scope controls what the agent can do: "mcp:read" (view-only research agents), "mcp:paper" (paper-trade bots, safe default — cannot touch live money), "mcp:live" (full access including live-money deploys, live exchange connections, and wallet charges). Scopes are hierarchical: live implies paper implies read. When in doubt, pick paper first — the server returns 403 insufficient_scope if the agent tries a live action, and the user can always re-authorize with a broader scope.

Preflight check before invoking other tools. Returns the authenticated user, OAuth scope on the current token (mcp:read / mcp:paper / mcp:live), tier capabilities (allowLiveTrading, allowAIBuilder, allowNewsTrading, allowMcpServer), Strategy Lab wallet balance (for cost-charging tools like generate_strategy), and the OAuth client name/expiry. Agents should call this at the start of a workflow to pick the narrowest scope needed and to surface cost/balance to the user before committing to a charge. Response is cached server-side for 30s per token.

無需輸入參數。

Manually store a TradeStaq JWT access token instead of logging in through the browser. Advanced / automation use only — most users should call authenticate (browser OAuth) or login (email + password) instead. The token is saved locally to ~/.tradestaq/mcp-config.json with an assumed 7-day expiry. Use this when you already hold a valid token, e.g. in CI or a headless environment.

Connect a new exchange account via browser. Opens a page where you securely enter your exchange API keys. Keys never enter the chat.

無需輸入參數。

Remove the stored TradeStaq credentials from local config (~/.tradestaq/mcp-config.json), signing the user out. Also clears the cached OAuth client so the next authenticate registers cleanly — call this before re-authenticating with a different scope.

無需輸入參數。

Get the current price of a trading pair, along with its 24h change and volume, from a connected exchange. Use it for a quick spot-price check or to confirm the market before sizing or placing a trade. Read-only — never places orders. For historical OHLCV data use get_candles.

Fetch OHLCV (open/high/low/close/volume) candlestick data for a trading pair from a connected exchange. Use it to analyze price action, compute indicators, or ground a trading decision in real market data before backtesting or deploying a strategy. Returns the candles plus the latest candle and the high/low range over the window. Read-only — never places orders. Get exchange IDs from list_exchanges.

List your connected exchange accounts with their IDs, platform names, and status.

無需輸入參數。

Create a paper-trading exchange with a simulated balance. No API keys required. Paper exchanges let agents test strategies, deploy bots, and place trades without risking real money. Recommended starting point for first-time users and any scope=mcp:paper workflow. Requires OAuth scope mcp:paper or mcp:live. Session-cookie users (dashboard) can always call this.

Search for trading pairs on a specific exchange. Use list_exchanges to find your exchange IDs.

Get portfolio overview: total balance, exchanges, and active bots.

無需輸入參數。

Get all open trading positions with current PnL.

List available trading strategies — either the public marketplace or the user's own library. Supports filtering and sorting. Use it to discover strategies to backtest or deploy, or to find strategy IDs for get_strategy, compare_strategies, and deploy_bot. Read-only.

Get full details for a specific strategy by ID: description, market/timeframe, performance stats, rating, code, and parameters. Use it to inspect a strategy before backtesting, deploying, comparing, or editing with update_strategy. Read-only. Get IDs from list_strategies; use compare_strategies for side-by-side comparison and explain_strategy for a plain-English breakdown. `code` is included when you own the strategy (or it's a forkable community strategy you have access to); omitted otherwise.

Get a plain-English explanation of a strategy: what it does, risk profile, best market conditions.

Compare 2-5 strategies side by side on their key performance metrics: ROI, max drawdown, win rate, Sharpe ratio, rating, and active bot count. Use this to help a user choose between strategies from the marketplace or their own library before backtesting or deploying one. Read-only. Get strategy IDs from list_strategies.

Save a new trading strategy from existing TradeDroid strategy code to the user's library, so it can be backtested or deployed. Use this when you already have the code (hand-written or produced by generate_strategy). To create a strategy from a natural-language description instead of code, use generate_strategy. Returns the new strategy ID; validate it with what_if_backtest before deploying via deploy_bot.

Update one of your own strategies: metadata (name, description, category, market, tags) and/or its code. Writing `code` creates or updates a DRAFT version — the currently stable/live version keeps running unaffected. NOTE: `status` here only changes the strategy's publish/visibility state (draft->testing->live->listed) -- it does NOT promote a new code version to the stable channel bots actually run. To ship a code change to already-deployed bots, validate the new version with validate_strategy_version, then promote it with promote_strategy_version. Use get_strategy first to see current values and status. Get the strategy ID from list_strategies(owned:true); non-admins cannot edit a suspended strategy.

Generate a complete trading strategy from a natural-language description using AI (FORGE). Describe the idea and it writes runnable TradeDroid strategy code — no coding required — then saves it so you can validate with what_if_backtest and deploy with deploy_bot. The fastest path from idea to a deployable strategy. Note: AI generation is a paid, cost-bearing operation and can take up to ~2 minutes.

List the version history for one of your own official/authored TradeDroid strategies: every stored version with its validation status, and which channel (if any) it currently serves -- 'stable' is what every bot without a channel override actually runs, 'beta' and 'latest' are not live to bots. Use this to check whether a version you validated has passed, and to find the exact version ID to pass to promote_strategy_version. Read-only. Get the strategy ID from list_strategies(owned:true) or get_strategy.

Run TradeDroid's automated validation pipeline (syntax check, entry/exit logic check, quick real-data backtest) against the current latest/draft version of one of your own strategies. Required before that version can be promoted to the stable channel with promote_strategy_version -- promotion to stable is rejected until this passes. Async: this only starts the job, which can take from a few seconds up to ~1-2 minutes. Poll list_strategy_versions afterward and watch validationStatus go pending -> running -> passed|failed. Get the strategy ID from list_strategies(owned:true); get exchangeId from list_exchanges (any exchange you own works -- it only sources real historical candles for the backtest, no real orders are placed).

Promote a specific version of one of your own official/authored TradeDroid strategies to the stable or beta channel. Promoting to STABLE is the step that actually changes the code every bot on the default channel runs -- editing a strategy (update_strategy) or validating a version has NO effect on already-deployed bots until this is called. Promoting to stable requires that version's validationStatus already be 'passed' (run validate_strategy_version first, confirm with list_strategy_versions) -- rejected with a 400 otherwise. 'beta' has no validation gate. Confirm with the user before calling: this is an immediate, broad change affecting every bot on that channel at once, not just one bot.

Start a Strategy Lab optimization run on one of your own strategies: an AI mutation loop that repeatedly tweaks the strategy code, backtests each variant, and keeps improvements (walk-forward validated: trains on trainSplit of the window, validates on the rest). This is different from generate_strategy -- that writes one strategy from a description; this iteratively improves an EXISTING strategy you already own. Does not create new strategies. Wallet-charging: call once WITHOUT acknowledgeCost to get a cost estimate (no charge, nothing queued), confirm the spend with the user, then call again with acknowledgeCost:true to actually start. Requires the mcp:live OAuth scope. Only one run can be active per user at a time. When the run finishes, its best version is checked out of sample (on the part of the window it was not trained on). The best version becomes the strategy's latestVersion ONLY if it passes that check (single-pair runs: also when the check is inconclusive, e.g. too few out-of-sample trades). Otherwise -- it failed the check, or the run was cancelled -- the version is HELD: latestVersion and the bots following it are not changed, and get_optimization_status shows progress.verdict, progress.heldBecause and progress.heldVersionId (savedVersionId is absent). The strategy author can still accept a held version in the TradeStaq web app ("Use this version anyway"). Promoted to stable automatically ONLY if autoPromote:true AND the result clears a strict bar (see autoPromote param); otherwise use promote_strategy_version yourself once you like the result. MULTI-PAIR (basket) RUNS: pass symbols (primary first) to test every candidate on several pairs of the same exchange account and market type, so the result is not tuned to one chart. Pricing is the base per experiment plus an extra charge per extra pair per experiment, billed per pair actually evaluated. A multi-pair request always returns a cost_estimate first with a quoteId, the pairs, the maximum cost and esti

Check progress of a Strategy Lab optimization run started with start_optimization_run. Each experiment (AI mutation + backtest) typically takes 1-2+ minutes, so poll every 15-30 seconds rather than tightly looping. While the run is going, savedVersionId (once it appears) is the strategy version holding the best result found so far -- it is not the strategy's latestVersion yet. When status is completed, progress.verdict gives the out-of-sample result: on a pass (single-pair runs: also when inconclusive) savedVersionId is now the strategy's latestVersion -- inspect it with list_strategy_versions. A held run (failed check, or cancelled) has no savedVersionId; instead progress.heldVersionId is the held version and progress.heldBecause says why, latestVersion is unchanged, and the author can accept it in the TradeStaq web app ("Use this version anyway"). progress.cancelled is true for a cancelled run, and progress.stopReason says why a run stopped early (cancelled, time_budget, balance or data_unavailable_on_resume). If the run was started with autoPromote:true, check progress.autoPromoted (true if it was actually promoted to stable) and progress.autoPromoteSkippedReason (present and explains why if it wasn't); otherwise promote it yourself with promote_strategy_version if you like it. A completed or failed run stays queryable for 24 hours. MULTI-PAIR runs: progress.basket lists the pairs; progress.baselinePerAsset and progress.bestPerAsset give each pair's result, with the best version marked W/T/L (won, tied, lost) or cured against the original on that pair; progress.validation.perAsset and progress.validation.breadth give the out-of-sample check per pair and how many pairs passed; experiments[].perAsset is kept only on the best and the latest experiment (this tool asks for the summary view). While a run waits to start, queue gives its position and etaMinutes (estimated minutes until it starts). After an auto-promote, progress.autoPromote.untestedPairs lists pairs that

Cancel a Strategy Lab optimization run you started. Takes effect after the current experiment finishes, not instantly -- check get_optimization_status to confirm it actually stopped. Any best version found before cancellation is kept but HELD (latestVersion is not changed); get_optimization_status then shows progress.cancelled, progress.heldVersionId and progress.heldBecause, and the author can still accept it in the TradeStaq web app.

Inject live free-text steering into a running Strategy Lab optimization, e.g. "stop trying mean-reversion tweaks, focus on trend-following". Applies starting with the NEXT experiment, not the one currently in flight. Overwrites any previously-injected guidance for this run.

Run a backtest on a strategy. Async, may take 30-120 seconds. Returns full performance metrics.

Check status/results of a previously started backtest.

Get export links for a completed backtest. Returns CSV and PDF download URLs.

List all your trading bots with status and performance.

無需輸入參數。

Get detailed status, configuration, and live performance for a specific trading bot by ID. Returns its run status, the strategy/symbol/exchange it trades, whether it is paper or live, P&L, win rate, total trades, risk config (leverage, stop-loss, take-profit, position size) and, for a strategy bot, strategyConfig (version channel and the version it runs, preset, timeframe, execution mode, interval, parameter overrides: what update_bot can change). Use it to check how a deployed bot is doing. stopAfterClose.enabled = true means the bot will pause itself once its current position closes (set with update_bot); completedAt is when it last did. Read-only — to stop a bot use stop_bot or update_bot stopAfterClose. Get bot IDs from list_bots.

Explain what a strategy bot has been doing run by run: why it did or did not trade, which signals it queued or dropped, and which runs failed. Use it when a bot is not trading as expected, after get_bot_status. Read-only. Sections (pick with `include`): - runs (default): one entry per bot run, newest first. Fields: ts (run time, ms epoch), k (outcome kind, below), r (reason code, e.g. bar_wait, entry_backoff, timeout), bar (candle open time, ms), px (price), em (signals the strategy emitted), q (orders queued), dr (signals dropped), why (short reason codes for drops/skips), err (error text, truncated), sk (skipped runs folded into this entry since the previous one), ex (executor result for the queued orders: filled | blocked | ignored | failed), sn (spin number), ms (run duration). Also pendingSkips (bar_wait skips since the last entry: n, firstAt, lastAt, lastBar), lastSpin (at, status, nextAt, lastProcessedCandle), and earlyExits (runs that stopped before saving, by UTC day yyyymmdd then reason code, today and yesterday). - spinLogs (default): stored per-run records: status (success | no_signal | error | timeout), createdAt, spinNumber, executionTimeMs, price, signals {count, types}, error message. - live: the most recent in-memory runs (status, timestamp, spinNumber, executionTimeMs, signals, error, outcome in the runs format above) plus today's run summary counts (todaySummary). Outcome kinds (k): skipped_bar = waiting for the next candle close on an on-bar-close bot, normal and not a problem; skipped_other = the run was skipped for another reason (r says why, e.g. the bar was already claimed); no_signal = the strategy ran and wanted no trade; signal_queued = it emitted signals and orders were sent to the executor (q > 0); signal_dropped = it emitted signals but none were queued (why says why, e.g. entry_backoff after rejected orders); error = the run failed (r and err say why, e.g. runtime, timeout). Each section reports its own error if it cannot be loaded,

Deploy a strategy as a trading bot. Defaults to paper trading for safety — whether a bot trades real money is determined entirely by the exchange account it's attached to (not by the `live` flag alone), so this refuses to deploy if `live` doesn't match the target exchange's own paper/live status. Check an exchange's status with list_exchanges first, or create one with create_paper_exchange. The bot trades on the strategy's own timeframe unless you pass `timeframe`; omit `name` and the server names it.

Edit a deployed bot. One call can rename it, switch it to another strategy or apply a preset, change its timeframe, execution mode or run interval, set strategy parameters, change its version channel, and change its risk settings (leverage, position size %, stop loss, take profit), trade notifications or stopAfterClose. All of it goes in ONE update, so a strategy switch never lands half-done. Merging: the bot's current settings are fetched first and your changes go on top. Grouped settings (positionSizing, messaging, spinConfig, parameterOverrides) are merged, never wiped by a partial change. Size and leverage are NEVER changed unless you pass positionSizePercent / leverage, also when you switch strategy or apply a preset. Strategy switch (strategyId) and timeframe change need the bot to be FLAT: no open position and no working order. A bot that holds one is refused (OPEN_POSITION) and nothing is changed, because the new strategy would adopt a position it did not open (e.g. a long-only strategy inheriting a short). Pause it first with stopAfterClose:true (it keeps managing the position, opens nothing new and pauses once flat), wait until get_bot_status shows no openPosition, then switch. A switch starts the strategy state over and drops the old strategy's parameters, preset and stale owed exits; the new strategy runs its stable channel unless you pass versionChannel / pinnedVersionId. The bot keeps its status: a paused bot stays paused until you start_bot it. Preset (presetId): applies it as the dashboard does when you pick one: its strategy, parameter overrides, timeframe, execution mode / interval and version, with anything you pass explicitly on top. The same flat rule applies when it changes the strategy or timeframe. Scope: editing a paper bot needs mcp:paper; any change to a LIVE bot (rename, strategy, timeframe, parameters, risk) needs mcp:live. The server enforces it (INSUFFICIENT_SCOPE). Returns the resulting config (strategy, version and channel, time

Activate a bot so it starts opening new positions on its next scheduled interval. Newly deployed strategy bots come up in "paused" status by default — this is the step that actually starts them trading (paper or live, depending on the exchange it's attached to). Check state first with get_bot_status; find bot IDs with list_bots.

Stop a running trading bot immediately. The bot stops trading entirely: any positions it currently holds stay open but are left unmanaged (no stop loss / take profit handling, no strategy exits) — close those separately with close_position. For a graceful stop that keeps managing the open position and pauses once it closes, use update_bot with stopAfterClose: true instead. The bot and its config are kept and can be restarted later (with start_bot), so this is a reversible state change, not a delete. Check state first with get_bot_status; find bot IDs with list_bots.

Permanently delete a trading bot and its configuration -- irreversible, the bot cannot be recovered after this call. Refuses if the bot still has an open trade recorded (the delete itself doesn't close positions, so deleting it now would orphan that trade with nothing left to manage or close it) -- close_position and stop_bot it first. Confirm with the user before calling. Get bot IDs from list_bots.

Export a bot's trade history as structured data — every closed trade with entry/exit prices and P&L, plus a performance summary. Use it to review or report on how a specific bot has performed. Read-only. Get bot IDs from list_bots.

Close an open trading position by placing a market order — fully or partially. This moves real money when the position is live, so confirm intent with the user before calling. Find the exchangeId, symbol, and side with get_positions. Set percentage below 100 for a partial close. A position one bot holds is closed as that bot's close (its lots, its exit record). Reports what actually closed (size, price, PnL) as the server confirmed it; when nothing closed, it returns the server's reason as an error, never "closed". Each call sends its close once. After CLOSE_OUTCOME_UNKNOWN, CLOSE_UNCONFIRMED or CLOSE_IN_PROGRESS the position may already be closed: never call close_position again for it without checking get_positions first.

Get the user's closed trade history across exchanges — entry/exit prices, P&L, and holding duration per trade, with pagination. Use it to review past trades or answer questions about specific fills. Read-only. For aggregate metrics (ROI, win rate, Sortino) use get_performance_metrics instead.

Get aggregate trading performance metrics over a time range: ROI, win rate, total P&L, and Sortino ratio. Use it to summarize how the user (or a subset of their trading) is performing. Read-only. For a list of individual trades use get_trade_history.

Browse the leaderboard of top-performing traders you can copy.

Subscribe to copy a top trader's trades. WARNING: This commits capital to copy trading.

Suggest trading strategies matching your risk profile. Filters by risk tolerance, max drawdown, preferred assets, and minimum Sharpe ratio.

Get a market read for a symbol: trend direction, volatility level, and key support/resistance levels. Use it to inform a strategy or trade decision, or to ground market commentary in current conditions. Read-only — never places orders. Get exchange IDs from list_exchanges.