Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Start a live deployment

start_deployment
Destructive

Prepares owner review for a new BotSpot deployment; this call does not start a bot or place trades before approval. After explicit owner approval, this is HIGH RISK: the deployment may place real-money trades. Call for an authorized start request even when required saved variables are missing: readiness validation returns the exact missing-variable secure entry cards. Preparing those cards is the next setup step, not a completed start or approval. Never request secret values in chat or claim a schedule was created by this preparation. For an extra iteration of an existing scheduled bot, use run_deployment_once; do not create another deployment. Never use this tool for a direct or one-off buy, sell, or order request. Use place_trade instead; a start_deployment approval is not a trade approval. When the user asks to run, start, turn on, or deploy an attached saved strategy, call this tool to create the website approval request; do not substitute a backtest. Omit brokerCredentialId by default unless the user explicitly named the exact saved broker connection/account to use now. The website approval page is the normal place for visible broker selection and blocks approval until a valid broker is selected. This tool accepts only saved references: aiStrategyRevisionId for code, optional brokerCredentialId for broker access, and optional envVarSetIds for saved non-broker runtime secrets. Broker access must come from a saved broker credential selected in the tool call or on the website approval page. Do not pass a broker credential whose status is reconnect_required. Omit brokerCredentialId and still create the start approval; the website approval page lets the owner select, add, or reconnect a broker before approving, including through /account-settings/broker-connections. Non-broker runtime secrets must come from saved environment variables: pass their ids as envVarSetIds. Do not pass raw broker credentials, raw environment variables, raw runtime configuration, inline code, requirements text, API keys, screener exports, CSV rows, JSON row dumps, workbook data, or large base64 blobs. Use create_broker_credential/list_broker_credentials before deployment, and use saved_env_vars(action="create")/saved_env_vars(action="list") for data-provider API keys or other non-broker runtime secrets. Broker credential key examples: Alpaca (alpaca): ALPACA_API_KEY + ALPACA_API_SECRET OR ALPACA_OAUTH_TOKEN. Do not pass ALPACA_IS_PAPER; BotSpot derives it from paperOrLive. Example credentialValues: {"ALPACA_API_KEY":"PK...","ALPACA_API_SECRET":"secret..."}. Tradier (tradier): TRADIER_ACCOUNT_NUMBER + TRADIER_ACCESS_TOKEN OR TRADIER_ACCOUNT_NUMBER + TRADIER_API_KEY OR TRADIER_ACCOUNT_NUMBER + TRADIER_TOKEN. Optional: TRADIER_REFRESH_TOKEN, TRADIER_OAUTH_CLIENT_ID, TRADIER_OAUTH_CLIENT_SECRET. Do not pass TRADIER_IS_PAPER; BotSpot derives it from paperOrLive. Example credentialValues: {"TRADIER_ACCOUNT_NUMBER":"6AB12345","TRADIER_ACCESS_TOKEN":"token..."}. Charles Schwab (schwab): SCHWAB_ACCOUNT_NUMBER + SCHWAB_TOKEN. Example credentialValues: {"SCHWAB_ACCOUNT_NUMBER":"123456789","SCHWAB_TOKEN":"base64url-token-payload..."}. Tradovate (tradovate): TRADOVATE_USERNAME + TRADOVATE_DEDICATED_PASSWORD + TRADOVATE_CID + TRADOVATE_SECRET. Optional: TRADOVATE_APP_ID, TRADOVATE_APP_VERSION. Do not pass TRADOVATE_IS_PAPER; BotSpot derives it from paperOrLive. Example credentialValues: {"TRADOVATE_USERNAME":"username...","TRADOVATE_DEDICATED_PASSWORD":"dedicated-password...","TRADOVATE_CID":"client-id...","TRADOVATE_SECRET":"secret..."}. TopstepX (projectx-topstepx): PROJECTX_TOPSTEPX_API_KEY + PROJECTX_TOPSTEPX_USERNAME. Optional: PROJECTX_TOPSTEPX_PREFERRED_ACCOUNT_NAME. Example credentialValues: {"PROJECTX_TOPSTEPX_API_KEY":"key...","PROJECTX_TOPSTEPX_USERNAME":"username..."}. WEEX (weex): WEEX_API_KEY + WEEX_API_SECRET + WEEX_API_PASSPHRASE. Example credentialValues: {"WEEX_API_KEY":"key...","WEEX_API_SECRET":"secret...","WEEX_API_PASSPHRASE":"passphrase..."}. Bitunix (bitunix): BITUNIX_API_KEY + BITUNIX_API_SECRET. Optional: BITUNIX_TRADING_MODE. Example credentialValues: {"BITUNIX_API_KEY":"key...","BITUNIX_API_SECRET":"secret..."}. Kraken (kraken): KRAKEN_API_KEY + KRAKEN_API_SECRET. Example credentialValues: {"KRAKEN_API_KEY":"key...","KRAKEN_API_SECRET":"secret..."}. Coinbase (coinbase): COINBASE_API_KEY_NAME + COINBASE_PRIVATE_KEY. Optional: COINBASE_API_PASSPHRASE, COINBASE_SANDBOX. Example credentialValues: {"COINBASE_API_KEY_NAME":"organizations/.../apiKeys/...","COINBASE_PRIVATE_KEY":"-----BEGIN EC PRIVATE KEY-----..."}. memoryGb may be 2, 3, or 4 when the user sets bot memory, including because the strategy needs a browser. Omit memoryGb to keep the current size. Do not send any other size, and do not send a CPU field. CPU stays as it is. Pass memoryGb only with deploymentMode scheduled. A 2, 3, or 4 GB always-on start is rejected because that larger host is not approved; tell the user that start was not placed instead of dropping the memory setting. The tool always creates a short-lived website authorization request and returns an approval URL the user must open while signed in to BotSpot. It does not execute from chat-only approval or reusable grants. No broker secrets are returned to the MCP response. For Codex, Claude, Cursor, and other clients without BotSpot native confirmation cards, return the exact authorizationUrl as a clickable Markdown link in your reply. Do not say a card or button was created unless the client actually rendered it. BotSpot clients may render structuredContent as a native confirmation, but a button name alone is not an approval link. A pending request is not execution; only the signed-in user may approve on the website. Report expiry and check get_deployment_action_status after approval.

