Skip to main content
Glama
Sign In

Equibles

by io.github.daniel3303
OverviewDiscussionsAdmin

Option Volatility History

GetOptionVolatilityHistory
Read-only

Get a stock's daily implied volatility history, newest first: constant-30-day implied volatility (IV30), IV rank and IV percentile over the trailing year, the at-the-money IV of the near and far expirations, and 30-day realized (historical) volatility. Use it for historical IV, IV rank, IV percentile, implied versus realized volatility, and whether volatility is high or low against its own past. Two bases are stated apart and never blended: derived, our model on each session's at-the-money option closes (ranked, from 2024-01-18), and quoted, the source's model captured in the session's last quarter hour (from launch, unranked); each row carries its contract and trade counts. A stock whose history is still being built answers with the sessions it has; the rest appears over the following days. startDate and endDate set the window (default: the last year). Plus and Pro read it; the Free plan is answered with an upgrade note. US tickers only.

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": {
      "ticker": "<ticker>"
    },
    "name": "GetOptionVolatilityHistory"
  }
}

Input Schema

NameRequiredDescriptionDefault
tickerYesUS stock ticker, e.g. AAPL
endDateNoLast session in YYYY-MM-DD format (default: today)
startDateNoFirst session in YYYY-MM-DD format (default: a year before endDate)
maxResultsNoMaximum sessions to return, newest first (default: 60, max: 500)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare a safe read; the description adds substantial context the annotations do not carry: two provenance bases (derived vs quoted) that are never blended, the differing start dates and ranking availability for each, per-row contract and trade counts, partial-history behavior for newly tracked stocks, and plan gating where Free receives an upgrade note instead of data.

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 verb and returned data, then progressively narrower detail on provenance, backfill, and access. Dense but nearly every clause carries information; the 'Two bases are stated apart and never blended' framing is slightly ceremonial but justifies a real distinction.

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 no output schema, the description still describes what each row contains and in what order, plus how partial histories and plan tiers behave. An agent has everything needed to call it and interpret the result.

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 coverage is 100%, so the baseline is 3. The description restates the date-window role of startDate/endDate and the newest-first ordering, but adds no format or edge-case detail beyond what the schema already documents (YYYY-MM-DD, defaults, max 500).

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 and resource ('Get a stock's daily implied volatility history, newest first') and enumerates exactly which series come back (IV30, IV rank, IV percentile, near/far ATM IV, realized volatility). That is enough for an agent to separate it from neighbors such as GetOptionContractHistory or GetVixHistory without inspecting 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?

Explicitly lists the analytical questions it answers ('historical IV, IV rank, IV percentile, implied versus realized volatility, and whether volatility is high or low against its own past') and the plan/ticker constraints. It stops short of naming a sibling alternative or a when-not-to-use case, so it is clear context without exclusions.

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

All Equibles 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