Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Commit evidence from a completed Rules review

commit_backtest_rules_review

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 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.

Input Schema

NameRequiredDescriptionDefault
rulesYes
overallYes
backtestIdYes
codeDigestNo
revisionIdYes
rulesDigestNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so extensively: it is a write that fails on stale digests, non-terminal backtests, or missing verdicts; duplicate Rule ids are rejected; Node derives and stores SHA-256 digests; optional digest inputs are assertions only; and it never edits Rules, Python, backtests, orders, or deployments.

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?

Purpose and critical constraints are front-loaded, and nearly every sentence adds operational value. It is dense and somewhat repetitive at the end about non-mutation, but the length is largely justified by the complex multi-source schema.

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?

Given a complex nested evidence schema, no annotations, and no output schema, the description is substantially complete on validation, evidence format, and failure modes. It omits the meaning of 'overall' and does not describe the success result of the commit, leaving minor gaps.

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 must compensate, and it does for most parameters: it explains rules array cardinality/duplicates, per-source evidence required fields, missingTelemetry rules, digest optionality, and validity of zero/null observed values. However, the 'overall' parameter is never mentioned, and backtestId/revisionId are only implicitly identified.

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 (commit), resource (per-Rule evidence review), and scope (one exact terminal backtest and revision). It also explicitly delimits what the tool does not do ('never analyzes a Rule or retrieves evidence'), which cleanly separates it from sibling analysis/retrieval tools like get_backtest_artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong preconditions: independently read rules.json/main.py, define per-Rule evidence, inspect artifacts/logs/metrics before calling. It also clarifies boundary behavior rather than naming an explicit alternative tool for evidence gathering, so routing to specific siblings is implied rather than stated.

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 toolsInspect
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.

Resources