Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

List deployments for the current user

list_deployments
Read-only

Returns 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.count is 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 one status value or by multiple statuses; 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

NameRequiredDescriptionDefault
limitNo
searchNo
statusNoOptional single status filter. Omit status to list all deployments.
statusesNoOptional multi-status filter. Use this instead of a comma-separated status string.
strategyIdNo
isRealMoneyNo
aiStrategyIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnlyHint it discloses batching behavior (one preprocessor call, parallel position lookups), how status="running" matches the Bots page Active & scheduled inventory including startup-state refreshes, that total/hasMore metadata is not evidence of missing rows, and that live.positions.count is only a hint, not proof of zero holdings. That is substantive behavioral context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The scoping and routing content is front-loaded, but the text is heavily repetitive: show_bot_activity is recommended three separate times, get_deployment_position_telemetry's zero-holdings caveat is restated in two consecutive passages, and the closing sentence repeats the earlier get_bot_performance guidance. Much of this could be compressed by half without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully enumerates the returned row shape (id, status, strategyName, revision, nested bot, broker metadata, errorDetails, schedule object, live object with performance/positions/account). It covers pagination, filtering, degradation, and reporting rules for partial pages, so an agent can call it and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 29%, and the description compensates heavily: use one status or multiple statuses, never comma-separated strings, omit both to list all, limit max 50 with pagination guidance, and that strategyId/aiStrategyId filters apply only when explicitly supplied (no implicit conversation-strategy filter).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: returns the user's deployments with per-row paper/live mode, linked broker and performance data. It immediately distinguishes the row-level inventory from siblings like show_bot_activity and get_deployment_position_telemetry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes away from place_trade/list_broker_credentials for order workflows, toward show_bot_activity for current account performance, toward get_deployment_logs for failure diagnosis, and toward get_deployment_position_telemetry for symbol-level holdings. It also states the fallback path (status="running" with a broad limit) when broker-snapshot tools return nothing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.