Skip to main content
Glama
Sign In

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. 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 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. For broker or exchange API keys, use the broker connection workflow and its provider-specific permissions guidance.

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.

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": "env_var_sets"
  }
}

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?

Annotations only say destructiveHint=true and readOnlyHint=false; the description goes well beyond that by disclosing Vault storage, that raw values are never returned, that update replaces rather than merges, that enable/disable is 'reversibly' scoped to future injection, and that delete is rejected while saved runtime preferences still reference the record. The reserved-name/prefix rejection list and the LUMIBOT_SCHEDULED_* warning add authentication/constraint context the annotations cannot express.

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 and front-loaded 'Prefer saved_env_vars' routing are good structure, but the long reserved-name/prefix block is duplicated verbatim under both list and create, and the LUMIBOT_* warning is repeated word-for-word. That repetition is a substantial share of the text and should live once in shared preamble.

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, the definition covers everything an agent needs: which fields each action takes, what is stored and never returned, which names are rejected, what happens on delete when references exist, and where the returned ids are consumed. The only minor gap is that return metadata is described for list but not for create/update.

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 baseline is 3; the description exceeds it by mapping fields to actions ('Required fields: displayName, envVars' for create, 'Required fields: id' for update/enable/disable/delete) and by illustrating the shape of envVars with concrete examples like {"POLYGON_API_KEY":"..."}. It stops short of describing merge/replace nuance for displayName or idempotency on repeated creates.

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 line states the resource ('Legacy multi-variable records') and immediately contrasts it with the sibling that should be preferred ('saved_env_vars, one variable per record'). Each of the six actions gets its own headed section with a specific verb, so an agent can distinguish list/create/update/enable/disable/delete without opening the schema.

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?

Explicit routing guidance is given at both tool and action level: 'Prefer saved_env_vars' for every operation, plus concrete when-not rules ('Do not store broker credentials here when a saved broker credential can represent the broker connection... use the broker connection workflow'). It also names the downstream consumers of returned ids (start_deployment.envVarSetIds, start_backtest.envVarSetIds).

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