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 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.9/5.0
Behavior5/5

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

Rich behavioral disclosure beyond raw schema: synchronous with 3-10s latency, per-day quota (Pro=50, Power=500), API tier restriction, multi-day candle alignment variance (6.66 pp CAGR average), warmup/late-listing caveat requiring comparison against benchmark.strategy_window when matches_strategy_window is false, and filters never create trades. This is substantial context not present in annotations (which are absent), so the description fully carries the burden.

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?

Dense but each sentence earns its place; critical operational details (benchmark caveat, quota, alignment risk) are front-loaded or contextually placed. Slightly compact to the point of requiring careful reading, but not bloated; no filler words.

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-param tool with no output schema, the description covers: when to use, what is returned, latency, quota, tier, caveats about result interpretation, filter semantics, and sibling routing. It goes beyond typical definitions in anticipating agent decision errors (aligning 1d/2d/3d as ranking, ignoring matches_strategy_window=false) and behavioral expectations. Nothing essential is missing for selecting and invoking it correctly.

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 parameters are already documented. The description adds meaning beyond schema: it explains the benchmark comparison caveat, clarifies capital affects only absolute figures, warns against changing params without reason, explicates interval alignment risk and suggests treating differences below 6.66 pp as indistinguishable, details asset_type retirement, and states filters only remove entries. This goes well beyond the schema's field descriptions.

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?

Description begins with a concrete question framing the tool's purpose, then states the exact operation: run ONE strategy on ONE pair over a date range, synchronous, 3-10s, returning full performance results. It explicitly differs from siblings and lists output fields (CAGR, total return, max drawdown, win-rate, trade count, benchmark comparison, run_id).

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?

Explicitly states when to use ('when the user wants a concrete result for a specific setup'), and provides alternatives for side-by-side comparisons (arena_compare_strategies), many pairs (arena_run_universe_backtest), and judging existing results (validate_strategy / arena_get_robustness_field). Also explains filters only remove entries and advises running once without them for baseline.

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