Skip to main content
Glama

Backtesting Arena

Get Deribit BTC Max Pain (latest + upcoming)

arena_get_max_pain

What happened at the last Deribit expiry? Max pain and how spot settled against it: max_pain_strike, spot_at_expiry, %-diff, put_call_ratio, notional. Plus up to 10 upcoming expiries, each with current live max-pain level, days_to_expiry, open_interest_contracts and open_notional_usd. Field semantics: days_to_expiry is floored at 0 and cannot separate "expires later today" from "already settled" — settles_at (full ISO timestamp) and hours_to_settlement (SIGNED; negative = settled but not yet finalized) carry that distinction. settlement_time_utc names the settlement time where evidenced against the exchange (08:00:00Z for DERIBIT_BTC); where not evidenced, all three timing fields are null. open_interest_contracts (upcoming: latest daily snapshot) and total_contracts (settled: last snapshot BEFORE expiry) are the SAME measurement at different observation times; contracts_as_of names the snapshot. total_notional_usd is computed against the SETTLEMENT spot and never changes; open_notional_usd uses the CURRENT spot and moves with spot (notional_spot/notional_spot_date name the reference). oi_available distinguishes "null" from "not collected". Expiry flags NEST rather than partition (quarterly ⊂ monthly ⊂ weekly ⊂ daily): filter on the booleans, read expiry_type as the label — only it separates a Friday expiry from a mid-week one. All flags are calendar-derived, so upcoming expiries carry them too. spot_at_expiry is the exchange settlement price: for DERIBIT_BTC the Deribit delivery price (30-min index TWAP before 08:00 UTC — rows before 2026-08-31 were recomputed from that series; they had carried the BTCUSDT daily close, 16 h later), for IBIT the ETF close of the expiry day. Pass market to switch venue (DERIBIT_BTC default, IBIT). include_strike_ladder=true adds, per expiry, open interest per 2.5 % price band around spot (±25 %, calls/puts, absolute contracts) with day-over-day delta — a stock, not a side: no hedge direction follows from it. include_gex=true (DERIBIT_BTC only) adds per expiry a gex block plus gex_totals across the book — Black-Scholes gamma notional per band from LIVE Deribit mark IV (gex_data_as_of names the fetch, a different observation time than the snapshot fields); the dealer sign is an ASSUMPTION, both conventions published side by side; zero_gamma_level flips only under the SqueezeMetrics convention (short-all has no zero crossing by construction, its null is structural — zero_gamma_level.note says so). With ladder or GEX, pass expiry_date to get ONE expiry instead of all upcoming ones — the full ten-expiry response with both is large. Cron collects daily 02:00 UTC from Deribit Public API. Related: arena_get_max_pain_history (base rates + daily snapshots of open expiries), arena_get_iv_snapshot (implied vol for the same expiries). [Free tier]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketNoOptions market. Only DERIBIT_BTC is served: IBIT (BlackRock spot-ETF options) is still collected daily but no longer delivered — the chain comes from an unlicensed source, so it cannot be redistributed (2026-09-24).
expiry_dateNoOptional YYYY-MM-DD of ONE open expiry: upcoming[] (and its strike_ladder/gex) is restricted to it, which keeps ladder/GEX responses small; gex_totals still covers the whole book. An expiry that is not open returns invalid_input listing the open ones. Omit for all upcoming expiries.
include_gexNoDefault false (response unchanged). DERIBIT_BTC only. When true, each upcoming expiry carries a `gex` block plus `gex_totals` across the whole book: Black-Scholes gamma notional (USD per 1 % spot move) per 2.5 % band from LIVE Deribit mark IV per strike (gex_data_as_of names the fetch, ~10 min cache — a different observation time than the 02:00 UTC snapshot fields). The dealer SIGN is an assumption, not a measurement: both conventions are published side by side (assuming_dealers_short_all, assuming_squeezemetrics_convention); where they disagree, the data does not know the answer. zero_gamma_level flips only under the SqueezeMetrics convention — short-all is <= 0 everywhere and has no zero crossing by construction (its null is structural; zero_gamma_level.note says so). Tau floor 2 h near expiry (tau_clamped flags it); instruments without usable IV are excluded and counted.
include_strike_ladderNoDefault false (response unchanged). When true, every expiry carries a `strike_ladder`: open interest per 2.5 % price band around the snapshot spot (±25 %, calls/puts separate, absolute contracts, share_pct), below_range/above_range sums, max_pain_recomputed (cross-check against the stored level) and `delta` vs the previous day's snapshot on the same band grid (null with delta_reason when there is none). OI is a stock, not a side — no hedge direction follows; the note travels with the response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / expiry_date
      Added value: +{
      +  "description": "Optional YYYY-MM-DD of ONE open expiry: upcoming[] (and its strike_ladder/gex) is restricted to it, which keeps ladder/GEX responses small; gex_totals still covers the whole book. An expiry that is not open returns invalid_input listing the open ones. Omit for all upcoming expiries.",
      +  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / market / description
      Previous value: -"Options market: 'DERIBIT_BTC' (default) or 'IBIT' (BlackRock spot-ETF options, collected since 2026-08-24; settlement-timing fields are null until evidenced)."New value: +"Options market. Only DERIBIT_BTC is served: IBIT (BlackRock spot-ETF options) is still collected daily but no longer delivered — the chain comes from an unlicensed source, so it cannot be redistributed (2026-09-24)."
    • changedInput schema / properties / market / enum
      Previous value: -[
      -  "DERIBIT_BTC",
      -  "IBIT"
      -]New value: +[
      +  "DERIBIT_BTC"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / include_gex / description
      Previous value: -"Default false (response unchanged). DERIBIT_BTC only. When true, each upcoming expiry carries a `gex` block plus `gex_totals` across the whole book: Black-Scholes gamma notional (USD per 1 % spot move) per 2.5 % band from LIVE Deribit mark IV per strike (gex_data_as_of names the fetch, ~10 min cache — a different observation time than the 02:00 UTC snapshot fields). The dealer SIGN is an assumption, not a measurement: both conventions are published side by side (assuming_dealers_short_all, assuming_squeezemetrics_convention) with a zero_gamma_level each; where they disagree, the data does not know the answer. Tau floor 2 h near expiry (tau_clamped flags it); instruments without usable IV are excluded and counted."New value: +"Default false (response unchanged). DERIBIT_BTC only. When true, each upcoming expiry carries a `gex` block plus `gex_totals` across the whole book: Black-Scholes gamma notional (USD per 1 % spot move) per 2.5 % band from LIVE Deribit mark IV per strike (gex_data_as_of names the fetch, ~10 min cache — a different observation time than the 02:00 UTC snapshot fields). The dealer SIGN is an assumption, not a measurement: both conventions are published side by side (assuming_dealers_short_all, assuming_squeezemetrics_convention); where they disagree, the data does not know the answer. zero_gamma_level flips only under the SqueezeMetrics convention — short-all is <= 0 everywhere and has no zero crossing by construction (its null is structural; zero_gamma_level.note says so). Tau floor 2 h near expiry (tau_clamped flags it); instruments without usable IV are excluded and counted."
  4. Changed1 schema field changed
    • addedInput schema / properties / include_gex
      Added value: +{
      +  "description": "Default false (response unchanged). DERIBIT_BTC only. When true, each upcoming expiry carries a `gex` block plus `gex_totals` across the whole book: Black-Scholes gamma notional (USD per 1 % spot move) per 2.5 % band from LIVE Deribit mark IV per strike (gex_data_as_of names the fetch, ~10 min cache — a different observation time than the 02:00 UTC snapshot fields). The dealer SIGN is an assumption, not a measurement: both conventions are published side by side (assuming_dealers_short_all, assuming_squeezemetrics_convention) with a zero_gamma_level each; where they disagree, the data does not know the answer. Tau floor 2 h near expiry (tau_clamped flags it); instruments without usable IV are excluded and counted.",
      +  "type": "boolean"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / include_strike_ladder
      Added value: +{
      +  "description": "Default false (response unchanged). When true, every expiry carries a `strike_ladder`: open interest per 2.5 % price band around the snapshot spot (±25 %, calls/puts separate, absolute contracts, share_pct), below_range/above_range sums, max_pain_recomputed (cross-check against the stored level) and `delta` vs the previous day's snapshot on the same band grid (null with delta_reason when there is none). OI is a stock, not a side — no hedge direction follows; the note travels with the response.",
      +  "type": "boolean"
      +}
  6. Changed2 schema fields changed
    • changedInput schema / properties / market / description
      Previous value: -"Options market. Currently only 'DERIBIT_BTC' (default). IBIT planned."New value: +"Options market: 'DERIBIT_BTC' (default) or 'IBIT' (BlackRock spot-ETF options, collected since 2026-08-24; settlement-timing fields are null until evidenced)."
    • changedInput schema / properties / market / enum
      Previous value: -[
      -  "DERIBIT_BTC"
      -]New value: +[
      +  "DERIBIT_BTC",
      +  "IBIT"
      +]
  7. 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"
      -]
  8. First observed

TDQS

A4.3/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 discharges it unusually well: it discloses the collection cadence ('Cron collects daily 02:00 UTC from Deribit Public API'), the ~10 min GEX cache and that gex_data_as_of is a different observation time than the snapshot fields, the dealer-sign ASSUMPTION with both conventions published, the structural (not missing) null in short-all zero_gamma_level, and the historical recomputation of pre-2026-08-31 rows. These are exactly the provenance/assumption caveats an agent would otherwise misread.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The answer is front-loaded (the core question leads), which is good, but the passage runs several hundred words and re-explains the GEX and strike-ladder parameters in nearly the same detail the input schema already provides, so those sentences do not fully earn their place. Density is high but so is duplication.

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?

There is no output schema and this is a rich options-analytics payload, yet the description defines the key fields (max_pain_strike, spot_at_expiry per venue, open_interest_contracts vs total_contracts, total_notional_usd vs open_notional_usd, oi_available, nested expiry flags, ladder and GEX blocks) and their observation-time distinctions. An agent has enough to interpret results correctly without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters in near-identical terms, establishing a baseline of 3. The description adds limited marginal value (rationale that ladder/GEX responses get large, notes about nesting expiry flags), and the statement 'Pass `market` to switch venue (DERIBIT_BTC default, IBIT)' actually conflicts with the schema enum, which permits only DERIBIT_BTC and states IBIT is no longer delivered.

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?

Opens with a specific framing ('What happened at the last Deribit expiry? Max pain and how spot settled against it') and enumerates the concrete return fields (max_pain_strike, spot_at_expiry, put_call_ratio, notional) plus up to 10 upcoming expiries, so the resource and scope are unambiguous. It also names two siblings (arena_get_max_pain_history, arena_get_iv_snapshot) with their distinct roles, letting an agent route without opening either schema.

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?

It routes explicitly: history tool for 'base rates + daily snapshots', iv_snapshot for 'implied vol for the same expiries', and it tells the agent to pass expiry_date when combining ladder/GEX because 'the full ten-expiry response with both is large'. What's missing is any negative guidance on when NOT to call this (e.g. vs live spot/options tools), so it stops short of a 5.

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.