Skip to main content
Glama

Helium MCP Server - News, Markets & AI

by io.github.connerlambden

get_option_price

Get Helium's proprietary ML model-predicted price for a specific option contract.

Helium trains per-symbol regression models on historical options data. This tool
looks up the most recent available options chain for the symbol (today or up to
5 days back), finds the exact contract matching strike/expiration/type, and runs
it through that model to produce a predicted fair-value price.

Returns:
- symbol: the ticker
- strike: the strike price used
- expiration: the expiration date used
- option_type: 'call' or 'put'
- predicted_price: Helium's model-predicted option price in dollars
- prob_itm: probability of expiring in the money (0.0–1.0), or null if model unavailable
- options_data_date: the date of the options chain snapshot the model was run on
  (so you know how fresh the underlying market data is)

Throws an error if no options chain data is available for the symbol within the past 5 days,
or if the exact contract (strike/expiration/type combination) does not exist in that chain.

Args:
    symbol: Ticker symbol, e.g. 'AAPL', 'SPY'.
    strike: Strike price as a number, e.g. 150.0.
    expiration: Expiration date as 'YYYY-MM-DD', e.g. '2026-06-20'.
    option_type: Must be 'call' or 'put'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
strikeYes
symbolYes
expirationYes
option_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that the tool uses the most recent options chain (today or up to 5 days back), searches for an exact contract match, runs the model, and returns predicted_price and prob_itm. It also explicitly states error conditions (missing chain or contract) and how staleness is communicated via options_data_date.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized, starting with a one-sentence purpose, followed by process, return fields, error conditions, and argument specifications. Each section earns its place and is free of filler. Despite being detailed, it is structured with headers and bullet-like clarity, making it easy for an agent to parse.

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?

Given the tool's complexity—four required parameters, an output schema, and no annotations—the description is exceptionally complete. It covers return values (even listing probability of ITM and its null behavior), freshness of data, and failure modes. The presence of an output schema does not reduce the need for this context because the description explains meaning and caveats beyond field names.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides zero description coverage, but the description's Args section gives clear semantics for all four parameters: symbol examples, strike as a number, expiration with format 'YYYY-MM-DD', and option_type restricted to 'call' or 'put'. This adds essential meaning beyond the bare schema. The description also clarifies the model's behavior for each parameter.

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 clearly states that this tool 'Get Helium's proprietary ML model-predicted price for a specific option contract.' It uses a specific verb ('Get'), a specific resource ('ML model-predicted price'), and the scope is precise. This distinguishes it from sibling tools like get_historical_options_data, which focuses on historical data.

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?

The description implies usage for obtaining a model-predicted fair-value price and explains the underlying mechanism (recent chain, model). However, it does not explicitly mention when not to use this tool or compare it to alternatives like get_historical_options_data or get_ticker. Usage context is clear but without explicit exclusions.

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

All Helium MCP Server - News, Markets & AI toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but two pairs could cause confusion: get_all_source_biases vs. get_source_bias, and search_news vs. search_balanced_news. The descriptions explicitly differentiate them (list vs. single source; RSS vs. synthesized stories), so an agent can disambiguate with careful reading.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_* for retrievals and search_* for searches. Any variations (e.g., get_all_source_biases vs. get_source_bias) are natural qualifiers and don't break the pattern.

Tool Count5/5

With 10 tools spanning news bias analysis, options data, ticker data, and trading strategies, the count is well-scoped. Each tool has a distinct role and the set is neither too thin nor overloaded.

Completeness4/5

The surface covers the core workflows: searching news, analyzing bias at both article and source level, retrieving market data, options chains, and strategy rankings. Minor gaps exist, such as no direct way to fetch a full article by ID or list all news sources, but these are workarounds with existing tools.

Resources