BotSpot: AI Trading, Backtests and Bots

List deployments for the current user

list_deployments

Read-onlyIdempotent

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_deployments"
  }
}

Input Schema

Name	Required	Description
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: live data is batched in one preprocessor call with parallel position lookups, the server refreshes startup states like 'deploying' to match the Bots page Active inventory, scheduled launchers can precede execution by preStartSeconds, and pagination caps at 50. However, much of the remaining text is agent answer-formatting policy ('enumerate every returned row in items[]', 'Count and name only rows returned') rather than tool behavior, which inflates the section without adding invocation guidance.

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 description is roughly 500 words of run-on prose with nested bullets, mixing field documentation, routing rules, and multi-sentence directives about how the agent should phrase its final answer and count rows. The return-shape documentation is useful but is interleaved with answer-formatting policy that does not belong in a tool definition, making the definition hard to scan. Front-loading is decent (purpose first, exclusions second) but the sheer volume violates the 'every sentence earns its place' bar.

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

Completeness4/5

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

For a 7-parameter read tool with no output schema, the description supplies the return shape in detail (schedule object, live.performance.stats timeframes and fields, live.positions.count vs symbol-level holdings, live.account snapshot with found flag), which is what the agent most needs. It also covers the caveats that prevent misreading the data (count is a hint not proof of zero holdings; total/nextToken is not evidence of missing names). It is over-complete rather than incomplete — the redundant answering directives could be trimmed without losing invocation-critical information.

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

Parameters4/5

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

Schema description coverage is only 29% (status and statuses are documented; limit, search, strategyId, aiStrategyId, isRealMoney are not), so the description must compensate and largely does. It states the mutual-exclusivity rule ('Filter by one status value or by multiple statuses; omit both to list all'), warns 'Do not pass comma-separated status strings', notes limit max 50, enumerates the other filter dimensions, and adds a crucial caveat that a conversation-attached strategy does not implicitly filter the inventory. Deduction for not clarifying what 'search' matches against.

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

Purpose4/5

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

The opening sentence states a specific verb and resource — 'Returns the user's deployments with each row's own paper/live mode, linked broker and performance data' — and the field enumeration (id, status, strategyName, schedule, live.performance.stats, live.positions, live.account) makes the resource concrete. It clearly separates itself from siblings like show_bot_activity and get_deployment_logs. It loses a point because the core purpose statement is immediately buried under paragraphs of routing rules, so an agent must parse a lot of noise to extract 'what does this do'.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not-to-use with named alternatives: '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 current account performance and holdings of a specific bot, call show_bot_activity first', and 'for failed, unhealthy, or attention-required deployment diagnosis... call get_deployment_logs'. It also names the fallback path (get_broker_account_snapshot/get_broker_positions) when broker telemetry is stale, and specifies status="running" for Active inventory checks — far beyond the minimum.

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

All BotSpot: AI Trading, Backtests and Bots tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.