BotSpot: AI Trading, Backtests and Bots

Create a strategy file

create_file

Destructive

Creates a file in a new immutable revision for any strategy owned by the authenticated user. For the current attached workspace, omit strategyId and revisionId. When create_strategy attaches the workspace through conversationUpdate, these defaults also apply to new first-build files. If creation returned no conversationUpdate, copy the exact returned strategyId/revisionId pair. Provide exactly one of content or attachment. For user-requested exact upload import, use attachment: {messageId, attachmentId} from attachments(action="list"); the server preserves original UTF-8 bytes and returns size/hash evidence. Read the new file back with get_file. Do not invent unavailable upload contents or import files without user intent. Use only for files that do not already exist; do not use this to update main.py or requirements.txt after create_strategy. Use replace_file for replacing an existing file and patch_file for small exact edits. For plan-driven first-build work, make the visible implementation item in_progress with update_plan_item before using file tools so the user sees the current plan step while file work runs. Use paths like lib/helpers.py or data/symbols.csv for folders. Default to the active strategy unless the user explicitly asks for another owned strategy.

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

Input Schema

Name	Required	Description
`path`	Yes
`content`	No
`attachment`	No	Exact original upload to import instead of model-transcribed content. Use only when the user requested this import.
`revisionId`	No	Base revision ID to snapshot from. Omit with strategyId for the current attached/open strategy.
`strategyId`	No	Base strategy id. Omit with revisionId for the current attached/open strategy so the server uses the conversation's latest saved revision.
`description`	No	Shown to the customer as "How your strategy works". One or two plain sentences on what the strategy now does, e.g. "Buys Apple after a 5% drop in a day and sells at a 10% gain." Write for the customer, not an internal change note.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

addedInput schema / properties / description / description

Added value: +"Shown to the customer as \"How your strategy works\". One or two plain sentences on what the strategy now does, e.g. \"Buys Apple after a 5% drop in a day and sells at a 10% gain.\" Write for the customer, not an internal change note."

Changed6 schema fields changedOct 28, 2026

addedInput schema / properties / revisionId / $ref
```
Added value: +"#/properties/strategyId"
```

changedInput schema / properties / revisionId / description

Previous value: -"Base revision ID to snapshot from"New value: +"Base revision ID to snapshot from. Omit with strategyId for the current attached/open strategy."

removedInput schema / properties / revisionId / format
```
Removed value: -"uuid"
```
removedInput schema / properties / revisionId / type
```
Removed value: -"string"
```

addedInput schema / properties / strategyId / description

Added value: +"Base strategy id. Omit with revisionId for the current attached/open strategy so the server uses the conversation's latest saved revision."

changedInput schema / required

Previous value: -[
-  "strategyId",
-  "revisionId",
-  "path"
-]New value: +[
+  "path"
+]

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already flag non-readOnly, non-idempotent, destructive, and open-world, so the description does not need to re-state mutation risk; instead it adds real substance: revisions are immutable snapshots, the server preserves original UTF-8 bytes and returns size/hash evidence for attachments, and creation may or may not produce a conversationUpdate. It does not describe the response payload or failure modes such as a path collision, which keeps it below a 5.

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?

Purpose is front-loaded and every sentence is substantive, but the block runs long and mixes three distinct concerns (revision targeting, content vs attachment, plan-item workflow) without structure or paragraph breaks, making it easy to skim past the exclusivity rule. Some fallback wording about conversationUpdate is dense enough to need a second read.

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?

For a six-parameter, nested, destructive mutation with no output schema, the description covers targeting, content sources, workflow ordering, and verification via get_file. What is missing is the return shape (file identifier, revision) and what happens when the path already exists, which the agent would otherwise have to discover empirically.

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?

Adds rules the schema does not encode: omit strategyId and revisionId together for the attached workspace, otherwise copy the exact returned pair; provide exactly one of content or attachment; attachment is only for user-requested exact imports sourced from attachments(action="list"). The path-folder example (lib/helpers.py) also clarifies path semantics beyond the minLength/maxLength constraints.

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?

Opens with a specific verb and resource ('Creates a file in a new immutable revision') and immediately bounds the scope to strategies owned by the authenticated user. It explicitly distinguishes itself from replace_file, patch_file, and the create_strategy follow-up case, so an agent can route correctly 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?

Gives explicit when-to-use (files that do not yet exist, plan-driven first build), when-not-to-use (do not update main.py or requirements.txt after create_strategy; use replace_file or patch_file instead), and names the exact sibling tools for those alternatives. It also states a default policy (active strategy unless the user asks otherwise) and a safety rule about not inventing upload contents.

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

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.