List deployments for the current user
list_deploymentsReturns the user's deployments with each row's own paper/live mode, linked broker and performance data. Never transfer performance between same-named paper and live deployments; an unavailable live return stays unknown. Do not use this tool to prepare or route a direct buy, sell, or one-off order request; use list_broker_credentials and place_trade for that workflow. Each deployment includes: id, status (running/stopped/failed/in_progress/deploying/starting/stopping/etc.), strategyName, revision version, nested bot object (id, name, isRealMoney, isPublic), broker metadata (broker, paperOrLive, saved credential display name/account id when available), timestamps, errorDetails, a schedule object for scheduled deployments (health, backend status, lastRunStatus, last run timestamps, schedule backend/status), A scheduled launcher can intentionally precede strategy execution by its configured preStartSeconds. A historical skipped run is not proof that its cadence is incorrect. AND a live object containing:
live.performance.stats: trimmed to returnAll/return1y/return6mo/return3mo/return30d/return7d/return24h timeframes with complete data. Each stat has total_return, max_drawdown, volatility (as % with snake_case canonical field names).
live.positions.count: current holdings count
live.positions.lastUpdated: timestamp of the most recent position snapshot
live.account: latest account snapshot with portfolio value, cash, timestamp, and found flag The live data is batched (one call to the preprocessor, parallel position lookups) so a single list_deployments call answers 'how are my bots doing?'. For 'is this bot live/running?' or Active inventory checks, use status="running" or omit status; the server matches the Bots page Active & scheduled inventory by including scheduled bots and refreshing startup states like deploying before returning results. If broker-snapshot tools return no accounts, no positions, stale data, or unavailable telemetry while the user asked for actual positions/holdings, this tool is the fallback discovery path for live-bot positions; call it with status="running" and a broad limit before concluding there is no live position evidence. When the user asks for all/running deployments, enumerate every returned row in items[] with its status and strategyName or bot.name; do not collapse them into 'same strategy' if a row-level answer was requested. Count and name only rows returned by items[] in this tool call unless additional pages were fetched; total/count/hasMore/nextToken metadata is not evidence of missing deployment names. If total is larger than returned rows and no additional page was fetched, say the answer is limited and list only the returned rows. For current account performance and holdings of a specific bot, call show_bot_activity first. It reads the exact linked broker balances and account holdings while keeping recorded bot orders separate. Do not repeat its telemetry via get_deployment_position_telemetry, get_bot_performance, or get_portfolio_series. If its current broker read is unavailable, recover once with get_broker_account_snapshot and get_broker_positions using this row's broker.brokerCredentialId.
live.positions.countis only a summary hint. It is not a symbol-level holdings answer and it is not proof of zero holdings. A current linked-account report is not a request for bot-attributed telemetry; answer that scope with show_bot_activity, without a preliminary historical positions read. Only for an explicit bot-attribution question or a correction of deployment summary counts, call get_deployment_position_telemetry for every deployment whose recorded holdings you will report, including deployments you intend to describe as zero; do not final-answer from this summary count. Only an explicit get_deployment_position_telemetry empty positions result proves zero holdings for that deployment. For live-vs-code discrepancy questions, an empty deployment list only limits live evidence; it is not a substitute for saved-code inspection or LumiBot source lookup. For failed, unhealthy, or attention-required deployment diagnosis, this inventory is not authoritative failure-log evidence: call get_deployment_logs for the exact deployment before reading or editing saved strategy code. status, schedule health, and errorDetails do not replace the logs. Filter by onestatusvalue or by multiplestatuses; omit both to list all deployments. Do not pass comma-separated status strings. Also supports isRealMoney, strategyId, aiStrategyId, or free-text search. A strategy attached to the conversation does not implicitly filter this inventory; strategy filters apply only when explicitly supplied. Paginate with limit (max 50). For current account performance use show_bot_activity; get_bot_performance provides recorded historical metrics across timeframes.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | ||
| status | No | Optional single status filter. Omit status to list all deployments. | |
| statuses | No | Optional multi-status filter. Use this instead of a comma-separated status string. | |
| strategyId | No | ||
| isRealMoney | No | ||
| aiStrategyId | No |