BotSpot: AI Trading, Backtests and Bots

Commit evidence from a completed Rules review

commit_backtest_rules_review

Idempotent

Commit the conversational Agent's already-completed, per-Rule evidence review for one exact terminal backtest and revision. This tool never analyzes a Rule or retrieves evidence. Before calling it, independently read the exact rules.json and main.py revision, define the evidence needed by each Rule, and inspect the relevant backtest artifacts, logs, metrics, trades, indicators, orders, and position state. Submit exactly one verdict for every active Rule. The rules array length must equal the number of unique active Rule ids. Duplicate Rule ids are rejected, including a complete verdict array accidentally appended twice. Node derives the stored overall result from those Rule verdicts; it is not the backtest readiness result. A zero-fill run does not make every satisfied Rule fail. The overall input remains accepted for existing clients; explicit skip retains its meaning. Node derives and stores the exact content SHA-256 digests from the immutable revision. Optional digest inputs are integrity assertions only; omit them instead of manually copying hashes. The write fails if a supplied digest is stale, if the backtest is not terminal, or if any active Rule is missing a verdict. Evidence references must identify real artifacts or exact code locations. Artifact and metric evidence use the same label key as get_backtest_artifact. Code evidence supplies path and lines; Node attaches the already-validated digest for that exact file. Artifact evidence requires label, query and rowCount; log evidence requires query, matchedLines, startTime and endTime from the actual log query; metric evidence requires label, metric and observedValue; code evidence requires path and lines. Include detail for every reference. Zero rowCount/matchedLines and null observedValue are valid observed values, not omitted fields. Each unknown Rule verdict requires its own missingTelemetry object with artifactOrField and reason; one Rule cannot borrow another Rule missingTelemetry. This commit never edits Rules, Python, backtests, orders, or deployments.

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": {
      "backtestId": "<backtestId>",
      "revisionId": "<revisionId>",
      "overall": "<overall>",
      "rules": "<rules>"
    },
    "name": "commit_backtest_rules_review"
  }
}

Input Schema

Name	Required	Description	Default
`rules`	Yes
`overall`	Yes
`backtestId`	Yes
`codeDigest`	No
`revisionId`	Yes
`rulesDigest`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations: discloses that Node derives the stored overall result from Rule verdicts (not the readiness result), that digests are derived server-side so optional digest inputs are assertions only, and names concrete failure conditions (stale digest, non-terminal backtest, missing verdict). It also clarifies edge semantics such as zero-fill runs not failing satisfied Rules and zero/null observed values being valid. It stops short of saying what the commit response returns, which with no output schema would have been useful.

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-loads purpose and exclusions, then walks through preconditions, cardinality rules, digest behavior, failure modes, and per-variant evidence shapes in a logical order. Nearly every sentence carries a distinct rule, though the dense unbroken prose and a couple of restated prohibitions ('never analyzes', 'never edits') make it heavier than needed.

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 write tool with a deeply nested schema and no output schema, the description covers invocation prerequisites, validation failure modes, evidence payload requirements, and digest handling. The main remaining gap is the shape of the successful result, which the agent cannot learn from an output schema.

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 description coverage is 0%, so the description carries the full burden and largely does: it enumerates the required fields per evidence variant (artifact: label/query/rowCount; log: query/matchedLines/startTime/endTime; metric: label/metric/observedValue; code: path/lines) and explains that digests are optional integrity assertions to omit rather than copy. It is thinner on backtestId/revisionId addressing and on the full meaning of each 'overall' enum value, leaving some semantic inference to the agent.

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?

States a specific verb and resource (commit the Agent's already-completed, per-Rule evidence review) scoped to one exact terminal backtest and revision. It immediately separates itself from evidence-gathering siblings by declaring 'This tool never analyzes a Rule or retrieves evidence,' which points the agent at get_backtest_artifact/get_backtest_logs for the prior step.

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 preconditions: read the exact rules.json and main.py revision, define per-Rule evidence, and inspect backtest artifacts, logs, metrics, trades, indicators, orders and position state before calling. It states exclusions (no analysis, no evidence retrieval), submission cardinality (one verdict per active Rule), and references get_backtest_artifact for label key alignment.

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.