Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Make and manage BotSpot API keys

api_keys
Destructive

Make, list, replace or revoke BotSpot API keys right in the chat, and approve a lumibot connect botspot login code. For a requested LumiBot project setup, action="create" returns connection.environment: choose a recognizable name, save those values directly in the authorized project environment or secret manager, preserve unrelated settings, and verify a research request. Keep the secret out of replies, Git, logs and command-line arguments; no additional CLI login or manual permission selection is needed for a signed-in owner. The secret appears once in the tool result; the default "lumibot_agent" preset gives a LumiBot AI trading agent free data (SEC filings, economic data, news headlines), Marketplace browsing and Community reading and posting, and nothing else. Keys never expire unless expiresInDays is set. action="presets" explains every preset in plain words. A key can never make keys or spend money. Only the signed-in person can use this tool.

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

action="presets": List API key permission presets

No other fields required. Shows the permission presets you can choose when making a BotSpot API key, with the exact permissions of each, in plain words. Presets: "lumibot_agent" (default; for a LumiBot AI trading agent: free data such as SEC filings, insider and 13F data, news headlines and economic data, Marketplace browsing, Community reading and posting; no deploys, backtests, trades, account, broker or billing), "research" (the same data and reads, no posting), "community" (Community only) and "custom" (pick scopes). A key can never make keys or spend money. Starting bots and real-money trades still need your separate approval click on botspot.trade even with a key.

action="create": Create a BotSpot API key

Required fields: name. Creates a BotSpot API key for the signed-in person, right here in the chat. The secret is shown once in this tool result. For a requested LumiBot setup, save it directly in the authorized project environment without printing it in your reply. BotSpot keeps only a fingerprint. Default preset is "lumibot_agent" (LumiBot agent), made for a LumiBot AI trading agent. Presets: "lumibot_agent" (default; for a LumiBot AI trading agent: free data such as SEC filings, insider and 13F data, news headlines and economic data, Marketplace browsing, Community reading and posting; no deploys, backtests, trades, account, broker or billing), "research" (the same data and reads, no posting), "community" (Community only) and "custom" (pick scopes). A key can never make keys or spend money. Starting bots and real-money trades still need your separate approval click on botspot.trade even with a key. Expiry is optional: the key never expires unless you pass expiresInDays (1 to 365). Free accounts can make keys. Up to 5 active keys per account. Choose a recognizable name yourself, use the default LumiBot preset, save connection.environment in the project environment or secret manager, and verify a research request. Preserve existing unrelated settings and keep the secret out of Git, logs, replies and command-line arguments. No extra CLI login is needed for an already signed-in owner session. If project file access is unavailable, explain the manual setup option.

action="list": List your BotSpot API keys

No other fields required. Lists the signed-in person's active API keys: name, first characters, permissions preset, expiry and last use. Never shows a secret.

action="rotate": Replace an API key with a new secret

Required fields: keyId. Makes a new secret with the same name, permissions and expiry, shows it once, and stops the old key immediately. Update every place that used the old key (for LumiBot: run lumibot connect botspot again).

action="revoke": Revoke an API key

Required fields: keyId. Stops an API key immediately. Anything using it loses access. This cannot be undone.

action="approve_device": Approve a LumiBot command-line login

Required fields: userCode. Approves (or denies) a login code shown by lumibot connect botspot or another BotSpot command-line tool. After approval, that tool receives a "LumiBot agent" key straight into its .env file; the key never passes through this chat. Only approve a code the person just started themselves and read to you; ask them to confirm the code before calling this.

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

Input Schema

NameRequiredDescriptionDefault
nameNoA name the person will recognize, e.g. "My LumiBot agent". Used with action="create". Required for action="create".
keyIdNoThe id from api_keys(action="list"). Used with action="rotate", action="revoke". Required for action="rotate", action="revoke".
actionYesWhich operation to run: "presets", "create", "list", "rotate", "revoke", "approve_device". See the tool description for each one.
presetNoPermission preset. Default lumibot_agent. Used with action="create".
scopesNoOnly with preset "custom": the exact tool permissions. Used with action="create".
decisionNoDefault approve. Used with action="approve_device".
userCodeNoThe code shown in the terminal, e.g. BCDF-GHJK. Used with action="approve_device". Required for action="approve_device".
expiresInDaysNoOptional. Leave out for a key that never expires. Used with action="create".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true; the description goes far beyond by disclosing that the secret is shown once and never again, that BotSpot keeps only a fingerprint, that revoke is irreversible, that rotate kills the old key immediately, that keys never expire unless expiresInDays is set, and that there is a 5-key-per-account cap. It also scopes the blast radius (a key can never make keys or spend money; bot starts and live trades still need a separate approval click), which is exactly the context a destructive-flagged tool needs.

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?

Structure is strong — front-loaded summary, then one clearly headed section per action. But the full preset enumeration (lumibot_agent/research/community/custom with permissions) appears verbatim three times: in the intro, again under `presets`, and again under `create`. That redundancy, plus a repeated 'a key can never make keys or spend money' line, bloats an otherwise well-organized description.

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, eight-parameter mutation tool with no output schema, the description covers what each action returns (key metadata for list, connection.environment for create, a delivered .env key for approve_device) and gives the agent an operational procedure for the LumiBot setup flow. Nothing material is missing for correct invocation.

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 genuinely adds cross-parameter semantics the schema cannot express: which fields belong to which action ('Only send the fields listed for that action'), that `name` is user-chosen and should be recognizable, that `custom` requires explicit scopes, and that `expiresInDays` is optional with a 1–365 range. It stops short of explaining the scopes array's accepted values, which is the one remaining gap.

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 names specific verbs and a specific resource (make, list, replace, revoke BotSpot API keys), plus the login-code approval case. The per-action sections then spell out exactly what each of the six operations does, so an agent can tell this apart from sibling tools like `account` or `broker_connections` 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?

Every action has an explicit label and required-field list, plus the routing sentence 'Set "action" to choose the operation.' It also gives real when-not guidance: 'Only approve a code the person just started themselves and read to you; ask them to confirm the code before calling this,' and routes agents to `action="presets"` to understand presets before choosing one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.