Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch

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

arena_is_distinguishable

Do these two CAGR figures actually differ? Check before ranking them. Pass the two values as a and b (gross CAGR in percent, 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. Read-only, no market data touched. [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aYesFirst value — gross CAGR in percent (e.g. 33.1 for +33.1%).
bYesSecond value, 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.
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. Dates show when Glama detected each change.

  1. 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"
+]
  2. Added

TDQS

A5/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. It discloses it is read-only ('Read-only, no market data touched'), describes the return contents (whether gap clears noise floor, the floor itself, dominant axis, probe and date), explains the consequence of omitting an axis (answer looks more certain than it is), and documents the hard error for grid_phase with non-multi-day intervals. This goes well beyond a minimal behavioral statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. It front-loads the core question, then methodically explains the return, the axes, the aggregation, the optional interval, the labels, and the safety guarantee. No fluff or repetition; structured with clear logical flow from purpose to parameters to behavior.

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?

Given the tool's complexity (6 parameters, multiple axes, error conditions, no output schema), the description is complete. It explains the return structure, the error condition, the aggregation rule, and every parameter's role. An agent has everything needed to call it correctly and interpret the result, even without an output schema. The only minor omission is the exact JSON return shape, but the description's narrative covers the components.

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 100%, so the baseline is 3, but the description adds substantial meaning: it explains the axes enum in detail (including that parameter_choice is the largest axis), clarifies the floor aggregation rule, defines the error condition for interval/grid_phase, and explains that labels are display names echoed back. This transforms the schema's raw definitions into practical, operational guidance.

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 crisp question — 'Do these two CAGR figures actually differ?' — and states the verb ('Check') and the resource (two CAGR values). It distinguishes itself from sibling tools by being the only one that performs a noise-floor significance test on CAGR differences, rather than retrieving data or running strategies. The phrase 'before ranking them' positions it clearly in the analysis workflow.

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?

The description gives explicit when-to-use guidance: 'Check before ranking them.' It instructs the caller to pass all axes that genuinely varied and clarifies the floor is their maximum, not sum. It also warns about the hard error when combining grid_phase with a non-multi-day interval. Though it doesn't name alternative tools, the context makes the intended use unambiguous and the conditions precise.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Many tools cover overlapping market indicators (e.g., cycle state, pulse, bullmarket ampel, volatility phases) and several share similar get_*_history patterns, which could cause an agent to select the wrong one. However, each tool has detailed descriptions with explicit references to related tools to reduce ambiguity.

Naming Consistency3/5

Tool names generally follow a verb_noun pattern (arena_get_*, arena_list_*, arena_run_*, arena_subscribe_*), but there are inconsistencies such as 'validate_strategy' (no arena_ prefix), 'arena_status' (not a clear verb_noun), and variations like 'arena_run_grid_backtest' vs 'arena_run_backtest'.

Tool Count2/5

With 84 tools, the server is heavily over-scoped for a typical MCP server, likely causing navigation and selection overhead. While the domain (crypto backtesting and analytics) is broad, 84 tools exceed reasonable coherence and impose a high cognitive load.

Completeness4/5

The tool surface covers a wide range of analytics (market indicators, backtesting, validation, alerts, subscriptions, reports) with few obvious dead ends. Minor gaps exist like lack of direct portfolio management or strategy editing, but core workflows are well covered.

Resources