Skip to main content
Glama
Sign In

feeds

by com.insidercable
OverviewDiscussionsAdmin

options_iv

Daily US equity option-chain structure per ticker, recorded forward from 2026-06-27 (~230 names, weekday close). Derived metrics only -- no quotes, strikes, greeks or spot are re-served: atm_iv_30d / atm_iv_90d (implied vol at the ~30d and ~90d expiries), iv_term (30d/90d; above 1 = backwardation/stress), skew_25d (25-delta put IV minus call IV; positive = put demand), iv_rank (percentile of today's 30d IV within THIS series' own history, with iv_hist_days saying how long that history is -- a rank over 10 days is not a rank), put/call ratios by open interest and by volume, net dealer gamma sign, max-OI call/put strikes as percent from spot, and an unusual-activity read (uoa_lean call/put/mixed from contracts with volume >= 3x open interest; EOD delayed data, no prints, so buyer vs seller is unknowable). happened_at is the trading day; observed_at is the day the chain was banked. Not backfilled; the source publishes only the current chain, so nobody can reconstruct these days.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "options_iv"
  }
}

Input Schema

NameRequiredDescriptionDefault
leanNoUnusual-activity lean on the day
paidNotrue = request the pay-per-call (x402) quote or the live tier. Without a payment attached the call returns the x402 PaymentRequired object as an isError result; attach the signed payment at _meta["x402/payment"] (or the PAYMENT-SIGNATURE header) and retry. Omit for the free, delayed tier.
sinceNoOnly trading days on/after this YYYY-MM-DD
tickerNoOne ticker, e.g. NVDA
tickersNoComma-separated tickers (max 100)
max_iv_rankNoMaximum iv_rank, 0-1 (e.g. 0.1 = vol cheap)
min_iv_rankNoMinimum iv_rank, 0-1 (e.g. 0.9 = vol rich)
min_hist_daysNoOnly rows whose iv_rank rests on at least this many days of history

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?

With no annotations, the description carries the full burden and does so well: it discloses EOD delayed data, no re-served quotes/strikes/greeks, that buyer-vs-seller is unknowable in uoa_lean, that iv_rank is series-relative with a caution about short history, the distinction between happened_at and observed_at, and critically that the data is not backfilled and cannot be reconstructed.

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?

A single dense paragraph, front-loaded with the resource and scope before drilling into metrics and caveats. Long but nearly every clause earns its place; a minor cost is that metric enumeration runs together rather than being list-structured.

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?

For an 8-param, all-optional filter tool with no annotations and no output schema, the description supplies the return-field semantics, the data-provenance caveats, and the credit/payment note. Nothing an agent needs to call it correctly is 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 baseline is 3, but the description adds conceptual meaning that maps to the filter params: the iv_rank percentile semantics explicitly underpin min_iv_rank/max_iv_rank/min_hist_days, and the 'no quotes/strikes' framing clarifies what lean and the metric filters operate over. The ticker/tickers/since/paid params are left to the schema.

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 US equity option-chain structure per ticker) with explicit scope: ~230 names, weekday close, derived metrics only, and enumerates the exact fields served (atm_iv_30d, iv_term, skew_25d, iv_rank, put/call ratios, dealer gamma, max-OI strikes, uoa_lean). An agent knows precisely what this returns and how it differs from any quote/tick source.

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?

Usage is implied by the content description and the free-vs-paid caveat, but there is no explicit 'use this when...' routing or mention of alternatives. Siblings (congress_trades, etf_flows, insider_*) are unrelated domains, so differentiation is implicit rather than stated.

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

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