Skip to main content
Glama

Backtesting Arena

Get BTC Volatility History (RV + ATR%)

arena_get_volatility_history
Read-only

How volatile has Bitcoin been? Daily Bitcoin volatility time series: realized volatility (30d & 90d, √365-annualized — calendar days, the same basis as DVOL — 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]

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "arena_get_volatility_history"
  }
}

Input 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.
formatNoDefault '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).
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. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / days / maximum
      Added value: +9007199254740991
  2. Changed1 schema field changed
    • 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"
      +}
  3. 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"
      -]
  4. 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."
  5. 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."
  6. 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"
      +}
  7. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past readOnlyHint: discloses data provenance (stitched pre-Binance close series back to 2009), a real null condition (ATR null before the Binance era, see meta.coverage), rank methodology trade-offs (look-ahead-free vs. trailing 2-year rolling), the free-tier cap, and that every response carries a `size` block with measured savings. These are exactly the caveats an agent needs to avoid misinterpreting results.

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?

Leads with the user-facing question and is front-loaded with metric definitions before any optimization advice. However, the payload-size advice restates a fair amount of what the `fields`/`format`/`schema_version` schema descriptions already say, which lengthens an already dense paragraph.

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?

With 8 all-optional parameters and no output schema, the description still covers what the response contains (series / series_columns, meta, size block) and the coverage caveat. Nothing an agent needs to call this correctly or interpret the output 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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter strategy the schema does not: combine `format: "columns"` with `schema_version: "2026-08"`, `fields: "minimal"` and `meta: "minimal"` for the real saving, and the warning that dropping fields alone 'saves less than it looks'. It does not clarify the precedence of `days` vs `from`/`to` beyond what the schema already states.

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?

Names the exact resource ('Daily Bitcoin volatility time series') and the two metrics returned (realized volatility 30d/90d, √365-annualized; ATR% Wilder EMA-14), plus the rank variants. An agent can immediately distinguish this from arena_get_iv_snapshot or arena_get_volatility_phases without opening the 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 when-to-use routing: 'Use `from`/`to` for a specific window instead of pulling everything', and a direct comparison with arena_get_iv_snapshot ('its realized_vol_30d is computed at snapshot time… this series uses completed closes and is the one to trust for finished days'). It also names arena_get_volatility_phases and arena_get_cycle as the right neighbours for adjacent questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.