Skip to main content
Glama

Backtesting Arena

by io.github.Schoasch
OverviewDiscussionsAdmin

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 schema_version: "2026-08" (rounds floats; opt-in until the default flips 2026-11-01) plus 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
NameRequiredDescriptionDefault
toNoISO date (YYYY-MM-DD), inclusive. End of the window. Defaults to the latest bar.
daysNoNumber of most recent days to return. Free tier capped at 365; API Pro unlimited. Ignored when from/to are given.
fromNoISO date (YYYY-MM-DD), inclusive. Start of the window. Free tier still only sees the last 365 days.
metaNoDefault full. 'minimal' drops params/params_hash/warmup, which are only useful on the first call.
fieldsNoDefault 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.
granularityNoDefault daily. weekly/monthly keep the LAST observation of each period (a state, not an average).
schema_versionNoDefault '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.

  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"
-}
    • removedInput schema / required
      Removed value: -[
-  "context"
-]
  2. Changed1 schema field changed
    • 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."
  3. Changed1 schema field changed
    • 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."
  4. Changed7 schema fields changed
    • 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"
+}
  5. Added

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses look-ahead-free ranks, the structural volatility decline, stitched pre-Binance series with ATR null before Binance era, the size block with saving measurement, free-tier restriction, and schema_version default flip. This is comprehensive behavioral disclosure beyond what schema could convey.

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?

Despite its length, every sentence earns its place. The core purpose is front-loaded, followed by rank semantics, historical coverage, performance guidance, and related tools. No fluff; dense with actionable detail. For a tool with 7 parameters and many nuances, this is appropriately sized and well-structured.

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 and absence of an output schema, the description covers everything needed: return series content, rank semantics, historical coverage and caveats, performance optimization, free-tier limits, and clear pointers to alternatives. No critical information is missing for correct invocation and interpretation.

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% (all 7 parameters documented), so baseline is 3. However, the description adds meaningful context: 'fields' explains the actual character saving and warns that dropping fields alone saves less than it looks; 'granularity' clarifies weekly/monthly keep the last observation (a state, not an average); 'schema_version' details rounding and default flip. This adds value beyond the schema's 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?

The description clearly states what the tool does: daily Bitcoin volatility time series with realized volatility (30d/90d, annualized) and ATR%. It also distinguishes itself from siblings by explaining the two rank flavors and naming related tools. This is a specific verb+resource with explicit differentiation.

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 explicitly advises when to use this tool vs alternatives, e.g., 'this series uses completed closes and is the one to trust for finished days' and names arena_get_volatility_phases, arena_get_iv_snapshot, and arena_get_cycle as related. It also provides practical guidance on using from/to for windows and granularity/fields for long ranges, plus free-tier limits.

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