This is options-chain-mcp, a read-only options research server for AI assistants via MCP, using pluggable data providers (Tradier or Alpaca).
find-options-chain: Fetch a filtered options chain for a symbol and expiration, keeping only liquid contracts (volume/bid/ask > $0.10) and strikes within a configurable percentage of the underlying price. Optionally include Greeks/IV and filter by call, put, or both.
find-option-expirations: List all valid expiration dates for a given underlying symbol.
get-quote: Get the latest quote for a stock or a single OCC option contract, including Greeks and implied volatility when supported by the provider.
historical-prices: Retrieve OHLCV bars for stocks or OCC options over a date range, with daily, weekly, or monthly intervals and optional session filtering.
It is intentionally read-only (no trading or order management), LLM-friendly (server-side filtering reduces token usage), and supports dual deployment: local via stdio for Claude Desktop or remote on Cloudflare Workers with OAuth.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@options-chain-mcp Show me the options chain for AAPL with the nearest expiration."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only MCP server for options research. Pluggable data provider — currently supports Tradier and Alpaca.
npx -y options-chain-mcpYou must bring your own market data credentials. Unlike a server that wraps a free public API, this one talks to a brokerage data provider on your behalf, so it needs a
TRADIER_TOKEN, or anALPACA_API_KEY_ID+ALPACA_SECRET_KEY, in its environment. Free sandbox/paper accounts work fine — see Choosing a data provider. Started without credentials, the server exits immediately and prints which variable is missing.
This Model Context Protocol (MCP) server gives AI assistants the tools to research options, without any ability to place trades:
find-options-chain — chain for a symbol + expiration, filtered to options with real volume/bid/ask and strikes within a percentage of spot. Automatically trims to significant strikes to keep the payload LLM-friendly.
find-option-expirations — valid expiration dates for an underlying.
get-quote — latest quote for a stock symbol or a single OCC option contract. Includes Greeks + IV when the provider supports them (Alpaca does; Tradier requires a chain lookup).
historical-prices — OHLCV bars for a stock or OCC option over any range and interval.
The server runs two ways:
Locally over stdio for Claude Desktop
Remotely on Cloudflare Workers with OAuth 2.1, for Claude.ai and other MCP clients that speak the remote-connector protocol
Please note:
Requires API credentials for whichever provider you use (free paper/sandbox accounts work)
Market data on free plans is typically 15-min delayed
Intended for informational purposes only
Users can run queries using natural language.
Related MCP server: thetadata-mcp
Built for LLM context budgets. A typical underlying has hundreds of strikes across dozens of expirations. Calling a raw get_option_chain from the official Alpaca server returns all of them — every dead far-OTM strike, every penny-bid contract, every field the API exposes. That payload eats thousands of tokens per call and forces the model to filter the noise itself. This server filters server-side:
Strikes are pre-filtered to a configurable percentage band around spot
Dead contracts are dropped (volume > 0 OR open_interest > 0 and bid/ask > $0.10)
A "significant strikes" pass keeps round-numbered strikes at distance and finer-grained strikes near the money — mimicking how a human trader actually reads a chain
Only the fields a research workflow needs are returned (no exchange codes, no raw timestamps, no boilerplate)
In practice a NVDA chain comes back as ~15 strikes instead of ~400 — roughly 20–40× fewer tokens per call, leaving room for actual analysis in the conversation.
Other things going for it:
Read-only by design. No place_order, no close_position, no exercise_options_position. Point an LLM at it without worrying about hallucinated trades.
Provider-pluggable. Tradier and Alpaca behind one identical tool surface. Swap with one env var; if one provider's data goes stale or the account expires, fall over to the other without changing prompts or client config.
Remote OAuth deployment included. Works from claude.ai web (and any other OAuth-aware MCP client), not just locally-connected Claude Desktop. The official Alpaca server is stdio-only.
Q: What are the highlights of the SPY options chain for two weeks out?
A: I'll check the current SPY options chain for two weeks out from today.
View Result from find-options-chain from options-chain (local)
{
"symbol": "SPY",
"expiration": "2025-03-28"
}Now that I have the SPY options chain for March 28, 2025 (two weeks out), I'll highlight the key information:
Current Market Context
Current SPY price appears to be around $565-566 based on the at-the-money options
Highest Volume:
$590 calls with 217 contracts traded
$600 calls with 174 contracts traded
$571 calls with 130 contracts traded
Highest Open Interest:
$600 calls: 8,299 contracts
$590 calls: 6,591 contracts
$605 calls: 4,676 contracts
$580 calls: 4,596 contracts
Notable Activity:
Far out-of-the-money calls ($590-$600) showing significant volume, suggesting some traders are positioning for potential upside movement
The $590 calls (priced at $1.07-$1.09) have high volume and open interest
Highest Volume:
$500 puts with 217 contracts traded
$460 puts with 160 contracts traded
$510 puts with 163 contracts traded
Highest Open Interest:
$525 puts: 79,196 contracts (extremely high)
$530 puts: 7,060 contracts
$550 puts: 4,883 contracts
$570 puts: 4,337 contracts
Notable Activity:
The massive open interest in $525 puts is striking, suggesting a significant hedging position
Overall put activity shows traders protecting against downside risk
Looking at the pricing, implied volatility appears moderate
The put-call ratio based on open interest is skewed toward puts, suggesting market participants are hedging against downside risk
There's higher open interest in OTM puts than OTM calls, indicating traders are more concerned about downside protection than upside speculation
Requires Node.js 20 or newer. No install step is
needed — npx fetches the server on first run. You do need credentials for one of the
two data providers; see Choosing a data provider.
There are two ways to run this server, and they authenticate differently:
Local (stdio, | Remote (Cloudflare Workers) | |
Client authentication | none — runs as a local subprocess | OAuth 2.1 with a passcode |
Provider credentials | yours, in the client's | yours, as Worker secrets |
Who it suits | you, on your own machine | you across devices, or people you share the passcode with |
Whose API quota | the local user's | the deploying account's |
Local setup is covered directly below; remote setup is under Running on Cloudflare Workers.
claude mcp add options-chain --env TRADIER_TOKEN=your_token -- npx -y options-chain-mcpThe server speaks MCP over STDIO. Run it with npx -y options-chain-mcp, or install it
globally with npm install -g options-chain-mcp and run options-chain-mcp, with the
provider credentials present in the environment.
npm install # install dependencies
npm run dev:stdio # run the stdio server from source
npm run build # compile TypeScript to build/
npm run typecheck # type-check both the stdio and Workers configs
npm run dev # run the Cloudflare Workers version locally
npm run deploy # deploy the Workers versionTool definitions live in src/tools.ts and are shared by both entry points:
src/index.ts (stdio) and src/worker.ts (Cloudflare Workers). Provider-specific
code lives in src/providers/.
build/ is generated and not checked in — run npm run build before pointing Claude
Desktop at a local build.
The server supports two providers. Set the credentials for whichever you want and (optionally) DATA_PROVIDER to pick explicitly. If DATA_PROVIDER is unset, Alpaca is used when both Alpaca keys are set, otherwise Tradier.
Provider | Env vars | Notes |
Tradier sandbox |
| 15-min delayed. Sandbox tokens expire — dashboard lets you regenerate. |
Alpaca |
| Paper account key works fine. Free |
See sample.env for optional overrides (feed selection, base-URL overrides for live accounts).
Field | Tradier | Alpaca |
| Daily total |
|
| Returned natively | Fetched from the trading API's contracts endpoint and merged in |
Greeks + IV on free tier | Yes (when | Yes (free |
The chain filter treats volume > 0 OR open_interest > 0 as "real market interest," so dead strikes get dropped on either provider. When you see "volume": null in an Alpaca response, that means the provider doesn't report it — not that the contract is inactive. Use open_interest for liquidity assessments on Alpaca.
Open your Claude Desktop configuration at:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the server configuration (using whichever provider you want):
{
"mcpServers": {
"options-chain": {
"command": "npx",
"args": ["-y", "options-chain-mcp"],
"env": {
"TRADIER_TOKEN": "your_tradier_sandbox_token"
}
}
}
}To run a local build instead, use "command": "node" with
"args": ["/full/path/to/options-chain/build/index.js"] after npm run build.
Or for Alpaca:
"env": {
"ALPACA_API_KEY_ID": "your_key_id",
"ALPACA_SECRET_KEY": "your_secret"
}Close/Quit then restart Claude Desktop
Once you restart you should see a small hammer icon in the lower right corner of the textbox. If you hover over the icon you'll see the number of MCP tools available.
The legacy lowercase
tokenenv var is still accepted for backward compatibility with older configs.
The Worker entrypoint (src/worker.ts) exposes the same tools over MCP's SSE and Streamable HTTP transports, wrapped in an OAuth 2.1 provider. Claude.ai (web and desktop) discovers the endpoints automatically via Dynamic Client Registration.
A Cloudflare account on any paid Workers plan (Durable Objects are used for MCP session state)
Wrangler authenticated: npx wrangler login
A KV namespace bound as OAUTH_KV (create with npx wrangler kv namespace create OAUTH_KV and paste the ID into wrangler.jsonc)
For Tradier:
npx wrangler secret put TRADIER_TOKENFor Alpaca:
npx wrangler secret put ALPACA_API_KEY_ID
npx wrangler secret put ALPACA_SECRET_KEY
# optional:
npx wrangler secret put DATA_PROVIDER # "alpaca" or "tradier"And the auth passcode that gates the consent page:
npx wrangler secret put APPROVE_PASSCODE # e.g. `openssl rand -base64 18`For local dev, put the same keys in a .dev.vars file at the repo root (gitignored).
npm run dev # local dev server with hot reload
npm run deploy # publish to <name>.<account>.workers.devIn Claude.ai → Settings → Connectors → Add custom connector:
URL: https://<your-worker>.workers.dev/sse (or /mcp for Streamable HTTP).
Leave client ID/secret blank — the server advertises Dynamic Client Registration.
Save and click connect. Claude opens a consent page; enter the APPROVE_PASSCODE you set above.
You'll be redirected back, authorized. Tokens refresh for 30 days.
For multi-user access or SSO, put Cloudflare Access in front of the Worker route. The OAuth flow still works for the MCP client; Access just adds a second layer for the human consent page.
If Claude Desktop cannot find npx, provide its full path (on macOS, typically
/usr/local/bin/npx or /opt/homebrew/bin/npx). The same applies to node if you are
running a local build.
If the server does not appear at all, check Claude Desktop's logs — the server now writes a specific reason to stderr (for example, missing provider credentials) instead of exiting silently.
List valid option expiration dates for an underlying symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Underlying symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as authentication requirements, rate limits, or whether it returns only future dates. The term 'valid' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. Efficient but lacks additional structuring. Appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return format or constraints. It is incomplete—does not clarify what 'valid' means or if dates are formatted in a specific way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter. The description adds no new semantic meaning beyond restating the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'list' and the resource 'valid option expiration dates' for a given symbol. It distinguishes from sibling tools like historical-prices or get-quote, but 'valid' could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The description does not provide context on when it is appropriate or when to consider alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the data provider for the options chain of a symbol on a specific expiration date. The result is filtered to options with volume, bid, and ask greater than 0.10 and strikes within a configurable percentage of the underlying price. If nothing is found the result may be empty — check that the symbol and expiration are valid.
| Name | Required | Description | Default |
|---|---|---|---|
| greeks | No | Whether to include greeks/IV in the response | |
| symbol | Yes | The underlying symbol | |
| expiration | Yes | Expiration date formatted as YYYY-MM-DD | |
| option_type | No | Filter by option type | both |
| strike_percentage | No | Percentage distance from the underlying price to include strikes (e.g. 10 = ±10%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: data provider query, filtering by volume/bid/ask >0.10, strike percentage, and behavior when nothing found. This is good transparency for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, filtering criteria, and an edge case. No extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers purpose, filters, and result emptiness. It lacks mention of return format but is sufficiently complete for a query tool. Minor gap: does not describe pagination or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining filtering logic (volume/bid/ask thresholds, strike percentage) that is not in parameter descriptions. This helps the agent understand how parameters influence results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool queries for options chain of a symbol on a specific expiration date, and lists key filtering criteria. It clearly distinguishes from siblings like historical-prices and get-quote which are for different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving filtered options data but does not explicitly compare to siblings or provide when-to-use/when-not-to-use guidance. It does mention an edge case (empty result) and suggests checking validity, which is helpful but not full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest quote for a stock symbol or single OCC option contract. For option symbols the response includes Greeks and implied volatility when the provider supports it.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol (e.g. AAPL) or OCC option contract (e.g. AAPL250117C00150000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries disclosure burden. Mentions that for option symbols, response includes Greeks and IV when supported, which is useful. However, does not clarify if tool is read-only, rate limits, or response structure beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver core information efficiently. Front-loaded with main action, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-parameter tool without output schema. Covers basic purpose and a key behavioral nuance. Could be more complete by describing standard response fields (e.g., price, volume) but that is often assumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the symbol parameter with examples (100% coverage). The description adds meaning by clarifying that option symbol inputs yield additional data (Greeks/IV), which helps the agent understand parameter-dependent behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Get' with resource 'latest quote' clearly states the action. Distinguishes from siblings (historical-prices, find-option-expirations, find-options-chain) by focusing on current data for stocks or single option contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for obtaining latest quotes but does not explicitly state when not to use or mention alternatives like historical-prices for past data. No direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical OHLCV bars for a stock symbol or OCC option contract over a time range.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End date in YYYY-MM-DD | |
| start | Yes | Start date in YYYY-MM-DD | |
| symbol | Yes | Stock symbol or OCC option contract (e.g. AAPL or AAPL250117C00150000). Use longer intervals for longer ranges. | |
| interval | No | Bar interval | daily |
| session_filter | No | Include extended-hours bars (all) or regular sessions only (open). Applies only to Tradier; Alpaca ignores this. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral details like output format (list of bars), data frequency, or potential adjustments. The parameter descriptions cover some behavior (interval, session_filter) but lack overall transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, and front-loaded with key action (historical bars). No wasted words, though could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Description omits what the output looks like (e.g., array of bars with OHLCV fields), which is critical for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional semantics beyond what schema provides; it repeats the concept of stock/option and time range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies it provides historical OHLCV bars for stock symbols or OCC option contracts over a time range, distinguishing it from sibling tools (e.g., get-quote for real-time quotes, find-options-chain for chains).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool. While context implies it's for historical data, it does not mention alternatives (e.g., for real-time quotes use get-quote).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: historical bars, expiration listing, latest quote with Greeks, and options chain query. No overlap in functionality.
Three tools follow verb_noun pattern (find-option-expirations, get-quote, find-options-chain), but historical-prices is a noun phrase without a verb, creating a minor inconsistency.
With 4 tools, the server covers essential options data operations (historical, expirations, quotes, chain) without being too sparse or bloated.
Core data retrieval is covered, but there is a minor gap: find-options-chain does not explicitly include Greeks for options in the chain, and there is no tool for retrieving option-specific Greeks across multiple contracts in a batch.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
Tradier MCP — stock & options market data via the Tradier Brokerage API
Live US options chains with Greeks and IV, a screener, SQL, and FMP fundamentals.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/blake365/options-chain'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
