Backtesting Arena

Get BTC Volatility History (RV + ATR%)

arena_get_volatility_history

How volatile has Bitcoin been? Daily Bitcoin volatility time series: realized volatility (30d & 90d, √252-annualized, close-to-close) and ATR% (Wilder EMA-14, captures intraday range + gaps), on the same scale. Ranks come in two flavours answering different questions: rvRank/atrPctAnnRank expand from the start of history and are look-ahead-free, but they include BTC's structural volatility decline; rvRankRolling/atrPctAnnRankRolling rank against a trailing 2-year window, which removes that trend from the comparison. History reaches back to 2009 via a stitched pre-Binance close series; ATR is null before the Binance era because no daily high/low exists that far back (see meta.coverage). Use from/to for a specific window instead of pulling everything and discarding it, and granularity/fields to keep long ranges affordable. For long ranges pass format: "columns" (one array per field — the largest saving) together with schema_version: "2026-08" (rounds floats; opt-in until the default flips 2026-11-01), fields: "minimal" and meta: "minimal" — every response carries a size block with chars_before/chars_after/saved_pct measuring the saving for YOUR call. Free tier: last 365 days. Related: arena_get_volatility_phases (current phase per pair), arena_get_iv_snapshot (implied vs. this realized — same RV method, but its realized_vol_30d is computed at snapshot time BEFORE that date has traded, so on fresh breakout days the two can differ; this series uses completed closes and is the one to trust for finished days), arena_get_cycle (regime context). [Free tier]

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	ISO date (YYYY-MM-DD), inclusive. End of the window. Defaults to the latest bar.
`days`	No	Number of most recent days to return. Free tier capped at 365; API Pro unlimited. Ignored when from/to are given.
`from`	No	ISO date (YYYY-MM-DD), inclusive. Start of the window. Free tier still only sees the last 365 days.
`meta`	No	Default full. 'minimal' drops params/params_hash/warmup, which are only useful on the first call.
`fields`	No	Default full. 'minimal' returns date, close, rv, rvRank, rvRankRolling, atrPctAnnRank, atrPctAnnRankRolling only — measured saving 18–20 % of characters (full-history series, 2026-07-31; the `size` block in the response has the figure for your actual call), not a fifth of the size. Combine with granularity or a from/to window for a real reduction; dropping fields alone saves less than it looks.
`format`	No	Default 'rows' (series[] of objects). 'columns' returns series_columns instead — one array per field (date, close, rv, …) with each field name written once; the largest single saving for long ranges. Combines with fields, granularity and schema_version (the size block then measures the combined saving).
`granularity`	No	Default daily. weekly/monthly keep the LAST observation of each period (a state, not an average).
`schema_version`	No	Default '2026-07' (unchanged output). '2026-08' rounds floats to 2 decimals (ranks 1) and reports the saving. Default flips 2026-11-01.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / format

Added value: +{
+  "description": "Default 'rows' (series[] of objects). 'columns' returns series_columns instead — one array per field (date, close, rv, …) with each field name written once; the largest single saving for long ranges. Combines with fields, granularity and schema_version (the size block then measures the combined saving).",
+  "enum": [
+    "rows",
+    "columns"
+  ],
+  "type": "string"
+}

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"
-}

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

Changed1 schema field changedAug 19, 2026

changedInput schema / properties / fields / description

Previous value: -"Default full. 'minimal' returns date, close, rv, rvRank, rvRankRolling, atrPctAnnRank, atrPctAnnRankRolling only — measured saving 18–20 % of characters (5,508-row series, 2026-07-31), not a fifth of the size. Combine with granularity or a from/to window for a real reduction; dropping fields alone saves less than it looks."New value: +"Default full. 'minimal' returns date, close, rv, rvRank, rvRankRolling, atrPctAnnRank, atrPctAnnRankRolling only — measured saving 18–20 % of characters (full-history series, 2026-07-31; the `size` block in the response has the figure for your actual call), not a fifth of the size. Combine with granularity or a from/to window for a real reduction; dropping fields alone saves less than it looks."

Changed1 schema field changedJul 31, 2026

