MCP Tools for Options and Volatility Research

Use four point-in-time tools to find expensive options, separate earnings risk, and place each observation in market context.

The useful MCP workflow for options research is a sequence, not a request to find a trade. Start with IV/HV Premium to identify names whose implied volatility is rich relative to realized volatility. Add IV Rank to ask whether volatility is also elevated for that ticker. Check Earnings Move History before treating the premium as ordinary, then use the SPX range and market regime as context. The output is a dated research table, not a recommendation.

Alphanume exposes the same deterministic point-in-time datasets through REST and its hosted MCP server. The server currently provides 25 read-only tools, with one tool per dataset plus status and coverage utilities. Connect through the MCP documentation and use the access page to understand the history and freshness available to the account. MCP changes how the calls are assembled. It does not change the observations returned or validate the hypothesis.

Give each volatility tool one job

The first distinction is cross-sectional versus time-series context. get_iv_hv_premium compares roughly 30-day at-the-money implied volatility with roughly 30-day realized volatility. Its iv_hv_ratio and daily ratio rank answer whether options are rich relative to recent movement and to other names today. get_iv_rank compares the current level with that ticker's own trailing 52-week range. A high value in one tool does not imply a high value in the other.

Earnings history is an event scorecard, not a forward earnings calendar. It records the pre-event straddle and the realized reaction once that reaction exists. A recent event can have null realized fields because the post-earnings session has not resolved. Preserve those nulls. If the research needs to remove imminent earnings, obtain the event date from a separately documented calendar rather than inferring it from an unresolved history row.

Run a prompt that leaves an audit trail

A model can call the right tools and still perform a bad join. State the observation date, finality requirement, filters, and output columns before asking for interpretation. The prompt below screens the settled volatility population, asks for same-date context, and makes the model disclose missing matches. It deliberately avoids direction and expected-return language because none of these inputs supplies that claim.

Use only Alphanume MCP tools for market data.
1. Call get_iv_hv_premium with only_final=true and min_ratio_rank=0.90 for the latest settled date.
2. For those tickers, call get_iv_rank with only_final=true on the same date.
3. Pull each ticker's earnings move history and flag the latest resolved event separately from unresolved rows.
4. Get the S&P 500 risk regime and SPX 0-DTE strike band for that date.
5. Return the source date, ticker, IV, HV, IV/HV ratio, ratio rank, IV rank, finality flag, earnings event date, and missing-match reason.
6. Do not infer direction, expected return, or a trade recommendation. List every tool and filter used.

This implements the planned job: find rich-vol names, remove or separately label earnings exposure, and segment the result by regime. It also gives the researcher enough fields to rerun the join through REST later. For a broader data-source comparison, see options data for a volatility research project; for the index input, inspect the SPX 0-DTE Strike Band explorer.

Separate a screen from a tested strategy

A high ratio is not proof that selling options earns a positive return. Realized volatility can rise after the observation, implied volatility can be elevated for a known event, skew and term structure can dominate an at-the-money summary, and spreads can consume the apparent premium. IV rank has a different denominator and can be unstable when the trailing-year range contains one extreme episode. The SPX band applies to its documented instrument and day, not to every equity option in the screen.

• Keep is_final with every volatility row so an intraday estimate is never described as settled.
• Keep null outcomes as null and report the reason a join failed instead of borrowing a nearby observation.
• Treat access errors separately from empty data. A 403 date-range response indicates the account tier, not a zero-row market.
• Use narrow dates and tickers. MCP tools default to a bounded row count, so a broad response can be truncated.

Reproduce one date before expanding

Choose one completed trading date and save two artifacts: the raw tool responses and the final joined table. Verify that every row uses the same settled date, that no earnings outcome was available only afterward, and that the response reports all filters. Then rerun the same screen through the documented REST endpoints and compare row counts and values. Once the two interfaces agree, expand the date range and define a return measurement before calling the screen a strategy test.