BotSpot: AI Trading, Backtests and Bots

Manage saved environment variables

saved_env_vars

Destructive

List, create, update, enable, disable, or delete saved environment variables (one variable per record). Raw values are never returned. Names BotSpot sets for its own runs, such as LUMIBOT_SCHEDULED_*, cannot be saved here.

Set "action" to choose the operation. Only send the fields listed for that action.

action="list": List saved environment variables

No other fields required. Lists saved environment variable metadata for the authenticated user. Raw values are never returned. Each item should normally represent one saved variable. Use returned ids as start_deployment.envVarSetIds, update_deployment_revision.envVarSetIds or start_backtest.envVarSetIds. Returned metadata includes displayName, keyNames, status, and timestamps only; it never includes raw values or Vault secret ids. Reserved runtime names and prefixes are rejected: AWS_*, BOTSPOT_*, BOT_MANAGER_*, DEPLOY_*, MCP_*, AUTH0_*, DB_*, DATABASE_*, CUSTOM_JWT_*, AI_SERVICE_*, PYTHON*, LD_*, DYLD_*, PIP_*, UV_*, ECS_*, NODE_API_*, LUMIBOT_SCHEDULED_*, LUMIBOT_LIVE_ARTIFACTS_*, BACKTEST_CACHE_*, plus PATH, PYTHONPATH, NODE_ENV, PORT, HOME, LD_PRELOAD and other interpreter controls. LUMIBOT_SCHEDULED_* and LUMIBOT_LIVE_ARTIFACTS_* values are set only by BotSpot for its own scheduled runs; never tell a user to save them or pass them through envVarSetIds, because BotSpot rejects them and the runtime ignores them.

action="create": Create saved environment variable

Required fields: variableName, value. Stores one environment variable value in Vault and returns only metadata for the authenticated user. Use this for non-broker runtime secrets such as data-provider API keys. Do not store broker credentials here when a saved broker credential can represent the broker connection. For broker or exchange API keys, use the broker connection workflow and its provider-specific permissions guidance. Reserved runtime names and prefixes are rejected: AWS_*, BOTSPOT_*, BOT_MANAGER_*, DEPLOY_*, MCP_*, AUTH0_*, DB_*, DATABASE_*, CUSTOM_JWT_*, AI_SERVICE_*, PYTHON*, LD_*, DYLD_*, PIP_*, UV_*, ECS_*, NODE_API_*, LUMIBOT_SCHEDULED_*, LUMIBOT_LIVE_ARTIFACTS_*, BACKTEST_CACHE_*, plus PATH, PYTHONPATH, NODE_ENV, PORT, HOME, LD_PRELOAD and other interpreter controls. LUMIBOT_SCHEDULED_* and LUMIBOT_LIVE_ARTIFACTS_* values are set only by BotSpot for its own scheduled runs; never tell a user to save them or pass them through envVarSetIds, because BotSpot rejects them and the runtime ignores them.

action="update": Update saved environment variable

Required fields: id. Updates saved variable metadata and optionally replaces its Vault value. Values are encrypted at rest and never returned to MCP. If variableName is omitted when replacing a value, the existing single key name is reused. For broker or exchange API keys, use the broker connection workflow and its provider-specific permissions guidance.

action="enable": Enable saved environment variable

Required fields: id. Re-enables a disabled saved environment variable record for the authenticated user. Enabled records can be used for future backtest/deployment secret injection. Raw values are never returned.

action="disable": Disable saved environment variable

Required fields: id. Reversibly disables a saved environment variable record for the authenticated user. Disabled records are not eligible for backtest/deployment secret injection or automatic selection, but metadata remains visible and can be re-enabled. Raw values are never returned.

action="delete": Delete saved environment variable

Required fields: id. Deletes saved variable material from Vault and marks the authenticated user's metadata row deleted. Deletion is rejected while any saved runtime preference still references the variable; detach every reference first.

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": {
      "action": "<action>"
    },
    "name": "saved_env_vars"
  }
}

Input Schema

Name	Required	Description
`id`	No	Used with action="update", action="enable", action="disable", action="delete". Required for action="update", action="enable", action="disable", action="delete".
`value`	No	Used with action="create", action="update". Required for action="create".
`action`	Yes	Which operation to run: "list", "create", "update", "enable", "disable", "delete". See the tool description for each one.
`displayName`	No	Used with action="create", action="update".
`variableName`	No	Used with action="create", action="update". Required for action="create".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations flag a destructive, non-idempotent, open-world tool, and the description adds substantial context beyond that: values are stored in Vault and encrypted at rest, delete destroys Vault material plus marks the metadata row, disable is explicitly reversible and only removes injection eligibility, enable restores it for future backtests/deployments, and list returns metadata (displayName, keyNames, status, timestamps) but never raw values or Vault secret ids. A long rejected-name denylist is also disclosed. This is well past what the annotations convey.

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 per-action headings make it scannable and the summary is front-loaded, but there is heavy duplication: the full reserved-name denylist is pasted verbatim twice, 'Raw values are never returned' appears four times, and the broker-credential caveat twice. Trimming the repeats would shorten the description by roughly a third without losing any 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?

For a six-action mutation tool with no output schema this is unusually complete: it describes what each action returns and does not return, the irreversibility of delete versus the reversibility of disable, retention of metadata after disable, and the referential precondition blocking deletion. Nothing an agent needs in order to choose and invoke an action safely 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 100%, so the baseline is 3, but the description adds real meaning on top: which fields belong to which action, that update optionally replaces the Vault value while keeping the existing single key name if variableName is omitted, and that the returned ids feed envVarSetIds on deployment/backtest tools. That behavioral coupling of parameters to downstream calls is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb set plus resource (saved environment variables, one variable per record) and immediately states two hard constraints: raw values are never returned, and BotSpot-reserved names cannot be saved. Each of the six actions is then named and scoped. It stops short of explicitly routing to the sibling env_var_sets, only alluding to it through 'use returned ids as start_deployment.envVarSetIds', so an agent must infer the grouping-vs-single distinction.

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?

Guidance is explicit at both the action level (required fields per action, and 'Only send the fields listed for that action') and the tool level (do not use this for broker credentials - use the broker connection workflow instead; do not pass LUMIBOT_SCHEDULED_* through envVarSetIds). The delete action adds a clear precondition: deletion is rejected while any saved runtime preference references the variable, so detach references first. When-to-use, when-not-to-use and the alternative are all present.

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