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, √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]

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. 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"
+}
  2. 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"
-]
  3. 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."
  4. 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."
  5. 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"
+}
  6. Added

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 data provenance (stitched pre-Binance close series reaching to 2009), a data caveat (ATR null before the Binance era, see meta.coverage), that trend-expansion ranks are look-ahead-free while rolling ranks use a trailing 2-year window, the free-tier 365-day limit, a size block for measuring savings, and the 2026-11-01 default schema flip. This is unusually complete behavioral context.

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 and then the series definition before any optimization advice. It is dense with parentheticals and runs long, but almost every sentence carries distinct information (rank semantics, provenance caveats, savings mechanics) rather than repetition.

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 must convey return shape, and it does: it explains rows vs. columns (series vs. series_columns), the fields enum contents, meta minimal, and the response size block. Combined with the coverage caveats and tier limits, an agent has what it needs to call 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 description coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description adds real meaning beyond it by explaining how parameters interact (columns + schema_version + fields + granularity + meta stack into a combined saving measured by the size block) and warning that dropping fields alone saves less than it looks.

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 resource (daily BTC volatility time series) and the exact measures returned: realized volatility (30d/90d, √365-annualized) and ATR% (Wilder EMA-14). It explicitly differentiates itself from siblings arena_get_iv_snapshot, arena_get_volatility_phases, and arena_get_cycle, so an agent can route 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?

Gives explicit when-to-use guidance: use from/to for a specific window rather than pulling everything, use granularity/fields to keep long ranges affordable, and pass format:'columns' with schema_version:'2026-08' for maximum savings. It also resolves a genuine ambiguity against arena_get_iv_snapshot, naming the exact case (fresh breakout days) where the two series diverge and which to trust.

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