BytNode

Get Options Data

get_options_data

Read-only

Options and spot ETFs of ONE asset (BTC or ETH, never a pair). No window = current value; since_ms/until_ms/last = history. Rows newest first, dated at the START of their bucket (first_time + i x step_s); for a total, an extreme or a change read summary, for the period covered read ranges; null + unavailable = no data; _pct = percent, _ratio = fraction; every unit: describe_fields.

expiries=true: active expiries with, PER EXPIRY, OI calls/puts, put/call, max pain, top strikes, ATM IV (options_summary and options_put_call_ratio are totals).
options_max_pain: every active expiry, nearest first (limit=N: N nearest); its history needs expiry. options_oi_distribution: one expiry is much smaller.
etf_fundamentals: QUARTERLY SEC filings per issuer (no daily flows); ticker keeps one.

EXAMPLE: nearest expiry: asset=BTC, expiries=true

FIELDS:

options_summary: Options overview: OI, volume, put/call, ATM IV, nearest expiry. [now, 1 point]
options_oi: Open interest, calls and puts, USD. [tf with N or history]
options_oi_change: OI change, calls and puts, USD. [tf with N or history]
options_oi_distribution: Open interest by strike, per expiry. [expiry, now, 1 point]
options_volume: Volume, calls and puts, USD. [tf with N or history]
options_put_call_ratio: Put/call ratio (open interest) and label. [tf with N or history]
options_iv: ATM 30-day implied volatility (%). [tf with N or history]
options_iv_klines: Candles of the ATM 30-day implied volatility (%). [tf with N or history]
options_max_pain: Max pain strike of each active expiry. [history needs expiry]
options_greeks: Aggregated greeks: delta, gamma, theta, vega. [now, 1 point]
etf_fundamentals: Spot ETF filings per issuer: shares, NAV, net assets, holdings. [ticker in history]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "asset": "<asset>"
    },
    "name": "get_options_data"
  }
}

Input Schema

Name	Required	Description	Default
`last`	No	History over the last '48h' / '30d' (whole buckets).
`asset`	Yes	The asset.
`limit`	No	N latest points per series (default 1).
`detail`	No	summary: one row per series + summary; full: every column.	compact
`expiry`	No	Expiry YYYY-MM-DD.
`fields`	No	Fields (FIELDS below).
`ticker`	No	ETF issuer (IBIT) of etf_fundamentals.
`columns`	No	Columns to keep, e.g. ["close", "volume"].
`context`	No	Adds `context`: where each series' latest value sits in its own recent history (percentile, z, n, window). Not a signal; no quota.
`dry_run`	No	Plans the call without making it: its quota cost, your remaining rate and quota, the checks. No data, no quota.
`expiries`	No	Adds the active expiries.
`since_ms`	No	History start: epoch ms, ISO date or '48h' ago.
`until_ms`	No	History end.
`timeframe`	No	Step of the history.
`max_tokens`	No	Response budget, estimated tokens (default 6000).
`max_quota_cost`	No	Refuses the call, before any request, if it would use more quota requests than this.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint/destructiveHint=false, and the description goes well beyond them: row ordering (newest first), bucket timestamp semantics (first_time + i x step_s), null-plus-unavailable meaning no data, unit conventions (_pct vs _ratio), and quota behavior via dry_run/max_quota_cost. These are precisely the behaviors an agent cannot infer from annotations or 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?

Purpose is front-loaded in the first sentence, followed by rules, then a scannable FIELDS list with bracketed cadence tags. The telegraphic style packs a lot per line, but phrases like 'for a total, an extreme or a change read summary, for the period covered read ranges' are terse enough to slow comprehension and take a second read.

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 16 parameters, no output schema and no nested objects, the description carries the full burden and does so: it enumerates every field with its access pattern ([now, 1 point], [tf with N or history]), documents ordering and timestamp anchoring, and delegates unit lookup to describe_fields. Nothing an agent needs to construct a correct call appears 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 genuine cross-parameter meaning the schema lacks: per-expiry contents when expiries=true, that max_pain history requires `expiry`, that options_oi_distribution with a single expiry is a much smaller response, and that `ticker` narrows etf_fundamentals to one issuer. It does not spell out detail=compact/full behavior beyond the schema's own text.

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 verb+resource and scope: options and spot ETF data for ONE asset (BTC or ETH, never a pair). The parenthetical exclusion separates it from pair-oriented siblings, and the FIELDS block enumerates exactly what can be retrieved, so an agent knows what it is before reading any 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?

Gives explicit temporal routing (no window = current value; since_ms/until_ms/last = history) and field-selection guidance (use summary for totals/extremes/changes, ranges for period coverage; options_oi_distribution with one expiry is much smaller than max_pain). It also points to describe_fields for units and includes a worked EXAMPLE, though it never states a hard 'use X tool instead' exclusion beyond the pair caveat.

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

All BytNode 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.

Resources

Need Help?