Input Schema

NameRequiredDescriptionDefault
memoryGbNo
acceptancesNo
envVarSetIdsNo
idempotencyKeyNo
brokerCredentialIdNo
aiStrategyRevisionIdYes
strategyParameterSetIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only destructiveHint=true in annotations, the description carries the full behavioral burden and does so thoroughly: it discloses HIGH RISK real-money trading after owner approval, the website approval flow, short-lived authorization requests, that pending requests are not execution, that broker secrets are not returned, and memory-size rejection behavior. Nothing contradicts destructiveHint=true; the risk disclosure is consistent with it.

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 description is front-loaded with risk and usage guidance, but it is very long and includes extensive broker credential key examples and repeated secret-handling warnings that are not necessary to invoke start_deployment. The structure is useful for a high-risk tool, but many sentences could be trimmed without losing invocation-critical meaning.

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 complex, high-risk tool with no output schema and 0% schema description coverage, the description is largely complete: it explains the approval URL return, no-secret return behavior, expiry and status-check follow-up, and most parameter constraints. It is not fully complete because a few schema parameters, notably acceptances, idempotencyKey, and strategyParameterSetId, are left undocumented.

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 0%, so the description must compensate. It explains aiStrategyRevisionId, brokerCredentialId, envVarSetIds, and memoryGb in detail, including defaults, constraints, and rejection behavior, but it does not mention acceptances, idempotencyKey, or strategyParameterSetId.

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 action and resource: preparing owner review for a new BotSpot deployment, while explicitly clarifying that it does not start a bot or place trades before approval. It distinguishes the tool from siblings such as run_deployment_once, place_trade, and backtest substitution.

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 and when-not-to-use guidance, including calling it for an authorized start request even when variables are missing, using run_deployment_once for extra iterations, and using place_trade instead for direct order requests. It also tells the agent not to substitute a backtest and to omit brokerCredentialId by default.

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 toolsInspect
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.

Resources