Skip to main content
Glama

Alphanume Datasets

IV Rank & Percentile (52-week)

get_iv_rank
Read-onlyIdempotent

IV Rank & IV Percentile (52-week): answers "is this name's volatility high or low for itself?" For each US optionable equity, per trading day: where current ~30-day implied vol and 20-day realized vol sit inside that name's own trailing-year range -- iv_rank/hv_rank (0-100 position between the 52w low and high), iv_percentile / hv_percentile (share of the past year's days below today), the 52w high/low/median levels themselves, and daily cross-sectional ranks/z-scores for context. Rows update intraday and settle after the close (is_final=1).

The classic premium-selling timing filter: min_iv_rank=50 finds names in the upper half of their own vol range regardless of absolute vol level.

Requires an Alphanume Pro API key. A 403 PRO_SUBSCRIPTION_REQUIRED or DATE_RANGE_RESTRICTED error means the key's plan does not cover the request -- it does not mean the data is missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoExact date, YYYY-MM-DD. Cannot be combined with the date range parameters.
tickerNoTicker symbol filter, e.g. 'AAPL'. Case-insensitive.
date_gtNoStart of date range, exclusive (YYYY-MM-DD).
date_ltNoEnd of date range, exclusive (YYYY-MM-DD).
date_gteNoStart of date range, inclusive (YYYY-MM-DD).
date_lteNoEnd of date range, inclusive (YYYY-MM-DD).
max_rowsNoMaximum data rows to return to the client (applied after the API responds). Default 500. Use 0 for no cap. Prefer narrowing with date/ticker filters over raising this.
only_finalNoIf true, return only settled end-of-day rows (is_final=1). By default the latest value is returned, which intraday may be provisional.
max_hv_rankNoOnly rows with hv_rank <= this value, range [0, 100].
max_iv_rankNoOnly rows with iv_rank <= this value, range [0, 100].
min_hv_rankNoOnly rows with hv_rank >= this value, range [0, 100].
min_iv_rankNoOnly rows with iv_rank >= this value, range [0, 100].
min_iv_percentileNoOnly rows with iv_percentile >= this value, range [0, 100].

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The description discloses that rows update intraday and settle after the close (is_final=1), that the default latest value may be provisional, and that 403 PRO_SUBSCRIPTION_REQUIRED or DATE_RANGE_RESTRICTED errors are about plan coverage rather than missing data. These details go well beyond the annotations and materially help an agent interpret behavior and failures.

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?

The description is dense but well organized: core concept first, then update behavior, then a use case, then authentication/error context. Every sentence contributes something necessary, and no filler or vague phrasing is present.

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 13 optional parameters, no output schema, and many siblings, the description covers the essential context: the data universe, the computed metrics, update timing, filtering semantics, and the meaning of common auth errors. An agent has enough information to call the tool correctly and interpret the response.

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; the description adds value by defining what iv_rank, hv_rank, iv_percentile, and hv_percentile actually measure. It also gives min_iv_rank a practical interpretation, complementing the schema without redundantly restating each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource (IV/HV rank and percentile within each name's trailing 52-week range for US optionable equities) and the tool's core purpose: answering whether volatility is high or low relative to that name's own history. It lacks an explicit retrieval verb like 'get' or 'return', but the subject matter is specific and distinct from the listed siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete usage pattern ('min_iv_rank=50 finds names in the upper half of their own vol range') and clarifies that ranks are relative to each name's own range, not absolute levels. However, it never contrasts this tool with closely related siblings such as get_iv_hv_premium or get_vol_of_vol, so an agent gets no explicit 'when to use this vs. that' guidance.

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.

TDQS

A4.2/5.0
Disambiguation4/5

Each tool maps to a distinct dataset, and the descriptions are detailed enough to resolve most ambiguity. A few adjacent pairs (S-1 dilution vs. shelf registrations, IV-HV premium vs. IV rank, FDA votes vs. FDA adverse events) share thematic surface area and could be confused by name alone.

Naming Consistency4/5

The overwhelming majority of tools follow a clean get_<noun_phrase> snake_case pattern. The two exceptions, check_api_status and list_market_cap_tickers, are semantically appropriate utility/companion tools but break the otherwise uniform verb prefix.

Tool Count3/5

At 27 tools, the surface is heavy and spans many unrelated financial domains, making selection and prompt context more expensive. Each tool does earn its place as a distinct dataset, but the server would benefit from some consolidation or a higher-level catalog tool.

Completeness4/5

As a read-only datasets API, the surface is broadly complete: status checking, pagination, and one coverage-map companion exist where needed. Minor gaps include the absence of a global dataset catalog/coverage listing and the lack of companion list tools for most other datasets.

Resources