Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

List backtests

list_backtests
Read-onlyIdempotent

Summarize recent backtests for the user, optionally scoped to a strategy or conversation. For the current attached strategy, use scope='strategy' and omit id, strategyId, and aiStrategyId. The server resolves the exact strategy from the scoped MCP token, avoiding copied-identifier errors. Supports server-side sorting via sortBy + sortOrder (default is createdAt desc). Use status to filter by one or more backtest statuses (comma-separated). Use offset+limit to page through full history (for example, limit=50 offset=0, then offset=50 for older runs). For lightweight summaries, includeArtifacts defaults to false; set includeArtifacts=true only when you need artifact manifests inline (artifact pages are capped to 10 rows). If a backtest status is initiated/in_progress/backtesting, only status/log diagnostics may be available; do not fetch trades.csv, indicators.csv, or stats.csv until the run reaches a terminal status. The response includes a 'Tool IDs' section listing full backtestId/revisionId/aiStrategyId/strategyId for each row so downstream tools can chain without manual lookup. For normal questions about 'this backtest', 'the backtest', or 'how did it do', select one relevant terminal run from this response and keep that same backtestId for every get_backtest_artifact, get_backtest_logs, and query_csv call in the answer. Only inspect multiple run ids when the user asks for all runs, a comparison, or a different named run. If the user or conversation history already gives an exact backtest id, list_backtests is optional discovery only and does not replace direct artifact/log inspection. If this response is empty, still use the explicit id with get_backtest_artifact/get_backtest_logs/backtest_status/query_csv when diagnosing that named run. Do not replace a user-provided backtest id with a newer or listed run unless the user asks for latest, comparison, or a different named run. IMPORTANT: Each backtest has TWO date concepts: (1) 'createdAt' = when the backtest was RUN (e.g., '2024-12-08T22:48:17Z'), (2) 'period'/'startDate'/'endDate' = the historical date RANGE the backtest covers (e.g., '2024-01-01 → 2024-12-01'). When user asks for 'most recent' or 'latest' backtest, use createdAt to determine recency, NOT the period. COMMUNICATION: When referring to backtests, NEVER use the backtest ID (meaningless to users). Instead describe it by WHEN it ran and WHAT it covers, e.g.: 'The backtest that ran at 5:48 PM covering Dec 2024 to Dec 2025...' Convert createdAt timestamps to the user's timezone for communication.

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_backtests"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoWith scope "all" (default): one exact backtest id; returns that run if you own or ran it, otherwise nothing. With scope "conversation": the conversation id. With scope "strategy": a strategy or aiStrategy id.
limitNo
scopeNoall
offsetNo
sortByNoServer-side sort field. Supported values: createdAt, totalReturn, cagrAnnualReturn, sharpe, maxDrawdown, status.createdAt
statusNoOptional comma-separated status filter. Valid values: initiated, in_progress, completed, completed_no_trades, failed, force_stopped, terminated_timeout, not_found, completed_with_errors. Do not use deployment-only statuses such as terminated. Example: completed,completed_no_trades.
sortOrderNoSort direction: desc (default) or asc.desc
strategyIdNo
aiStrategyIdNo
includeArtifactsNoInclude artifact manifests in each backtest item (default false to keep responses lightweight).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / id / description
      Added value: +"With scope \"all\" (default): one exact backtest id; returns that run if you own or ran it, otherwise nothing. With scope \"conversation\": the conversation id. With scope \"strategy\": a strategy or aiStrategy id."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses important behavior: server-side strategy resolution from the MCP token, sorting and paging defaults, artifact manifest caps, status diagnostics limitations, the 'Tool IDs' response section, empty-response handling, and the createdAt versus period date distinction.

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 front-loaded with purpose, but it is a long wall of text with repeated downstream-behavior instructions and communication guidance. Many sentences are useful, yet the overall length and lack of structure make it harder to scan than necessary for a list tool.

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?

For a 10-parameter discovery tool with no output schema, the description is complete: it explains what the response contains, how to chain results, how to handle empty results, and how to interpret dates. It leaves little ambiguity for an agent invoking this tool correctly.

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 50%, but the description compensates by explaining scope behavior, omitting identifiers for the attached strategy, sortBy/sortOrder defaults, comma-separated status filtering, offset/limit paging, and includeArtifacts defaults. It does not fully clarify when to use strategyId or aiStrategyId outside the attached-strategy case, so it falls just short of complete.

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 opens with a specific verb and resource: 'Summarize recent backtests for the user, optionally scoped to a strategy or conversation.' It clearly distinguishes this discovery tool from direct artifact/log tools and names the relevant downstream 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 gives explicit when-to-use guidance, including scope selection, direct-id handling, terminal-status gating, and when to inspect multiple runs versus one. It also names the alternatives (get_backtest_artifact, get_backtest_logs, query_csv, backtest_status) and the conditions that select them.

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.