changedInput schema / properties / fields / description

Previous value: -"Default full. 'minimal' returns date, close, rv30, rvRank, atrPctAnnRank only — about a fifth of the characters."New value: +"Default full. 'minimal' returns date, close, rv, rvRank, rvRankRolling, atrPctAnnRank, atrPctAnnRankRolling only — measured saving 18–20 % of characters (5,508-row series, 2026-07-31), not a fifth of the size. Combine with granularity or a from/to window for a real reduction; dropping fields alone saves less than it looks."

Changed7 schema fields changedJul 30, 2026

changedInput schema / properties / days / description

Previous value: -"Number of most recent days to return. Free tier capped at 365; API Pro unlimited."New value: +"Number of most recent days to return. Free tier capped at 365; API Pro unlimited. Ignored when from/to are given."

addedInput schema / properties / fields

Added value: +{
+  "description": "Default full. 'minimal' returns date, close, rv30, rvRank, atrPctAnnRank only — about a fifth of the characters.",
+  "enum": [
+    "minimal",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / from

Added value: +{
+  "description": "ISO date (YYYY-MM-DD), inclusive. Start of the window. Free tier still only sees the last 365 days.",
+  "type": "string"
+}

addedInput schema / properties / granularity

Added value: +{
+  "description": "Default daily. weekly/monthly keep the LAST observation of each period (a state, not an average).",
+  "enum": [
+    "daily",
+    "weekly",
+    "monthly"
+  ],
+  "type": "string"
+}

addedInput schema / properties / meta

Added value: +{
+  "description": "Default full. 'minimal' drops params/params_hash/warmup, which are only useful on the first call.",
+  "enum": [
+    "full",
+    "minimal"
+  ],
+  "type": "string"
+}

addedInput schema / properties / schema_version

Added value: +{
+  "description": "Default '2026-07' (unchanged output). '2026-08' rounds floats to 2 decimals (ranks 1) and reports the saving. Default flips 2026-11-01.",
+  "enum": [
+    "2026-07",
+    "2026-08"
+  ],
+  "type": "string"
+}

addedInput schema / properties / to

Added value: +{
+  "description": "ISO date (YYYY-MM-DD), inclusive. End of the window. Defaults to the latest bar.",
+  "type": "string"
+}

AddedJul 24, 2026

TDQS

A4.8/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 free-tier 365-day cap, that ATR is null before the Binance era, that history reaches 2009 via a stitched series, that rvRank/atrPctAnnRank are look-ahead-free but trend-biased while the Rolling variants are not, and that the size block measures savings. These are non-obvious behavioral traits an agent could not infer from the schema.

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?

The opening question ('How volatile has Bitcoin been?') front-loads the purpose, and each subsequent sentence carries distinct information (rank semantics, coverage caveats, affordability knobs, related tools). It is dense and long, but not padded — though the savings/format guidance could be tightened for an agent skimming it.

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 and no annotations, yet the description names the returned fields, explains the two rank families and their trade-offs, documents data-coverage limits (ATR null pre-Binance, 2009 stitching, free-tier window), and points to the meta.coverage/size blocks for self-description. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so the baseline is 3; the description goes beyond it by explaining the rank-flavour distinction behind rvRankRolling, why `format: "columns"` produces the largest saving, how fields/granularity/format combine in the size block, and that schema_version 2026-08 is opt-in with a default flip date. It adds real interpretive value without re-documenting the enum values already in the schema.

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+resource ('Daily Bitcoin volatility time series') and enumerates exactly what is returned: realized volatility (30d/90d, √252-annualized) and ATR% (Wilder EMA-14). It also names the differentiating sibling (arena_get_iv_snapshot) and explains the methodological distinction, so an agent can separate it from related tools without opening a schema.

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?

Explicit routing is provided: use `from`/`to` rather than pulling everything, use `granularity`/`fields` for affordability, and pass `format: "columns"` + `schema_version: "2026-08"` for long ranges. It also states the free-tier limit and directs to sibling tools for the questions this one does not answer (arena_get_volatility_phases, arena_get_cycle).

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.

Get BTC Volatility History (RV + ATR%)

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources