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. Use get_file with a returned strategyRevisionId to inspect a historical file. 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.

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.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds what they cannot: restore creates a new immutable whole-strategy revision, preserves all other current files and Rules, restoring rules.json does not restore main.py, a stale head produces a visible conflict, and success must be verified via get_file. That is substantive behavioral disclosure beyond the flags.

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 with the two-sentence core, then cleanly partitioned by action headings with required fields called out, which suits a dual-mode tool. It is somewhat long and repeats the 'never restore an old whole snapshot/file map' warning in both sections and restates the get_file readback twice.

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?

With 8 parameters, no output schema, and a destructive branch, the definition covers return content for list (per-file versions, source revision UUIDs, headRevisionId), pagination, conflict handling, and verification steps. Nothing essential for a correct call 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%, but the description still adds meaning: which fields pair with which action, where sourceRevisionId/expectedHeadRevisionId come from, and the omission semantics of strategyId/revisionId. Minor wart: it tells the agent to use 'nextBefore' for older entries while the actual parameter is named 'before', which could send an agent looking for a nonexistent field.

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+resource pair for each mode: per-file history listing and single-file restoration into the current snapshot. It distinguishes itself from get_file (inspection), list_revisions (whole-strategy revisions), and replace_file/patch_file by stressing that only one file is restored and the whole snapshot is never restored.

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 per-action required fields, tells the agent to obtain sourceRevisionId and expectedHeadRevisionId from action="list", to omit strategyId/revisionId for the attached strategy, and to read back the new revisionId with get_file. It also routes historical inspection to get_file with the returned strategyRevisionId, which is exactly the sibling-selection guidance needed.

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.