BotSpot: AI Trading, Backtests and Bots

List bounded revisions (versions) for a strategy

list_revisions

Read-onlyIdempotent

Returns a bounded page of available revisions for a strategy with full revisionIds and version numbers. The default returns the newest 20 revisions and is capped at 50 per call so revision history never overwhelms the model context. When the user names an exact historical version such as "version 641" or "original 641", pass version= to retrieve that revision in one call instead of paging with limit/offset. Use limit/offset only when browsing unknown older history without a named version number. Use this to discover which versions exist before calling set_strategy_revision for the already-active strategy, or before calling switch_active_strategy for a different owned strategy. When a user explicitly names a strategy that differs from the open page/context, says 'the one entitled X', says 'apply this to X also', or says 'do not change Y', resolve that named strategy with list_strategies, then list revisions for the named target; do not silently use the active page revision. After this returns, pass the named target's revisionId into get_file/patch_file/replace_file. Never reuse the open page revision id for a different named strategy. For first-build strategy work, call create_strategy first; list_revisions cannot open files for a workspace that does not exist yet. Each revision has a version number (1, 2, 3...) that users refer to, and a revisionId (UUID) that you need for same-strategy version switching. The isCurrent flag indicates which revision is currently active in the conversation.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_revisions"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of newest revisions to return in this bounded page. Defaults to 20 and is capped at 50. Ignored when version is set. Full revisionIds are always preserved.
`offset`	No	Zero-based page offset for older revisions. Use only when the first bounded page is not enough. Ignored when version is set.
`version`	No	Exact user-facing version number to retrieve (for example 641). Prefer this over limit/offset when the user names a specific historical version so the agent does not page through hundreds of newest revisions.
`strategyId`	No
`aiStrategyId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds real behavioral context: a default of 20 with a hard cap of 50 to protect model context, and the meaning of the isCurrent flag. It also discloses a failure mode ('cannot open files for a workspace that does not exist yet'). What it omits is behavior on an unknown or out-of-range version or on an invalid strategyId.

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?

Guidance is front-loaded and organized around decision points (named version vs paging, which strategy, what to do next). It drifts into mild repetition with the closing revisionId/version-number recap and the restated warning not to reuse the open page revision id.

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 five-parameter read-only listing tool with no output schema, the description covers paging limits, the special-case version lookup, return fields, and workflow placement. The remaining gap is the strategyId/aiStrategyId distinction and any error semantics, which no structured field fills.

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 coverage is 60%, and the description duplicates rather than extends the schema for limit, offset, and version, whose meanings are already documented inline. The two bare parameters, strategyId and aiStrategyId, get no explanation in either the schema or the description, leaving the agent to guess which identifier form to supply.

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 description opens with a specific verb and resource ('Returns a bounded page of available revisions for a strategy') and immediately scopes the output ('full revisionIds and version numbers'). It also distinguishes itself from set_strategy_revision, switch_active_strategy, and create_strategy by naming them, so an agent can place it in the workflow without opening a 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 are given: use version=<n> when the user names an exact historical version such as 'version 641' or 'original 641', and use limit/offset only when browsing unknown older history. It also states prerequisites (call create_strategy first for first-build work; resolve named strategies with list_strategies) and the downstream step (pass revisionId into get_file/patch_file/replace_file).

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.