Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Manage saved variable sets (legacy)

env_var_sets
Destructive

Legacy multi-variable records. Prefer saved_env_vars, one variable per record. Raw values are never returned.

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

action="list": List saved variables (legacy)

No other fields required. Legacy compatibility tool. Prefer saved_env_vars(action="list"). Lists saved variable metadata for the authenticated user. Raw values are never returned. Use returned ids as start_deployment.envVarSetIds, update_deployment_revision.envVarSetIds or start_backtest.envVarSetIds for non-broker runtime secrets such as data-provider API keys. 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 variables (legacy)

Required fields: displayName, envVars. Legacy compatibility tool. Prefer saved_env_vars(action="create") and create one saved variable at a time. Stores environment variable values in Vault and returns only metadata for the authenticated user. Use this for non-broker runtime secrets such as data-provider API keys. Examples: {"APIFY_API_TOKEN":"..."}, {"OPENAI_API_KEY":"..."}, {"DATABENTO_API_KEY":"..."}, {"POLYGON_API_KEY":"..."}. Do not store broker credentials here when a saved broker credential can represent the broker connection. 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 variables (legacy)

Required fields: id. Legacy compatibility tool. Prefer saved_env_vars(action="update"). Updates saved variable metadata and optionally replaces Vault material for the authenticated owner. When envVars is provided, it replaces the saved record. Values are encrypted at rest and never returned to MCP.

action="enable": Enable saved variables (legacy)

Required fields: id. Legacy compatibility tool. Prefer saved_env_vars(action="enable"). Re-enables saved environment variables for future backtest/deployment secret injection.

action="disable": Disable saved variables (legacy)

Required fields: id. Legacy compatibility tool. Prefer saved_env_vars(action="disable"). Reversibly disables saved environment variables so they cannot be used for future backtest/deployment secret injection.

action="delete": Delete saved variables (legacy)

Required fields: id. Legacy compatibility tool. Prefer saved_env_vars(action="delete"). 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 record; detach every reference first.

Input Schema

NameRequiredDescriptionDefault
idNoUsed with action="update", action="enable", action="disable", action="delete". Required for action="update", action="enable", action="disable", action="delete".
actionYesWhich operation to run: "list", "create", "update", "enable", "disable", "delete". See the tool description for each one.
envVarsNoUsed with action="create", action="update". Required for action="create".
displayNameNoUsed with action="create", action="update". Required for action="create".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations it discloses that raw values are never returned, values are encrypted at rest in Vault, deletion is rejected while runtime preferences reference the record, and enable/disable are reversible. These are non-obvious mutation semantics the annotations (destructiveHint=true) do not 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?

Front-loaded with the legacy warning and action map, which is good, but the long reserved-name list is duplicated nearly verbatim in both the list and create sections, bloating an already lengthy description.

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?

Covers a destructive, multi-action mutation tool thoroughly with no output schema present — return metadata shape is described (displayName, keyNames, status, timestamps) but not field-by-field, leaving a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds much more: per-action required fields (displayName+envVars for create, id for update/enable/disable/delete), no extra fields for list, example envVars payloads, and the reserved key list that constrains valid envVars keys.

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 resource (legacy multi-variable environment variable records) and immediately names the preferred sibling saved_env_vars, so an agent can distinguish them without opening either schema. Each action is given a one-line purpose.

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?

Explicitly says to prefer saved_env_vars for every action, forbids using this for broker credentials (pointing at saved broker credentials instead), and prescribes where returned ids are consumed (start_deployment.envVarSetIds etc.). It also names the reserved-name exclusions and the LUMIBOT_SCHEDULED_* caveat, which is when-not-to-use guidance.

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