BotSpot: AI Trading, Backtests and Bots

Show bot activity

show_bot_activity

Read-onlyIdempotent

For a general activity or trading-today summary, call this before separate order telemetry, run history or logs. Inspect its returned dated account, holdings and orders first, then fetch only missing decision details. Daily price attribution requires loading data-analysis and using validate_analysis_program followed by run_data_analysis, including when prices came from public search. Publish the computed opening and ending account values and the known-position subtotal, separately from an unknown full-basket total when a symbol is missing. Re-reading recorded position telemetry does not refresh broker holdings already shown in this report. When a current financial read is unavailable but an earlier tool result supplies a dated account value or cash, begin the interpretation with that last-known value and its original date, clearly labeled as not a current broker read. State the current uncertainty separately; an unavailable report does not erase earlier recorded evidence. Answers "How is my bot doing right now?" and "What did my bot do?" for one deployment. Already renders account value and holdings with signed unrealized P&L, followed by recent orders when available with their actual dates. Reuse these panels; do not add watchlist or risk-budget panels to restate account performance or holdings. This is the first financial read after list_deployments, before separate broker balance or position reads, even when discovery values are old. Reads current balances and account holdings directly from its exact linked broker, with source/retrieval timestamps; account-wide holdings and account-value change are not strategy-only profit. Uses recorded bot telemetry for orders and history, preserving their separate times. Live or paper comes from the deployment. Do not duplicate successful current reads. If current broker balances or holdings are unavailable and only recorded data is returned, recover once with get_broker_account_snapshot/get_broker_positions using that deployment's exact brokerCredentialId; never restart the trading bot to refresh prices. To explain a daily portfolio move, supplement this report with matching per-symbol price changes and estimated position contributions; since-entry P&L and a hold decision do not provide daily attribution. Recorded order history does not verify later broker activity. Use logs/run artifacts for decision explanations, not redundant cross-checks. Read-only. Shows an interactive panel in apps that support MCP Apps; always returns a text summary and a botspot.trade link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "deploymentId": "<deploymentId>"
    },
    "name": "show_bot_activity"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`deploymentId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, and the description goes beyond them: it discloses that balances come directly from the linked broker with source/retrieval timestamps, that orders come from recorded telemetry with their own timestamps, that a text summary and botspot.trade link are always returned, and that recorded position re-reads do not refresh broker holdings. It also documents the degraded path when a live broker read is unavailable. The only shortfall is that the fallback narrative is embedded in dense prose rather than clearly separated from primary behavior.

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 text is a sprawling multi-sentence block that mixes core behavior with extended workflow policy about daily price attribution, validate_analysis_program/run_data_analysis, opening/ending value reporting, and unknown-basket subtotals — much of which reads as unrelated analysis guidance. The core 'what this returns and when to call it' points are not front-loaded or separated from these digressions, making it hard to scan.

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

Completeness3/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 does cover return shape (rendered panels, text summary, link) and failure handling, which is appropriate for the tool's complexity. However, it omits any treatment of the limit parameter and spends a large share of its length on analysis-program and price-attribution instructions that do not help an agent invoke this tool correctly, leaving completeness uneven.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden of explaining the two parameters. It conveys that deploymentId identifies 'one deployment' and that live/paper comes from the deployment, but the limit parameter (default 20, max 50) governing how many recent orders are returned is never mentioned, leaving an agent to guess its effect and valid range.

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?

The description names the concrete output (account value, holdings with signed unrealized P&L, recent orders) and frames the tool as the answer to 'How is my bot doing right now?' for one deployment. It explicitly positions itself relative to siblings — before broker balance/position reads, before order telemetry, run history, and logs — so an agent can distinguish it from get_broker_account_snapshot, get_broker_positions, and the log/artifact tools.

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?

It states when to call it first (after list_deployments, before separate broker or telemetry reads), when not to duplicate it ('Do not duplicate successful current reads', 'never restart the trading bot to refresh prices'), and which alternatives to use for adjacent needs (get_broker_account_snapshot/get_broker_positions for recovery, logs/run artifacts for decision explanations). Exclusions and alternatives are explicit rather than implied.

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.