BotSpot: AI Trading, Backtests and Bots

Start a strategy parameter experiment

start_parameter_experiment

Destructive

Start 2-10 parameter variants against the same saved revision, same date window, and same current BotSpot Auto routing policy. BotSpot creates or resolves one immutable strategy parameter set per variant and starts the runs in parallel with bounded concurrency through the normal backtest entitlement and runtime path. Use this when the user asks to compare parameter values; do not edit strategy code between variants. Read the saved strategy first and use the exact parameter key from the saved strategy code, including its casing; never rename, uppercase, or infer a different environment-variable-style key. The result returns an experiment id, exact revision id, parameter-set ids, routing-policy snapshot, every successfully started backtest id, and any start failures. This tool does not return an externalWaitId: do not invent one or call record_external_wait_in_plan for the experiment id. In a BotSpot chat you are woken once, when the last run ends, with every run in parameterExperiment.runs: end your turn after starting and compare then, unprompted. Elsewhere, read backtest_status until every run is terminal. Report failures or missing artifacts and compare the complete set on the same window. On a plan with a backtest minute limit, runs that do not fit in the minutes left are not started and are listed in notStartedForMinutes. Do not blindly recommend the highest in-sample return; include drawdown, risk-adjusted metrics, trade count, parameters, and observed data provenance, then recommend out-of-sample or walk-forward validation. This always uses the conversation data provider; no dataProvider or raw botConfig input is accepted.

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": {
      "startDate": "<startDate>",
      "endDate": "<endDate>",
      "variants": "<variants>"
    },
    "name": "start_parameter_experiment"
  }
}

Input Schema

Name	Required	Description
`budget`	No	Starting cash for the backtest (in the quote currency, typically USD). Sets BACKTESTING_BUDGET in the backtest environment.
`endDate`	Yes	The last calendar day to simulate, inclusive. Preserve the requested last date; do not add a day as though this were an exclusive upper bound.
`variants`	Yes
`startDate`	Yes	The first calendar day to simulate, inclusive. Preserve the user-requested date, normally YYYY-MM-DD.
`revisionId`	No
`envVarSetIds`	No	Saved BotSpot environment variable IDs to inject into the backtest runner. The MCP server never reads or exposes the saved values; BotSpot issues a short-lived runtime secret for the backtest.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / endDate / description

Added value: +"The last calendar day to simulate, inclusive. Preserve the requested last date; do not add a day as though this were an exclusive upper bound."

addedInput schema / properties / startDate / description

Added value: +"The first calendar day to simulate, inclusive. Preserve the user-requested date, normally YYYY-MM-DD."

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare mutation, non-idempotency, and open-world behavior, but the description adds substantial context they cannot: one immutable parameter set per variant, bounded-concurrency parallel execution through the normal entitlement path, the wake-once chat behavior versus polling elsewhere, and the minute-limit failure mode that lands runs in notStartedForMinutes. It stops short of describing cost or partial-rollback semantics if some starts fail, which is the only meaningful gap.

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

Conciseness4/5

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

Front-loaded with what the tool does and when to use it, then ordered through parameter naming, return payload, wait semantics, failure handling, and result interpretation. It is dense and long, and the closing recommendation guidance is arguably advisory rather than definitional, but no sentence is redundant.

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 enumerates the return payload (experiment id, revision id, parameter-set ids, routing-policy snapshot, started backtest ids, failures) and explains the polling and wake-up protocols. For a destructive, non-idempotent, six-parameter tool, an agent has everything needed to call and follow up 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 coverage is 67% and the description adds real meaning beyond it: the parameter key must match the saved strategy code exactly including casing, variants map to one immutable parameter set each, and no dataProvider or botConfig input exists. It leaves budget and envVarSetIds largely to their schema text, so it improves on the baseline without fully compensating.

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?

States a specific verb and resource (start 2-10 parameter variants against the same saved revision, date window, and routing policy) and scopes it precisely enough to separate it from start_backtest, which has no variant sweep. An agent can identify the tool from the first sentence alone.

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?

Gives explicit trigger ('when the user asks to compare parameter values'), an explicit prohibition ('do not edit strategy code between variants'), a prerequisite ('read the saved strategy first and use the exact parameter key'), and a negative route ('do not call record_external_wait_in_plan for the experiment id'). It also states that no dataProvider or raw botConfig input is accepted, closing off a likely wrong call.

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.