Skip to main content
Glama

Option Chain Session

GetOptionChainSession
Read-only

Get one session's bars across one expiration, by strike: open, high, low, close, volume, VWAP and trades for every contract, active or expired. Use it for how a chain traded on a past date; GetOptionExpirations with expired=true lists past expirations. A larger expiration returns the strikes nearest that session's stock close; narrow with minStrike/maxStrike and type. History begins in early 2024. Plus can read a session 30 minutes after the stock close; the Free plan is answered with an upgrade note. Open interest, greeks and bid/ask have no history; implied volatility history is GetOptionVolatilityHistory. 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>",
      "date": "<date>",
      "expiration": "<expiration>"
    },
    "name": "GetOptionChainSession"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesThe session in YYYY-MM-DD format
typeNoContract type: call or put (default: both)
tickerYesUS stock ticker, e.g. AAPL
maxStrikeNoOnly include strikes at or below this price
minStrikeNoOnly include strikes at or above this price
expirationYesThe expiration in YYYY-MM-DD format
maxResultsNoMaximum contracts to return (default: 60, max: 500)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses history start (early 2024), plan gating (Plus can read 30 minutes after stock close; Free gets an upgrade note), truncation behavior for large expirations (nearest strikes to the session's stock close), and US-ticker-only scope. These are real operational constraints an agent could not infer from the annotations.

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?

Payload and scope come first, then alternatives, then constraints, so the important part is front-loaded. The text is dense with short clauses but nearly every one carries distinct information; only the plan-gating sentence is slightly tangential to the core call.

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 characterizes the return shape by listing the per-contract metrics, and it covers history depth, filtering behavior, plan limits, and geographic scope. Nothing material for a correct invocation appears 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 the baseline is 3, but the description adds genuine meaning: minStrike/maxStrike and type exist to narrow results because a large expiration returns only strikes nearest the session's stock close. It does not discuss maxResults, though the schema documents it adequately with a default and maximum.

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 verb and resource (get one session's bars for one expiration, by strike) and enumerates the returned fields: open, high, low, close, volume, VWAP and trades. It also scopes coverage to active or expired contracts, which separates it from GetOptionContractHistory and GetOptionChain.

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?

Explicitly frames the use case ('how a chain traded on a past date') and routes to siblings: GetOptionExpirations with expired=true for finding past expirations and GetOptionVolatilityHistory for IV history. It also states what is not available (open interest, greeks, bid/ask history), which prevents misuse.

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.