Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Create a new strategy workspace

create_strategy
Destructive

Creates a new strategy workspace with main.py and requirements.txt. The starter files are neutral boilerplate only; they do not encode customer-specific strategy logic or fake validation trades. After creation, use the returned files manifest instead of rediscovering starter paths. Use list_files for missing or stale discovery. Use replace_file, patch_file, and create_file to implement the strategy; each save result confirms what was saved and returns the revisionId to validate. When this user has not linked data that some asset class needs for a backtest, the result says so in backtestData. Before writing code, load BotSpot's free strategy-building skills: call skills (action=get, name=lumibot-strategy-building) and follow it, including existing plan progress and Rules; do not replace the plan merely to record workspace creation. For the first real main.py implementation after neutral starter creation, use replace_file with the main.py editHandle from the returned files manifest; no get_file is needed first. This is the default first-build path for BotSpot strategy creation after the user clearly asks to build/create/make/generate/implement/code a strategy, or asks to turn prior trading or competition rules into a clean/tighter/easier-for-agent prompt in this product flow. Do not use this tool when the current conversation/context already has an attached, current, open, or saved strategy/revision and the user asks to update, edit, fix, refine, change, or make that strategy buy/sell differently. For attached/current strategy edits, use get_file plus patch_file or replace_file on the existing revision, then read back the saved revision. Do not use this tool for advice, critique, feedback, risk assessment, review, planning, or 'what do you think' turns.

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

Input Schema

NameRequiredDescriptionDefault
nameYesRequired human-readable strategy title. Use natural words or title case, such as "Competition Risk Trader". Do not use slug-style, snake_case, kebab-case, file names, or lowercase underscore names such as competition_prompt_cleanup.
descriptionNoOptional notes for the initial revision

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), so the description's added value is the creation semantics: neutral boilerplate starter files, a returned files manifest to avoid re-discovery, revisionId confirmation on saves, and backtestData signalling missing linked data. That is substantial context beyond the annotations, though it never states whether creation fails or overwrites when a workspace already exists.

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 purpose is front-loaded in the first sentence, but the body is a dense block of routing directives with some redundancy ('do not replace the plan merely to record workspace creation', 'no get_file is needed first') and a convoluted clause about converting prior rules into a cleaner prompt. Every element is relevant, yet the whole would benefit from tighter phrasing and separation.

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 creation tool with two simple parameters and no output schema, the description covers the follow-on workflow (manifest, replace_file on the editHandle, skills call, revisionId validation) and the return-side signals (backtestData). Nothing an agent needs to invoke and then proceed correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already explains both the required name (natural title, no slug/snake_case) and optional description. The tool description adds nothing about either parameter, so the schema does all the work and the baseline of 3 applies.

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 gives a precise verb and resource ('Creates a new strategy workspace with main.py and requirements.txt') and immediately scopes what the starter files contain. It also names the sibling tools it is not (get_file/patch_file/replace_file for edits), so an agent can distinguish it without opening any 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 rules: it is the default first-build path when the user asks to build/create/implement a strategy, and it is explicitly excluded when a current or attached strategy exists and the user wants edits, with the correct alternative spelled out (get_file plus patch_file or replace_file on the existing revision). It also excludes advice, critique, review and planning turns, covering the main mis-invocation risks.

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.