BotSpot: AI Trading, Backtests and Bots

Get backtest artifact (auto-uses Parquet when available)

get_backtest_artifact

Read-onlyIdempotent

For a live or scheduled deployment, use get_deployment_logs for runtime logs and list_deployment_artifacts/query_deployment_artifact for decisions, preserving the discovered deploymentId and runId. A deploymentId or deployment runId is not a backtestId. Request a short-lived download URL for a specific BACKTEST non-log artifact (tearsheet, trades, indicators, stats, agent_detail, completion JSON, etc.). Files your own strategy writes are artifacts too: anything the strategy writes under logs/outputs/ during a backtest appears with the label outputs/ (for example outputs/timings.csv), and a run started with start_backtest profile=true has profile_yappi.csv. Those two kinds are owner-only: they are available when you own and can see the strategy code, not for linked, shared or marketplace strategies. Runtime logs are not artifacts; use get_backtest_logs for backtest runtime errors, warnings, tracebacks, order/fill log lines, startup lines, and strategy log output. Tool availability is already supplied by tools/list; never probe it with all-zero ids or dummy labels. For Marketplace live performance, use marketplace_strategies live/performance fields, not backtest artifacts. Missing live windows stay unavailable and do not require an artifact call. backtestId must be an actual backtest run id from list_backtests or an explicit user-provided backtest id; never pass a strategy id, aiStrategyId, revisionId, browser URL revisionId, conversation id, or placeholder such as . If you only have strategy/revision context, call list_backtests(includeArtifacts=true) first and select the relevant completed run. Once selected, keep that same backtestId for all artifacts/log calls in the answer unless the user explicitly asked to compare multiple runs or analyze a different named run. Do not mix stats/trades/agent_detail/log evidence from different backtest ids. Artifact absence is a normal result, not a tool crash: if a file has not been produced yet (common while a backtest is still running) the response returns structuredContent.unavailable=true with the backtest status and available artifact labels. IMPORTANT: When Parquet versions exist, this tool automatically serves them instead of CSV for much faster performance. The response says which format was served; that is an internal detail, not something to tell the user. ⚠️ CRITICAL FOR DATA FILES: This tool returns ONLY the schema (column names, types, nullCount, sample rows) - NOT the full data! The csvSchema tells you what columns exist, their types, and how many NULL values each has (nullCount). Check nullCount to identify columns that may have NULLs for certain row types. Sample rows show diverse bounded examples across different values (not just first N rows). Long preview values are shortened and the preview is not the full data. For JSON artifacts, this tool inlines parsed JSON as structuredContent.jsonContent when the file is reasonably small. To actually ANALYZE the data, you MUST follow up with query_csv to run a SQL query. Calling get_backtest_artifact alone does NOT count as 'analyzing' the CSV - you have only seen metadata/previews, not enough row-level evidence. Do not patch strategy code from list_backtests.errorDetails, backtest_status text, or this artifact preview alone when query_csv is visible. For debugging/diagnostics, call get_backtest_logs. This tool intentionally rejects runtime log labels so diagnostics do not lose context through filtered log CSV artifacts.

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": {
      "backtestId": "<backtestId>",
      "label": "<label>"
    },
    "name": "get_backtest_artifact"
  }
}

Input Schema

Name	Required	Description	Default
`label`	Yes	User-facing artifact label from list_backtests/includeArtifacts or get_backtest_artifact guidance, e.g. stats.csv, trades.csv, agent_detail.parquet, tearsheet.html, completion.json. Runtime logs are not artifacts; use get_backtest_logs.
`backtestId`	Yes	Actual backtest run UUID. Use the id returned by list_backtests or an explicit user-provided backtest id. Do not use a strategy id, aiStrategyId, revisionId, browser URL revisionId, conversation id, or a placeholder such as <unknown>.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses several behaviors an agent could not otherwise infer: short-lived download URLs, automatic Parquet substitution for CSV, structuredContent.unavailable=true when an artifact is missing (normal, not a crash), and owner-only access for strategy-written files under logs/outputs/. It also discloses a real limitation — data files return only schema, nullCount and sample rows, not full data.

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

Conciseness3/5

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

The critical warning about schema-only data files is buried after deployment routing, marketplace notes and id rules, so the most important fact is not front-loaded. Several warnings are duplicated across the description and the input schema (runtime logs are not artifacts, no placeholder ids, keep the same backtestId), which inflates length without adding 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 still explains the response shape (csvSchema with column types and nullCount, sample rows, structuredContent.jsonContent for JSON artifacts, unavailable flag with backtest status). For a two-parameter read tool with rich annotations, nothing an agent needs to call it correctly is missing.

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 coverage is already 100%, so the baseline would be 3; the description adds genuine meaning with label conventions not obvious from the schema (outputs/<path> for strategy-written files, profile_yappi.csv for profile=true runs) and a strong constraint on what a valid backtestId is. It does not add format or syntax detail for the label beyond examples, keeping it short of a 5.

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 states a specific verb and resource: "Request a short-lived download URL for a specific BACKTEST non-log artifact (tearsheet, trades, indicators, stats, agent_detail, completion JSON, etc.)." It also names what it is not — runtime logs, deployment artifacts, marketplace live performance — so an agent can distinguish it from siblings like get_backtest_logs and query_deployment_artifact without opening a schema.

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 routing: use get_deployment_logs for live/scheduled runtime logs, get_backtest_logs for diagnostics, query_csv to actually analyze data, and list_backtests(includeArtifacts=true) when only strategy/revision context exists. It also states exclusions (never pass strategy id, revisionId, conversation id, placeholders) and a consistency rule (keep one backtestId across the answer unless comparing runs).

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.