BotSpot: AI Trading, Backtests and Bots

Read or restore one strategy file

file_history

Destructive

List per-file history or explicitly restore one historical file into the current complete strategy snapshot. Listing is read-only. Restoring creates a new immutable strategy revision and preserves all other current files and Rules; it never restores an old whole snapshot. Use sourceRevisionId and expectedHeadRevisionId from history for restoration, then read back the saved file with get_file.

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

action="list": Read one strategy file history

Required fields: path. Returns bounded metadata for actual content, metadata and deletion changes of one owned strategy file, with per-file versions, source strategy revision UUIDs and current headRevisionId. Historical preview is read-only: this tool does not select an editing base, restore files or change conversation strategy state. Omit strategyId and revisionId for the current attached strategy; for another named owned strategy pass its exact legacy Strategy id and revisionId from list_strategies/list_revisions. Preview the intended historical source with get_file before restoring it. matchesCurrentContent identifies entries that would not change current content. Do not mistake fileVersion for the whole strategy version or UUID. Use nextBefore to read older entries. To restore a selected file, use file_history(action="restore") with its source strategyRevisionId and the current headRevisionId. Never copy the old whole snapshot to restore one file.

action="restore": Restore one strategy file

Required fields: sourceRevisionId, path, expectedHeadRevisionId. Restores one explicitly requested historical file into the current complete snapshot and creates a new immutable whole-strategy revision. Get sourceRevisionId and expectedHeadRevisionId from file_history(action="list"); the source and current destination must belong to the same owned strategy. All unrelated current Rules, helpers and dependencies are preserved. Never restore an old whole file map to restore one file. Restoring rules.json explicitly restores that Rules file only; restoring main.py does not restore old Rules. Omit strategyId for the current attached strategy; pass the exact named target legacy Strategy id for another owned strategy. The server uses only trusted conversation identity. A changed head returns a visible conflict: refresh history before retrying. Read back the returned new revisionId with get_file before claiming restoration succeeded.

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

Input Schema

Name	Required	Description
`path`	No	Used with action="list", action="restore". Required for action="list", action="restore".
`limit`	No	Used with action="list".
`action`	Yes	Which operation to run: "list", "restore". See the tool description for each one.
`before`	No	Exclusive per-file version cursor returned by the preceding history page. Used with action="list".
`revisionId`	No	Owned revision selector. Omit with strategyId for the current attached strategy; this is a read selector, not a write base. Used with action="list".
`strategyId`	No	action="list": Legacy Strategy id. Omit with revisionId for the current attached strategy. \| action="restore": Legacy Strategy id. Omit for the current attached strategy. Used with action="list", action="restore".
`sourceRevisionId`	No	Exact strategy revision UUID containing the selected historical file, returned by file_history(action="list"). Used with action="restore". Required for action="restore".
`expectedHeadRevisionId`	No	Exact current headRevisionId returned by file_history(action="list"); restoration fails if the strategy advances. Used with action="restore". Required for action="restore".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true; the description adds substantial context beyond that, clarifying that list is read-only while restore creates a new immutable whole-strategy revision that preserves unrelated files and Rules, and that a changed expectedHeadRevisionId produces a visible conflict requiring a history refresh. It also states the server uses only trusted conversation identity. The only gap is that destructiveHint=true applies to the whole tool rather than being scoped per action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded summary followed by per-action sections with required fields is easy to scan for a two-action tool. There is some redundancy, though: the 'never restore an old whole snapshot/file map to restore one file' warning appears twice, and the read-back instruction is repeated across sections.

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 complex dual-action tool with 8 parameters, no output schema and destructive semantics, the definition covers what list returns (bounded metadata, per-file versions, source revision UUIDs, headRevisionId), what restore creates (a new revisionId) and the required verification step with get_file. Nothing an agent needs to invoke either action correctly is missing.

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 adds workflow semantics the schema cannot: sourceRevisionId and expectedHeadRevisionId must be obtained from a prior file_history(action="list"), the source and destination must belong to the same owned strategy, and nextBefore is the cursor for older entries. That is real meaning beyond field descriptions.

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 both verbs and the resource precisely: 'List per-file history or explicitly restore one historical file into the current complete strategy snapshot.' It distinguishes the two operations up front and later names get_file as the read-back sibling, so an agent can tell it apart 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 guidance per action: omit strategyId/revisionId for the current attached strategy versus passing an exact legacy Strategy id for another owned strategy, and it names list_strategies/list_revisions as sources for those ids. It also gives concrete exclusions ('never restores an old whole snapshot', 'never copy the old whole snapshot to restore one file') and points to get_file for previewing the source before restoring.

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.