Ava Advisor

Options Sentiment

options_sentiment

Read-only

What the US OPTIONS MARKET is saying — the POSITIONING lens (~547 popular US optionable names, stocks + ETFs). Pairs with the news→impact read: for "how is doing?" fetch THIS and stock_impact/news_feed and fuse them (news = what's happening + WHY; options = how the market is positioned — direction lean via put/call, fear/greed via skew, IV level, dealer-gamma stability, max-pain pinning, notable expiries). For a name the user HOLDS it shows how the market is hedging that position. Broad-INDEX question → pass the liquid ETF proxy: S&P 500→SPY, Nasdaq 100→QQQ, Dow→ DIA, Russell 2000→IWM, 20y Treasuries→TLT, Gold→GLD. Tickers = bare US symbol or SYMBOL.US (NVDA/NVDA.US); US-only. style = plain (everyday language, default) | technical.

TWO MODES:
• SINGLE deep read — pass `ticker=<one>` (+ optional `as_of`). Returns the FULL narrative payload
  (horizons, buckets, per-signal `read`+`because`, `_guide`). Use for a focused "how is NVDA doing".
• BATCH / COMPARE — pass `tickers=[...]` and/or `dates=[...]` → ONE call returns a COMPACT grid, one
  small row per (ticker × date) cell: `spot`, `positioning_score` ([-1,+1], + bullish), per-horizon
  positioning, and medium-term signal `reads`. THIS is how you answer "NVDA vs AAPL, last week vs
  this week" — do NOT fire the single tool N×M times. `dates=[]` (omit) → a single "latest" column.

📅 HISTORICAL: `as_of`/`dates` = ISO date/timestamp; the snapshot AT-OR-BEFORE that instant. A bare
date (`2026-07-15`) is read as END of that day. Every response carries `available_from`/`available_to`
(the stored window); a cell whose date predates it comes back `covered:false` with the range — relay
THAT honestly (say history only goes back to `available_from`), never invent an older reading.
⚠️ Narrate from `read`+`because` (or the batch `reads`); DON'T recompute, DON'T compare raw O/S or IV
across assets, `baseline_pending`/`level` ≠ "unusual" (only a `_percentile`/`_rank` read flags
unusual), and the VERDICT is YOURS (opana stops at interpretation). Not covered → `{covered:false}`:
say options data isn't available and use the news/impact read instead — never fabricate.

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_sentiment"
  }
}

Input Schema

Name	Required	Description	Default
`as_of`	No	As-of date YYYY-MM-DD (point-in-time positioning).
`dates`	No	Specific expiry dates YYYY-MM-DD to focus the read on.
`style`	No	Narration style: `plain` (layperson, default) \| `technical`.	plain
`ticker`	No	A US-listed OPTIONABLE ticker OR a plain company name (resolved server-side) — ~547 names — or an index-ETF proxy (S&P→SPY, Nasdaq→QQQ). Non-US / uncovered → `covered:false` (not an error).
`context`	No	OPTIONAL but RECOMMENDED — paste the user's FULL request VERBATIM (any language: 'ขอราคาผลไม้ apple', 'compare Apple and Microsoft stock'). The server uses it to disambiguate which candidate each `ticker` entity means (the apple COMPANY vs the fruit COMMODITY; which Samsung). One context per call, shared by all tickers here.
`tickers`	No	Batch form — several tickers at once (instead of `ticker`).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds substantial unseen behavior: a ~547-name US-only coverage universe, snapshot AT-OR-BEFORE semantics, the `available_from`/`available_to` stored window, `covered:false` returns for out-of-range dates, and explicit anti-hallucination guidance (never invent an older reading, `baseline_pending`/`level` ≠ "unusual"). It also discloses that the final verdict is the caller's responsibility.

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 core purpose, then cleanly sectioned into "TWO MODES" and "HISTORICAL" blocks, and the batch-vs-single rule is stated where it matters. It is on the long side with heavy emphasis formatting and some repetition of the coverage limit, which keeps it just short of maximally tight.

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 carries the full burden and does so: it describes the single-mode narrative payload (horizons, buckets, per-signal `read`+`because`, `_guide`) and the batch compact grid (`spot`, `positioning_score` in [-1,+1], per-horizon positioning, medium-term `reads`). Error and edge-case returns are covered, so an agent knows what to expect and how to relay it.

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; the description earns extra for explaining ticker formats (`NVDA` or `NVDA.US`), the plain/technical style distinction, and that a bare date is read as end-of-day. However, it conflicts with the schema on `dates`: the description treats `dates` as batch comparison columns ("one small row per (ticker × date) cell"), while the schema calls it "specific expiry dates ... to focus the read on" — a semantic ambiguity the agent must resolve.

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?

The description names a specific lens ("POSITIONING lens") and enumerates the exact signals returned: put/call direction lean, skew-based fear/greed, IV level, dealer-gamma stability, max-pain pinning, and notable expiries. It also explicitly separates itself from the news-based siblings `stock_impact`/`news_feed` ("news = what's happening + WHY; options = how the market is positioned"), so an agent can choose without opening 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 Guidelines5/5

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

It gives concrete when-to-use routing ("for 'how is <X> doing?' fetch THIS *and* `stock_impact`/`news_feed` and fuse them"), a when-not-to-use rule ("do NOT fire the single tool N×M times" — use batch instead), and a mapping table for index questions (S&P→SPY, Nasdaq→QQQ, Dow→DIA, Russell→IWM, Treasuries→TLT, Gold→GLD). Fallback behavior for uncovered names is also specified.

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

All Ava Advisor 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.