Backtesting Arena

Validate a strategy/signal (honest backtest)

validate_strategy

Does this strategy survive an honest test? Backtest a trading strategy honestly — look-ahead-aware validation with Deflated-Sharpe-Ratio / multiple-testing correction (Bailey & López de Prado). Returns an EVIDENCE verdict (insufficient_evidence | anecdote | failed_oos | passed_oos) plus metrics, flags and caveats — NOT a buy/sell recommendation. Call this before acting on a strategy or signal list. Accepts a named catalog strategy (type=rules), a timestamped BUY/SELL signal list (signal_list), or a timestamped trade list (trade_list). Checks: realistic next-bar fills (look-ahead/optimism), net of cost, out-of-sample split, and a hard 30-round-trip sample gate (under 30 is always "anecdote"). signal_list/trade_list are re-priced at the OPEN of the bar after each timestamp (fill_rule: next_bar_open); their max_drawdown is measured on closed-trade equity (max_drawdown_basis), so it reads shallower than the daily mark-to-market drawdown of arena_run_backtest. Flag below_buyhold = net return under the single-entry buy & hold in the payload (informational, not part of the verdict). Not reproducible via generic backtest tools that ignore overfitting. [API Pro tier]

Input Schema

Name	Required	Description
`oos`	No	How the claim is tested out-of-sample. Omit for the default split — the out-of-sample part is what separates a finding from a fit.
`costs`	No	Trading costs. Default 10 bps (crypto) / 5 bps (else) — a gross-only claim usually shrinks once these apply.
`market`	Yes	Which market the claim is about — prices are re-fetched from here, not taken from you.
`window`	Yes	Period over which the claim is checked.
`strategy`	Yes	The claim being validated — supply exactly one of: a catalog strategy (type=rules), your signals (type=signal_list) or your finished trades (type=trade_list).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 25, 2026

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: -[
-  "strategy",
-  "market",
-  "window",
-  "context"
-]New value: +[
+  "strategy",
+  "market",
+  "window"
+]

Changed1 schema field changedJul 31, 2026

changedInput schema / properties / market / properties / interval / description

Previous value: -"Candle interval the signals refer to: '1d', '1w' or '1M'."New value: +"Candle interval the signals refer to. 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."

Changed1 schema field changedJul 31, 2026

changedInput schema / properties / market / properties / interval / enum

Previous value: -[
-  "1d",
-  "1w",
-  "1M"
-]New value: +[
+  "1d",
+  "2d",
+  "3d",
+  "1w",
+  "1M"
+]

Changed15 schema fields changedJul 27, 2026

changedInput schema / properties / costs / description

Previous value: -"Per-side fee in bps; default 10 (crypto) / 5 (else)."New value: +"Trading costs. Default 10 bps (crypto) / 5 bps (else) — a gross-only claim usually shrinks once these apply."

addedInput schema / properties / costs / properties / fee_bps / description
```
Added value: +"Per-side fee in basis points, e.g. 10 = 0.10%."
```

addedInput schema / properties / market / description

Added value: +"Which market the claim is about — prices are re-fetched from here, not taken from you."

addedInput schema / properties / market / properties / asset_type / description
```
Added value: +"Asset class, normally 'crypto'."
```
addedInput schema / properties / market / properties / interval / description
```
Added value: +"Candle interval the signals refer to: '1d', '1w' or '1M'."
```

addedInput schema / properties / market / properties / symbol / description

Added value: +"Pair / symbol the strategy is claimed to work on, e.g. BTCUSDT."

addedInput schema / properties / oos / description

Added value: +"How the claim is tested out-of-sample. Omit for the default split — the out-of-sample part is what separates a finding from a fit."

addedInput schema / properties / oos / properties / scheme / description

Added value: +"Out-of-sample scheme: 'split' (one in-sample/out-of-sample cut, default) or 'walk_forward' (rolling re-evaluation)."

changedInput schema / properties / oos / properties / split_frac / description

Previous value: -"In-sample fraction; default 0.7."New value: +"In-sample fraction for scheme=split; default 0.7."

addedInput schema / properties / strategy / description

Added value: +"The claim being validated — supply exactly one of: a catalog strategy (type=rules), your signals (type=signal_list) or your finished trades (type=trade_list)."

addedInput schema / properties / strategy / properties / params / description

Added value: +"Strategy parameters for type=rules; omit for the audited defaults."

addedInput schema / properties / strategy / properties / type / description

Added value: +"How the claim is supplied: 'rules' = a catalog strategy re-run by us · 'signal_list' = your timestamped BUY/SELL decisions · 'trade_list' = your finished round-trips."

addedInput schema / properties / window / description

Added value: +"Period over which the claim is checked."

changedInput schema / properties / window / properties / from / description

Previous value: -"YYYY-MM-DD"New value: +"Evaluation start, YYYY-MM-DD."

addedInput schema / properties / window / properties / to / description
```
Added value: +"Evaluation end, YYYY-MM-DD. Default: today."
```

Changed1 schema field changedJul 24, 2026

changedInput schema / properties / market / properties / asset_type / enum

Previous value: -[
-  "crypto"
-]New value: +[
+  "crypto",
+  "tokenized_equity",
+  "tokenized_etf",
+  "commodities"
+]

Changed1 schema field changedJul 14, 2026

changedInput schema / properties / market / properties / asset_type / enum

Previous value: -[
-  "crypto",
-  "stock",
-  "etf",
-  "commodities",
-  "forex"
-]New value: +[
+  "crypto"
+]

First observedJul 13, 2026

TDQS

A4.6/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 richly: it discloses the 30-round-trip sample gate (under 30 is always "anecdote"), next_bar_open fill rule, closed-trade equity drawdown basis, that prices are re-fetched from the given market rather than trusted, the below_buyhold informational flag, and the [API Pro tier] access requirement.

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?

Front-loaded with the core question ("Does this strategy survive an honest test?") and every sentence carries substantive information — verdict values, gates, fill assumptions, tier note. It is a dense single block rather than clearly segmented, but there is little true redundancy.

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?

No output schema exists, so the description correctly explains the return (EVIDENCE verdict enum plus metrics, flags and caveats, explicitly not a buy/sell recommendation). Nested parameter objects are all documented and the access tier is flagged, leaving nothing an agent needs in order to call it correctly.

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 coverage is 100%, so the baseline is 3, but the prose adds meaning beyond the schema by defining how the three strategy input types are treated (re-priced at next-bar open; signals paired into round-trips) and by naming concepts absent from the schema (fill_rule, max_drawdown_basis).

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 and resource — backtest/validate a trading strategy — with the distinctive method named (look-ahead-aware validation, Deflated Sharpe Ratio, multiple-testing correction) and the enumerated EVIDENCE verdict. It explicitly distinguishes itself from sibling arena_run_backtest (drawdown basis) and from generic backtest tools.

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?

"Call this before acting on a strategy or signal list" gives a clear trigger, and it names alternatives (arena_run_backtest, generic backtest tools) with a concrete reason to prefer this one. It does not spell out when NOT to use it (e.g., plain exploratory re-runs), so it stops short of full 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 tools Inspect

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.

Validate a strategy/signal (honest backtest)

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources