BotSpot: AI Trading, Backtests and Bots

Switch the conversation data source

set_data_provider

DestructiveIdempotent

Updates the active conversation to use the specified backtesting data provider.

AVAILABILITY AND SETUP: Read these constraints before selecting a provider. Do not probe a provider already declared OFF by calling this tool. Explain its known unavailability and the supported alternatives instead. Preserve the named setup page when explaining a connection requirement.

Theta Data ('theta_data') is OFF right now. Theta Data is not available on BotSpot right now. Never select it and never start a backtest on it. If the user asks for it, say plainly that it is not available and offer the alternatives below.
'alpaca' uses the user's connected Alpaca broker account for data. Never ask the user to add ALPACA_API_KEY or ALPACA_API_SECRET as environment variables: those names are reserved for broker connections. If Alpaca is not connected or needs reconnecting, send the user to the Broker Connections page.
For OPTIONS: BotSpot Auto has NO options data right now because Theta Data is off, and start_backtest refuses options strategies on 'botspot_auto'. Options backtests need the user's own data: 'alpaca' when the user has a connected Alpaca account (options history from February 2024), or 'polygon' with the user's own POLYGON_API_KEY. Ask the user which one before switching. If they have neither, explain how to connect an Alpaca account (a free one works) or save a Polygon key. BotSpot does not currently have IBKR options support.

IMPORTANT: Match the provider to the strategy's asset class requirements.

Available providers and their capabilities:

Alpaca (alpaca): stocks, options, crypto
BotSpot Auto (botspot_auto): stocks, options, crypto, futures, indexes
Custom Provider (custom): stocks, options, crypto, futures, indexes
DataBento (databento): futures
Kalshi (kalshi): prediction_contract
Polygon (polygon): stocks, options, crypto, indexes
ProjectX Futures (projectx): futures

RULES:

Match the provider to the strategy's asset class requirements
If the strategy requires an asset class the provider doesn't support, STOP and pick a compatible provider
BotSpot Auto is a managed asset-class router. Policy version: 2026-11-14. Current routes: default → ibkr, stock → ibkr, index → ibkr, option → thetadata, crypto → public, crypto_future → public, future → ibkr, cont_future → ibkr.
For STOCKS/INDEXES: Default to 'botspot_auto' (IBKR via router) unless the user explicitly requests a different provider (e.g., 'polygon' or 'alpaca')
For SPOT CRYPTO: Default to 'botspot_auto'. No broker connection or API key is needed: USD pairs use Coinbase public data, USDT pairs use Binance public data. Switch only when the user explicitly requests Polygon/Alpaca for spot crypto
For CRYPTO PERPETUAL/FUTURES: Default to 'botspot_auto'. No broker connection or API key is needed: perpetuals use Binance public data, with funding charged. Switch only when the user explicitly requests a compatible futures provider
For FUTURES: Default to 'botspot_auto' (IBKR via router) unless the user explicitly requests DataBento. If IBKR is missing/unsupported for the requested futures symbol/contract, recommend DataBento as the fallback (BYOK: the user must supply their own DataBento API key).
For a user's saved ProjectX futures connection, select 'projectx-' (Topstep: 'projectx-topstepx') and its dataConnectionId. History uses that owner's connection; never request reserved broker keys as environment variables. Coverage depends on the provider.
For prediction contracts, select 'kalshi'. Kalshi history is public: no broker connection, dataConnectionId or API key is needed to backtest (a connection is only needed to trade live). Use the contract's native ticker and YES/NO outcome, not the underlying stock or crypto price. Do not fabricate missing bars.
If user doesn't have required API keys for a BYOK provider, recommend 'botspot_auto' for stocks, indexes, crypto and futures, or 'custom'. For options, follow the OPTIONS rule above.
The 'custom' provider lets users supply their own data files

The tool will return capability validation warnings if there's a mismatch.

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": {
      "dataProvider": "<dataProvider>"
    },
    "name": "set_data_provider"
  }
}

Input Schema

Name	Required	Description
`dataProvider`	Yes
`customEnvVars`	No
`dataConnectionId`	No	Saved broker connection for Alpaca, Kalshi or ProjectX history; use its owner-scoped connection ID, never API keys.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / dataConnectionId / description

Previous value: -"Saved broker connection for ProjectX history; use its owner-scoped connection ID, never API keys."New value: +"Saved broker connection for Alpaca, Kalshi or ProjectX history; use its owner-scoped connection ID, never API keys."

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / dataConnectionId

Added value: +{
+  "description": "Saved broker connection for ProjectX history; use its owner-scoped connection ID, never API keys.",
+  "format": "uuid",
+  "type": "string"
+}

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations flag this as destructive, non-read-only and idempotent; the description goes further by covering auth requirements (Alpaca broker connection vs. BYOK keys), reserved env var names, coverage limits (options history from February 2024), and that validation warnings may be returned. The gap is that it never says what switching does to existing state or configuration beyond 'updates the active conversation'.

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?

It is structured with headers and bullets and front-loads the purpose, but it is heavily padded: the Theta Data unavailability is stated three times in a row, and 'match the provider to the strategy's asset class requirements' appears twice (IMPORTANT and RULES). The full router route table adds bulk of marginal value to the selection decision.

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 destructive, open-world switcher with no output schema and sparse schema descriptions, this covers availability, auth, asset-class fit, defaults and error behavior ('capability validation warnings') thoroughly. What's missing is what actually changes on switch and whether prior backtests/settings are affected.

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 only 33% (only dataConnectionId is documented in the schema), so the description must compensate, and it largely does: it enumerates every valid provider token, gives concrete naming ('projectx-topstepx'), and ties dataConnectionId to owner-scoped saved connections. customEnvVars is only implied through 'BYOK' and 'save a Polygon key' talk rather than named, which keeps 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 opening sentence gives a specific verb and resource: it updates the active conversation's backtesting data provider. That is clearly distinguishable from siblings like switch_active_strategy or set_strategy_requirements, which touch other aspects of the conversation.

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?

This is unusually explicit about when to pick which provider: per-asset-class defaults, explicit exclusions (never select theta_data, never probe an OFF provider), fallbacks when keys are missing, and routing to sibling pages (Broker Connections, API keys) for setup. It also tells the agent to ask the user before switching for options.

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.