Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

Run a New Backtest

arena_run_backtest

How would this strategy have performed? Run ONE strategy on ONE pair over a date range and get the full result: CAGR, total return, max drawdown, win-rate, trade count, Buy & Hold comparison, net-of-fees figures, and a run_id for later retrieval. Synchronous, typically 3–10s. Use this when the user wants a concrete result for a specific setup. For several strategies side by side use arena_compare_strategies; for many pairs at once use arena_run_universe_backtest; to judge whether an EXISTING result is trustworthy rather than produce a new one, use validate_strategy or arena_get_robustness_field. Filters are optional and only remove entries; run once without them for the baseline. Read result.benchmark before comparing cagr to buyhold_cagr: warmup or a late listing can shorten the strategy window, and matches_strategy_window:false means the two figures are annualized over DIFFERENT periods — in that case benchmark.strategy_window carries the like-for-like buy-and-hold (its cagr_delta_pp is benchmark-minus-benchmark, defined in cagr_delta_pp_definition; strategy vs like-for-like benchmark is strategy_minus_window_benchmark_pp) over the window the strategy actually traded, and THAT is the one to compare against. Per-day quota: Pro=50, Power=500. [API Pro tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pairYesCrypto pair symbol, e.g. BTCUSDT, ETHUSDT, SOLUSDT.
paramsNoStrategy-specific parameters, e.g. { rsi_period: 14 }. Omit to use the audited defaults — changing them without a reason is how overfitting starts.
capitalNoStarting capital in quote currency. Default 10000. Affects absolute figures only, not CAGR or win-rate.
date_toNoEnd date, YYYY-MM-DD. Default: today.
filtersNoOptional entry filters (Pro+). Each one only ever REMOVES entries — filters never create trades. Omit for the unfiltered baseline.
intervalYesCandle interval: '1d' daily, '2d'/'3d' multi-day, '1w' weekly, '1M' monthly. Multi-day candles (2d/3d) are anchored to the Unix epoch, so one of n possible alignments is used. Measured on our own corpus, the choice of alignment alone moves CAGR by 6.66 pp on average (max 12.30). Treat differences below that as not distinguishable — 1d/2d/3d behaved as one block in our tests, not a ranking.
strategyYesStrategy key — use arena_list_strategies to find valid keys.
date_fromYesStart date, YYYY-MM-DD. Earlier than the pair listing is clamped to the first available candle.
asset_typeYesAsset class. Use 'crypto' unless you are explicitly backtesting a tokenized real-world asset. Note: tokenized stocks/ETFs/gold trade AS crypto pairs (e.g. spybUSDT, qqqbUSDT) — there is no separate stocks/forex backtest surface; non-crypto asset classes were retired.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / stochRsiWeekly
      Added value: +{
+  "description": "Asset-specific weekly Stoch-RSI gate: entries only while the pair's weekly StochRSI(14) sits above its SMA(3). Default false.",
+  "type": "boolean"
+}
  2. Changed4 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / asset_type / description
      Previous value: -"Asset class. Use 'crypto' unless you are explicitly backtesting a tokenized real-world asset."New value: +"Asset class. Use 'crypto' unless you are explicitly backtesting a tokenized real-world asset. Note: tokenized stocks/ETFs/gold trade AS crypto pairs (e.g. spybUSDT, qqqbUSDT) — there is no separate stocks/forex backtest surface; non-crypto asset classes were retired."
    • 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: -[
-  "strategy",
-  "pair",
-  "asset_type",
-  "interval",
-  "date_from",
-  "context"
-]New value: +[
+  "strategy",
+  "pair",
+  "asset_type",
+  "interval",
+  "date_from"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / interval / description
      Previous value: -"Candle interval: '1d' daily, '1w' weekly, '1M' monthly."New value: +"Candle interval: '1d' daily, '2d'/'3d' multi-day, '1w' weekly, '1M' monthly. Multi-day candles (2d/3d) are anchored to the Unix epoch, so one of n possible alignments is used. Measured on our own corpus, the choice of alignment alone moves CAGR by 6.66 pp on average (max 12.30). Treat differences below that as not distinguishable — 1d/2d/3d behaved as one block in our tests, not a ranking."
    • changedInput schema / properties / interval / enum
      Previous value: -[
-  "1d",
-  "1w",
-  "1M"
-]New value: +[
+  "1d",
+  "2d",
+  "3d",
+  "1w",
+  "1M"
+]
  4. Changed12 schema fields changed
    • addedInput schema / properties / asset_type / description
      Added value: +"Asset class. Use 'crypto' unless you are explicitly backtesting a tokenized real-world asset."
    • changedInput schema / properties / capital / description
      Previous value: -"Default 10000."New value: +"Starting capital in quote currency. Default 10000. Affects absolute figures only, not CAGR or win-rate."
    • changedInput schema / properties / date_from / description
      Previous value: -"YYYY-MM-DD"New value: +"Start date, YYYY-MM-DD. Earlier than the pair listing is clamped to the first available candle."
    • changedInput schema / properties / date_to / description
      Previous value: -"YYYY-MM-DD; default today."New value: +"End date, YYYY-MM-DD. Default: today."
    • addedInput schema / properties / filters / description
      Added value: +"Optional entry filters (Pro+). Each one only ever REMOVES entries — filters never create trades. Omit for the unfiltered baseline."
    • addedInput schema / properties / filters / properties / altcoinSeasonMode / description
      Added value: +"Altcoin-Season gate. 'conservative' needs a confirmed alt season, 'aggressive' an early one. Default 'off'."
    • addedInput schema / properties / filters / properties / atrMode / description
      Added value: +"ATR volatility regime filter. 'low'/'high' restrict entries to that volatility band, 'expansion' to rising volatility. Default 'off'."
    • addedInput schema / properties / filters / properties / bullmarketStageMode / description
      Added value: +"Bull-market stage gate from the BTC cycle model; rising strictness from 'early' to 'strict'. Default 'off'."
    • changedInput schema / properties / filters / properties / minProfitGuardThreshold / description
      Previous value: -"Per-trade min profit guard (negative cap, e.g. -10)."New value: +"Per-trade min profit guard (negative cap, e.g. -10 = exit once a trade is 10% under water)."
    • changedInput schema / properties / filters / properties / wma200 / description
      Previous value: -"200-week MA filter (BTC-derived)."New value: +"200-week MA filter (BTC-derived): only take entries while BTC trades above its 200-week SMA."
    • addedInput schema / properties / interval / description
      Added value: +"Candle interval: '1d' daily, '1w' weekly, '1M' monthly."
    • changedInput schema / properties / params / description
      Previous value: -"Strategy-specific params (e.g. { rsi_period: 14 })."New value: +"Strategy-specific parameters, e.g. { rsi_period: 14 }. Omit to use the audited defaults — changing them without a reason is how overfitting starts."
  5. Changed1 schema field changed
    • changedInput schema / properties / asset_type / enum
      Previous value: -[
-  "crypto"
-]New value: +[
+  "crypto",
+  "tokenized_equity",
+  "tokenized_etf",
+  "commodities"
+]
  6. Changed2 schema fields changed
    • changedInput schema / properties / asset_type / enum
      Previous value: -[
-  "crypto",
-  "stock",
-  "etf",
-  "commodities",
-  "forex"
-]New value: +[
+  "crypto"
+]
    • changedInput schema / properties / pair / description
      Previous value: -"Pair symbol, e.g. BTCUSDT, AAPL.US, EURUSD.FOREX."New value: +"Crypto pair symbol, e.g. BTCUSDT, ETHUSDT, SOLUSDT."
  7. First observed

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 it delivers: synchronous with 3-10s latency, per-day quota, filters only remove entries, and a detailed benchmark-window caveat that prevents misreading cagr versus buyhold_cagr. It even warns that matches_strategy_window:false means different annualization periods.

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 long but every sentence earns its place: outcome first, then latency, then routing, then filters, then the critical benchmark caveat. It front-loads the decision-relevant facts and does not pad.

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 9-parameter tool with nested filters and no annotations or output schema, the description is remarkably complete: it lists the result metrics, explains how to retrieve later via run_id, warns about benchmark windows, and states quota limits. The absence of an output schema is compensated by the explicit mention of key result fields and the comparison caveat.

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 100%, so the schema already explains every parameter, which sets the baseline at 3. The main description adds only mild reinforcement ('filters are optional and only remove entries') rather than new per-parameter semantics; most of its added value concerns result interpretation, not parameters.

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 opening line frames the user question and then states exactly what the tool does: run ONE strategy on ONE pair over a date range and return the full result, including CAGR, drawdown, win-rate, and a run_id. It also names the sibling tools it is not (compare_strategies, run_universe_backtest), so there is no ambiguity with the large sibling list.

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?

It gives an explicit 'Use this when' condition, then names concrete alternatives for adjacent use cases: several strategies, many pairs, and judging existing results. This is exactly the routing guidance an agent needs.

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