Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Is this difference real — or smaller than the measurement noise?

arena_is_distinguishable

Do these two backtest figures actually differ? Check before ranking them. Pass the two values as a and b (same metric, same basis) plus axes — which arbitrary choices went into them — and the tool returns whether their gap clears the MEASURED noise floor of those choices, along with the floor itself, the dominant axis, and the probe + date it was measured on. axes accepts: grid_phase (how a multi-day candle grid is aligned to the Unix epoch; exists only on 2d/3d), parameter_choice (neighbouring parameter settings — by far the largest axis), window_edges (shifting the start date), pair_selection (which pairs made it into the universe). Pass ALL axes that genuinely varied; the floor is their maximum, not their sum. Optionally set interval to the candle interval so the floor can be sharpened where an axis was measured per interval — passing grid_phase together with a non-multi-day interval is a hard error, because that axis does not exist there. label_a and label_b are optional display names for the two values and are echoed back inside the explanation, so a multi-way comparison stays readable. metric selects the figure being compared: cagr (default, gross CAGR in percent), max_drawdown (bar-wise max drawdown in percent) or coin_vs_hold (percent more or fewer coins than buying and holding from the start). Each has its own measured floors; grid_phase is measured for cagr only and errors on the others. Read-only, no market data touched. [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aYesFirst value in percent of the chosen metric (e.g. 33.1 for +33.1% CAGR).
bYesSecond value, same metric, same unit and same basis as a.
axesYesWhich arbitrary choices differ between a and b. Pass every one that genuinely varied — omitting an axis makes the answer look more certain than it is.
metricNoWhich figure a and b are: cagr (default), max_drawdown or coin_vs_hold. Floors differ by metric.
label_aNoOptional name for a, echoed in the explanation.
label_bNoOptional name for b, echoed in the explanation.
intervalNoCandle interval, if known (e.g. '1d', '2d', '3d', '1w'). Sharpens the floor where an axis was measured per interval. Passing grid_phase with a non-multi-day interval is an error, not a rounding detail — that axis does not exist there.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / a / description
      Previous value: -"First value — gross CAGR in percent (e.g. 33.1 for +33.1%)."New value: +"First value in percent of the chosen metric (e.g. 33.1 for +33.1% CAGR)."
    • changedInput schema / properties / b / description
      Previous value: -"Second value, same unit and same basis as a."New value: +"Second value, same metric, same unit and same basis as a."
    • addedInput schema / properties / metric
      Added value: +{
+  "description": "Which figure a and b are: cagr (default), max_drawdown or coin_vs_hold. Floors differ by metric.",
+  "enum": [
+    "cagr",
+    "max_drawdown",
+    "coin_vs_hold"
+  ],
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "a",
-  "b",
-  "axes",
-  "context"
-]New value: +[
+  "a",
+  "b",
+  "axes"
+]
  3. Added

TDQS

A4.7/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 burden and does so: it discloses the return payload (pass/fail verdict, the floor value, dominant axis, probe and date), the computation semantics (max not sum across axes), hard error conditions (grid_phase with a non-multi-day interval; grid_phase on non-cagr metrics), and the safety profile ('Read-only, no market data touched', Free tier).

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?

It is front-loaded with the question and the when-to-use trigger, and nearly every sentence adds real information. It is a single dense block, however, and the grid_phase/interval error is stated twice, which slightly inflates length for a 7-parameter tool.

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 7-param tool with no annotations and no output schema, the description covers the return shape, error conditions, axis semantics, defaults, and safety in one place. An agent has everything needed to invoke it correctly without opening anything else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds meaning the schema cannot: it explains what each axis enum value actually represents, flags parameter_choice as by far the largest axis, clarifies that interval sharpens the floor per-interval, and notes metric-specific floor differences and the grid_phase-only-on-cagr rule.

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 states a specific verb and resource — testing whether two backtest figures differ beyond measurement noise — and frames the exact decision it supports ('Check before ranking them'). It is unmistakably distinct from every sibling, which are getters or backtest runners, and the title reinforces the purpose.

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?

It gives clear usage context ('Check before ranking them') and operational rules (pass ALL axes that genuinely varied; floor is their maximum, not their sum). However, it never names an alternative tool or a when-not-to-use condition beyond the axis/interval error cases, so it falls short of explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Backtesting Arena 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