Real-time news with bias scoring, live market data, and AI-powered options pricing
Get a page of news-source bias scores.
Returns sources active within the last 36 days with >100 articles analyzed, sorted by
avg_social_shares descending. The response also includes total, offset, limit, has_more,
and one shared bias_score_methodology block.
Each entry contains:
- source_name, slug_name, page_url
- articles_analyzed: total articles analyzed for this source
- avg_social_shares: average social shares per article (proxy for reach/influence)
- emotionality_score (0-10): average emotional intensity of the writing
- prescriptiveness_score (0-10): how much the source tells readers what to think/do
- bias_values: dict mapping classifier key → integer source weighted display score
(-50 to +50 for bipolar, 0 to +50 for unipolar). Keys use the same canonical
names as get_bias_from_url where a source aggregate is available, but article scores use
-10 to +10 or 0 to 10. Compare direction directly; normalize before comparing magnitude.
Political / ideological (bipolar: neg=left pole, pos=right pole):
'liberal conservative bias' neg=liberal, pos=conservative
'populist elitist bias' neg=populist, pos=elitist
'libertarian authoritarian bias' neg=libertarian, pos=authoritarian
'dovish hawkish bias' neg=dovish, pos=hawkish
'establishment bias' neg=anti-establishment, pos=pro-establishment
Credibility / quality (bipolar):
'overall credibility' neg=low credibility, pos=high credibility
'integrity bias' neg=low integrity, pos=high integrity
'article intelligence' neg=low intelligence, pos=high intelligence
'delusion bias' neg=truth-seeking, pos=delusional
'objective subjective bias' neg=objective, pos=subjective
'objective sensational bias' neg=objective, pos=sensational
'descriptive prescriptive bias' neg=descriptive, pos=prescriptive
'bearish bullish bias' neg=bearish, pos=bullish
'interesting' neg=boring, pos=interesting
'emotional bias' neg=negative tone, pos=positive tone
'rational irrational bias' neg=rational, pos=irrational
'corporate bias' neg=anti-corporate, pos=pro-corporate
'science superstition bias' neg=scientific, pos=superstitious
'individualist collectivist bias' neg=individualist, pos=collectivist
Unipolar bias dimensions (higher = more of that trait):
'opinion bias' opinion vs informative
'political bias' political content
'fearful bias' fear-based framing
'overconfidence bias' overconfidence
'gossip bias' gossip
'manipulation bias' manipulative framing
'ideological bias' ideological rigidity
'conspiracy bias' conspiracy content
'double standard bias' double standards
'virtue signal bias' virtue signaling
'oversimplification bias' oversimplification
'appeal to authority bias' appeal to authority
'begging the question bias' question-begging
'victimization bias' victimization framing
'terrorism bias' terrorism content
'marxism bias' Marxist framing
'islamist bias' Islamist framing
'anti-semitism bias' anti-Jewish framing
'anti-lgbt bias' anti-LGBT framing
'racism bias' racist framing
'anti-enlightenment bias' regressive, anti-liberal content
'scapegoat bias' scapegoating
'hypocrisy bias' hypocrisy
'suicidal empathy bias' suicidal-empathy framing
'cruelty bias' cruelty
'woke bias' woke framing
'written by AI' AI-written likelihood
'immature bias' immaturity
'circular reasoning bias' circular reasoning
'covering the response bias' covering-the-response tactic
'spam bias' spam-like content
'advertising bias' advertorial or promotional content
'speculation bias' speculation or forecasting
Tip: use get_source_bias for full narrative descriptions and recent articles on a specific source.
Tip: bias_values use shared canonical names where available. Source and article score scales
differ, so normalize magnitudes.
get_source_bias exposes the same canonical keys in bias_values and retains emoji-prefixed
bias_scores only for backward compatibility.
Args:
limit: Sources to return (1-1000, default 200).
offset: Number of sources to skip for pagination (default 0).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses sorting order, pagination fields, inclusion criteria, and detailed meaning of every output field, including scale differences between source and article scores. This is highly transparent.
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?
The description is long but well-organized with clear sections, bullet lists, and tips. The extensive list of bias dimensions is justified given the complex output, but its length prevents a perfect score.
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?
The description covers pagination, sorting, inclusion criteria, output field semantics, canonical key naming, scale normalization, and sibling tool distinctions. It leaves no significant gaps for correct invocation and interpretation.
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?
The Args section adds bounds for limit (1-1000) and explains offset as 'Number of sources to skip for pagination,' which goes beyond the schema's default values. This gives the agent crucial operational context.
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 'Get a page of news-source bias scores,' naming the specific resource and action. It also distinguishes itself from sibling tools by referencing get_source_bias and get_bias_from_url for different use cases.
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 explains the tool's scope (sources active within last 36 days with >100 articles) and includes an explicit tip to use get_source_bias for full narrative descriptions on a specific source. It doesn't enumerate all when-not-to-use scenarios, but the alternative is clearly pointed out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bias analysis for a specific article by its URL.
Use this when you have a direct link to an article and want to know its political leaning,
credibility, emotionality, and other bias dimensions — without needing to know the source name first.
On success (found=true), returns:
- article_id, classification_id, requested_url, matched_url, title, source, date, link, category
- teaser: article excerpt
- summary: one-sentence AI summary
- context: AI-generated context for the article
- implicit_assumptions: tacit or unstated premises the article's claims or framing rely on
(list of concise strings, when available)
- extracted_data: structured quantitative/qualitative facts extracted from the article
- raw_data: legacy serialized form of extracted_data
- bias_description: narrative description of this specific article's bias
- bias_values: dict of per-dimension article scores using canonical plain-text keys,
e.g. {"liberal conservative bias": 4, "overall credibility": 7, "emotional bias": -5, ...}
Article scores use -10 to +10 for bipolar dimensions and 0 to 10 for unipolar dimensions.
Positive values lean toward the second pole of each dimension (conservative, authoritarian, etc.).
- bias_analysis_status: 'evidence_ready', 'evidence_unverified', 'evidence_partial',
'scored_legacy', or 'pending'
- bias_dimensions when include_evidence=true: each dimension's score, scale, evidence status,
claim, verbatim evidence, counterevidence, confidence, and rationale. Quotes include
verification method and exact character offsets when raw-text matching succeeds.
Dimension evidence_status is one of: verified, provided_unchecked, quote_mismatch,
metadata_incomplete, metadata_only, or missing.
- bias_analysis: contract/schema/model/prompt provenance, generation and review status,
input scope/hash/size, analysis target, quote-verification method, explicit missingness
and evidence coverage, and case-specific limitations
- total_shares: total social shares
- wayback_link: Wayback Machine archive URL if available
- image: article image URL if available
On failure (found=false, HTTP 404):
- found: false
- message: explanation string
The URL is automatically queued for ingestion; retry after ~24 hours.
Tip: if you want source-level bias (not article-level), use get_source_bias instead.
Tip: bias_values keys here use plain-text format (e.g. 'liberal conservative bias') shared
with the other bias tools where that dimension is available.
Args:
url: Full article URL, e.g. 'https://www.nytimes.com/2024/01/01/us/politics/example.html'.
include_evidence: Include claim-level evidence and limitations. Defaults to true.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| include_evidence | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses success/failure response shapes, automatic ingestion on 404, retry expectations, evidence status values, score scales, and verification methods for quotes. This is far beyond minimal 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?
The description is lengthy but meticulously structured: main purpose first, then detailed return fields under success/failure, followed by practical tips and argument explanations. Every sentence adds necessary information for a complex tool with no wasted 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?
Given the tool's complexity, the description is complete: it enumerates all return categories, explains failure and retry, clarifies parameter semantics, and directs to sibling tools when appropriate. The presence of an output schema does not reduce the need for this description, and it exceeds that bar.
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?
Although the schema has no descriptions (0% coverage), the 'Args' section fully explains both parameters: 'url' with a concrete example and 'include_evidence' with its default and effect. The description compensates entirely for the schema's lack of detail.
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 uses a specific verb+resource ('Get bias analysis for a specific article by its URL') and clearly differentiates from the sibling tool get_source_bias. The scope is precise: article-level analysis for a direct link, without requiring prior source knowledge.
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?
Explicitly states when to use the tool ('when you have a direct link to an article and want to know its political leaning...') and provides an alternative ('if you want source-level bias, use get_source_bias instead'). It also explains failure handling and retry timing, giving clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full historical options chain for a ticker on a specific date.
Returns the complete options chain including all expirations and contracts,
with bid, ask, mid prices, greeks, and Helium's proprietary model values
(helium_theo, helium_pitm, should_i_buy, should_i_sell, terminal_buy_pl,
terminal_sell_pl, etc.) baked into each contract.
Returns:
- symbol, date, data_source ('recent' or 's3')
- num_expirations: number of distinct expiration dates
- total_contracts: total number of option contracts
- option_chain: dict keyed by expiration index, each value is a list of option contracts
Each contract includes fields like: putCall, symbol, description, bid, ask, mark,
mid_price, strikePrice, expirationDate, daysToExpiration, delta, gamma, theta, vega,
impliedVolatility, openInterest, volume, helium_theo, helium_pitm, should_i_buy,
should_i_sell, terminal_buy_pl, terminal_sell_pl, and more.
Args:
symbol: Ticker symbol, e.g. 'AAPL', 'TSLA', 'SPY'.
date: Date in YYYY-MM-DD format, e.g. '2026-04-10'.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses return structure, fields, and data_source values ('recent' or 's3'), but it does not explain what those data sources mean, nor does it mention potential large response sizes, error behavior, or rate limits.
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?
The description is long but well-structured with an opening summary, a 'Returns:' section, and an 'Args:' section. It is slightly verbose with the exhaustive field list, but most content adds value for a data-heavy 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?
The description gives a thorough picture of inputs, output structure, and included contract fields. It is mostly complete for invoking the tool and interpreting results, though the meaning of data_source and possible edge cases are left unexplained.
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?
The schema has 0% description coverage, but the description compensates well with concrete guidance: symbol examples ('AAPL', 'TSLA', 'SPY') and exact date format with an example ('2026-04-10'). This adds practical meaning beyond the bare schema field names.
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 opens with a clear, specific verb and resource: 'Get the full historical options chain for a ticker on a specific date.' It uniquely distinguishes this from siblings like get_option_price by emphasizing 'full historical options chain' and 'all expirations and 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?
Usage context is implied through phrases like 'full historical options chain' and the detailed returns, but the description never explicitly states when to use this tool versus alternatives like get_option_price. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| strike | Yes | ||
| symbol | Yes | ||
| expiration | Yes | ||
| option_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get comprehensive bias analysis for a news source.
Returns:
- source_name, slug_name, page_url
- source_match: original query and deterministic match method
- articles_analyzed: total articles in the bias database for this source
- last_updated: source-profile aggregation timestamp
- avg_social_shares: average social shares per article
- emotionality_score (0-10): how emotional the writing is
- prescriptiveness_score (0-10): how much the source tells readers what to think/do
- bias_values: canonical plain-text source-level weighted display scores (-50 to +50 bipolar,
0 to +50 unipolar). Keys match the article tools; these are directional source summaries,
not raw article-score averages.
- bias_scores: legacy emoji-prefixed display scores
- bias_score_methodology: scope and evidence caveats for aggregate scores
- bias_description: clean-text, AI-generated overall bias summary narrative
- bias_description_metadata: generation time, automated review status, and evidence scope
- bias_description_html: optional website HTML when include_html=true
- liberal_conservative_description: narrative on political leaning
- libertarian_authoritarian_description: narrative on authority stance
- signature_phrases: words/phrases uniquely overrepresented vs other sources
- signature_negative_phrases: uniquely negative/alarming phrases
- most_shared_phrases: phrases in their most viral articles
- most_emotional_phrases: phrases used in their most emotional articles
- pays_for_traffic_keywords: keywords this source buys ads for
- similar_sources: sources with the most similar bias profile
- most_different_sources: sources with the most different bias profile
- trends_graph_url: URL to a chart of this source's coverage volume over time
- bias_plot_urls: dict of 2D bias scatter plot image URLs (political_lib_auth, subjective_objective, informative_opinion, oversimplification_factful) — only present when available
- recent_articles: list of most recent articles with full article fields, bias_values,
analysis status, and optional self-contained bias_dimensions and bias_analysis.
Evidence quotes include verification method and exact character offsets when available.
- recent_evidence_coverage: reconciled counts for verified, unverified, partial,
legacy-scored, and pending articles, plus evidence-bearing count and verified ratio
Throws an error if the source is not found.
Args:
source: Source name, slug, or domain (e.g. 'Fox', 'reuters', 'bbc.co.uk').
Partial names are accepted only when they identify one source; ambiguous input returns candidates.
recent_articles: Number of recent articles to include (1-50, default 10).
include_evidence: Include per-article claims, verbatim evidence, counterevidence,
confidence, rationale, and limitations. Defaults to false to keep
multi-article source payloads compact.
include_html: Also return the original website-formatted source narrative. Defaults to false.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| include_html | No | ||
| recent_articles | No | ||
| include_evidence | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure responsibility. It explicitly states error behavior, partial match rules, ambiguity responses, and parameter defaults. It gives a thorough account of what the tool does and what can be expected.
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?
The description is front-loaded with a clear summary, followed by organized bullets and an Args section. It is lengthy but justified by the rich return payload. Some repetition (e.g., bias_values vs bias_scores) could be trimmed, but overall structure is effective.
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 the complexity of this tool, the description leaves little uncovered: input resolution, error handling, defaults, and every returned field is explained. The existence of an output schema is noted, but the description provides extensive context on its own.
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?
The Args section thoroughly explains each parameter beyond the bare schema: source accepts name/slug/domain with partial-match caveats, recent_articles has a range, include_evidence lists exactly what is included, and include_html clarifies the additional output. This more than compensates for 0% schema description coverage.
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 'Get comprehensive bias analysis for a news source' with a specific verb and resource. It distinguishes from siblings by focusing on a single source's bias profile, and the extensive field list makes the scope unambiguous.
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?
It clearly implies when to use this tool: whenever you have a source name, slug, or domain. It also explains partial name handling and ambiguity resolution. However, it does not explicitly contrast with alternatives like 'get_bias_from_url' for URL input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive data for a stock, ETF, or crypto ticker.
Returns:
- ticker, name, type (e.g. 'stock', 'etf', 'crypto'), industry
- latest_price, page_url
- bullish_case, bearish_case, potential_outcomes, takeaway, analysis_date (AI-generated)
- price_forecast_days, price_forecast_percent, price_forecast_lower/upper_bound_percent (model price forecast)
- future_uncertainty_urls: dict with raw underlying Plotly data (extracted from each stored
Plotly graph) for future_uncertainty (keyed by days-ahead), term_structure,
volatility_surface, and return_profile — the data behind the interactive graphs the site
now renders instead of the old static images (when available)
- future_uncertainty_last_updated, term_structure_last_updated
- iv_rank_percentile (0-100, IV rank over past year)
- long_vol_call, long_vol_put, short_vol_call, short_vol_put: full option pack dicts (when available)
Throws an error if the ticker is not recognized.
Args:
ticker: Ticker symbol, e.g. 'AAPL', 'AMZN', 'BTC', 'ETH', 'SPY'.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It is honest about error behavior ('Throws an error if the ticker is not recognized') and caveats fields 'when available' — good. However, it does not disclose data freshness sources beyond timestamps, potential staleness of AI-generated analysis, which fields may be null, or any rate-limit/authorization requirements. For a comprehensive read tool, more behavioral context would help.
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?
Organized with a clear bulleted return inventory followed by an Args section — good structure and front-loading of purpose. It's thorough but not bloated; every section adds information. The return list is long but necessary given the tool's comprehensive nature. Slightly verbose given the amount of returned-field detail, but this is justified for a broad fetch 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?
An output schema exists, so the description doesn't need to explain return types in depth, but it does a stellar job enumerating semantic meaning of each output field (AI-generated, keyed by days-ahead, IV rank over past year). For a single-param tool with an output schema, this is thorough. Could be marginally improved by stating data freshness caveats for AI-generated fields, but overall it's substantially complete for effective use.
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 0% and there's a single required parameter 'ticker' with no type description in the schema. The description compensates well by giving concrete examples ('AAPL', 'AMZN', 'BTC', 'ETH', 'SPY') and correctly stating it accepts stocks, ETFs, and crypto — meaningfully expanding what the bare schema provides. Though it doesn't mention case sensitivity or format normalization, the examples are sufficient for a single simple parameter.
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 is exceptionally clear: 'Get comprehensive data for a stock, ETF, or crypto ticker.' It uses a specific verb+resource and enumerates the full data payload across multiple categories (price, AI analysis, forecast, options, IV). It distinguishes well from sibling tools like get_historical_options_data, get_option_price, and search_news by its broad, all-inclusive scope.
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 clearly states what it returns and that it throws an error for unrecognized tickers, giving the agent good context for expected behavior. However, it does not explicitly contrast against siblings like get_bias_from_url or search_news, nor does it state when to prefer this over more specialized lookups. The primary use case is implied (fetch everything for a ticker) but no when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top-ranked short volatility and long volatility option trading strategies.
Returns two ranked lists — short_volatility (sell premium / theta strategies) and
long_volatility (buy premium / gamma strategies) — each containing up to `limit` tickers.
Each entry has the same fields as get_ticker:
- ticker, name, latest_price, page_url
- bullish_case, bearish_case, potential_outcomes, takeaway, analysis_date (AI-generated, when available)
- price_forecast_days, price_forecast_percent, price_forecast_lower/upper_bound_percent (when available)
- iv_rank_percentile (0-100, IV rank over past year, when available)
- short_vol_call, short_vol_put: best short volatility option packs (when available)
- long_vol_call, long_vol_put: best long volatility option packs (when available)
Sort options:
- "helium_rank" (default): Helium AI edge score — best overall expected value
- "odds_of_profit": Highest probability of profit
- "historical_performance": Best annualized historical P&L across backtested trades
- "reward_to_risk": Best reward-to-risk ratio
- "smallest_max_loss": Strategies with the smallest maximum possible loss
Args:
sort: Ranking method (default "helium_rank"). One of: 'helium_rank', 'odds_of_profit',
'historical_performance', 'reward_to_risk', 'smallest_max_loss'.
limit: Number of results per strategy type (1-20, default 5).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | helium_rank | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format, fields, sort options, and caveats like 'when available' and AI-generated content. It does not explicitly state there are no side effects, rate limits, or error behaviors, but for a get-style tool the disclosure is substantial.
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?
The description is front-loaded with the core purpose, then uses clear bullet-like sections for return fields and sort options. Despite its length, every section serves a purpose and the structure makes it easy to scan.
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 the tool's complexity—two ranked lists, five sort methods, and many output fields—the description covers the necessary detail for correct invocation. Defaults, limits, sort semantics, and field categories are all explained, making the tool self-contained for an agent.
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 0%, but the description fully compensates: it explains both `sort` (each enum value with meaning) and `limit` (range 1-20, default 5) in detail. This goes far beyond the bare schema.
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 opens with a specific verb and resource: 'Get the top-ranked short volatility and long volatility option trading strategies.' It clearly differentiates from sibling tools by focusing on ranked strategies rather than individual tickers or news, and further details the two output lists and sort options.
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 clearly implies when to use this tool—when you need top-ranked long/short volatility strategies—and provides rich context about sorting and output. It does not explicitly compare alternatives or state when not to use it, but the purpose is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Helium's balanced news stories — AI-synthesized articles that aggregate multiple sources.
Unlike search_news (which returns individual RSS articles), this returns Helium's own
synthesized stories: each one draws from multiple sources and includes an AI-written
summary, takeaway, context, evidence breakdown, potential outcomes, and relevant tickers.
Returns a list of stories, each with:
- title, simple_title, date, category
- page_url: full URL to the story on heliumtrades.com
- image: story image URL (when available)
- summary: Helium's synthesized overview
- takeaway: key conclusion
- context: background context
- evidence: numbered evidence items
- potential_outcomes: forward-looking outcomes with probabilities
- relevant_tickers: related stock tickers
- num_sources: number of source articles synthesized
- rank: search relevance score
Args:
query: Search keywords (required).
limit: Max results (1-50, default 10).
category: Filter by category. One of: 'tech', 'politics', 'markets', 'business', 'science'.
days_back: Only include stories from the last N days. 0 means no date filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No | ||
| days_back | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavior. It thoroughly describes the tool's output structure, including a list of all returned fields (title, page_url, summary, evidence, etc.) and notes nuances like 'image: story image URL (when available)' and 'rank: search relevance score'. It does not explicitly state whether the operation is read-only or mention rate limits, but the search nature is inherently non-destructive and the detailed return format gives strong 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?
The description is efficiently structured: it opens with a clear one-sentence definition, immediately differentiates from the sibling tool, then uses bullet points to enumerate the return fields and a compact 'Args:' list for parameters. Every sentence adds value without redundancy, and the front-loaded contrast with search_news ensures the most important information appears early.
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?
The tool has 4 parameters and an output schema, but the description goes beyond the schema by explaining the return objects in detail, including the exact list of story fields. It also gives parameter constraints and examples of category values. Given the tool's moderate complexity, the description is sufficiently complete—it covers what the tool does, how to use it, and what to expect in the response.
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?
The input schema provides only property titles with no descriptions, resulting in 0% schema description coverage. However, the tool description includes an 'Args:' section that fully specifies each parameter: query is required, limit has a range and default (1-50, default 10), category lists all allowed values ('tech', 'politics', 'markets', 'business', 'science'), and days_back explains the meaning of 0. This completely compensates for the missing schema descriptions.
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 that the tool searches Helium's balanced news stories, which are AI-synthesized articles aggregating multiple sources. It uses a specific verb ('Search') and resource ('Helium's balanced news stories'), and explicitly distinguishes it from the sibling tool search_news by contrasting the return types (synthesized stories vs. individual RSS articles). This provides unambiguous purpose and differentiation.
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 explicitly contrasts this tool with search_news: 'Unlike search_news (which returns individual RSS articles), this returns Helium's own synthesized stories...'. This clear alternative guidance tells the agent when to use this tool versus its sibling. It also describes the filtering options (category, days_back) that help tailor the query, giving further context on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Helium's meme database by text (OCR + caption).
Returns matching memes ranked by relevance. Each result includes:
- id, caption, ocr (text extracted from the image)
- image: full URL to the meme image
- source: origin platform (e.g. 'reddit')
- num_likes: likes/upvotes on the original post
- date, is_video, rank
Args:
query: Search keywords (required). Matched against OCR text and captions.
limit: Max results (1-100, default 20).
days_back: Only include memes from the last N days. 0 means no date filter (default).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| days_back | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it provides return field details and mentions ranking by relevance. It does not disclose potential issues like rate limits, authentication, or behavior on no results, but the search context implies no side effects.
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?
The description is well-structured: a concise purpose statement, a list of return fields, and an Args block. Every sentence adds value, and it is front-loaded with the main use case.
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?
The description covers purpose, parameters, and return format. Despite no annotations, it is self-sufficient for a search tool, and the output schema exists to provide additional structure. It lacks only edge-case info, which is not critical for this simple search.
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?
The description provides detailed explanations for all parameters in an Args section, going beyond the bare schema. It clarifies query matching, limit bounds, and the meaning of days_back=0, which is essential since schema description coverage is 0%.
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 tool's function: searching Helium's meme database by text using OCR and captions. It distinguishes itself from sibling tools (news, bias, options) by specifying the meme database and the fields returned.
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 provides clear context on when to use the tool (to search memes by text) and implies a read-only search operation. It does not explicitly mention alternative tools or exclusions, but the domain difference from siblings makes usage apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search news articles.
Returns a list of matching articles. Each article includes:
- article_id, classification_id, title, source, date, link, category, rank, total_shares, summary
- bias_values: dict of per-dimension bias scores using plain-text keys (e.g. 'liberal conservative bias'),
same schema as get_bias_from_url and get_all_source_biases (when available)
- bias_analysis_status: 'evidence_ready', 'evidence_unverified', 'evidence_partial',
'scored_legacy', or 'pending'
- evidence_ratio: fraction of scored bias dimensions whose supporting quote is verified
(0.0-1.0). Raise min_evidence to demand only articles with verified quotes.
- bias_dimensions when include_evidence=true: a self-contained object joining each score,
scale, evidence status, claim, evidence, counterevidence, confidence, and rationale.
Quotes include verification method and exact character offsets when raw-text matching succeeds.
Dimension evidence_status is one of: verified, provided_unchecked, quote_mismatch,
metadata_incomplete, metadata_only, or missing.
- bias_analysis: contract/schema/model/prompt provenance, generation and review status,
input scope/hash/size, limitations, quote-verification method, and explicit evidence coverage
- context: AI-generated contextual background for the article (when available)
- implicit_assumptions: tacit or unstated premises the article's claims or framing rely on
(list of concise strings, when available)
- extracted_data: structured quantitative/qualitative facts extracted from the article
- raw_data: legacy serialized form of extracted_data
Args:
query: Optional search keywords. Leave empty to return the most recent articles in
scope (use with bias to rank them). e.g. 'NVDA earnings'.
limit: Max results (1-100, default 20).
source: Filter by source name, e.g. 'CNN', 'Reuters'.
category: Filter by category. One of: 'trending', 'tech', 'markets', 'politics',
'business', 'science', 'memes'.
days_back: Only include articles from the last N days. 0 means no date filter. Default: 720 (2 years).
min_shares: Minimum total social shares.
sort: Sort order. One of: 'rank' (relevance, default), 'date' (newest), 'shares' (most shared).
bias: Optional bias dimension to sort by. Returns the most recent articles ranked highest on that
bias, highest score first. Any canonical bias key, e.g. 'liberal conservative bias',
'overall credibility', 'conspiracy bias'. Works with an empty query for a standalone
'most biased recent articles' listing. Use with only_analyzed if you want.
include_evidence: Include claim-level evidence, counterevidence, confidence, rationale, and limitations.
Defaults to false to keep search payloads compact.
only_analyzed: Return only articles with valid canonical bias scores.
min_evidence: Minimum fraction of scored dimensions with verified quotes (0.0-1.0, default 0).
Raise this to request only articles whose scores are backed by verified evidence,
e.g. 0.5. Returns a 400 if sort or bias is not a valid option.
| Name | Required | Description | Default |
|---|---|---|---|
| bias | No | ||
| sort | No | rank | |
| limit | No | ||
| query | No | ||
| source | No | ||
| category | No | ||
| days_back | No | ||
| min_shares | No | ||
| min_evidence | No | ||
| only_analyzed | No | ||
| include_evidence | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses output fields, status enums, default behavior (days_back=720, limit=20), error behavior on invalid sort/bias, the legacy raw_data field, and the rationale for include_evidence defaults. No annotation contradiction exists.
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?
The description is long but well-structured: a brief purpose sentence, a bulleted output contract, and then an Args list. Given 11 parameters and deeply nested output fields, each sentence earns its place without redundant filler.
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?
The definition covers parameters, return fields, defaults, error cases, and usage strategies, so an agent has enough information to call the tool correctly. The only minor gap is cross-tool selection guidance relative to sibling search tools, but that is not essential given the exhaustive parameter and output documentation.
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 0%, so the description is the only source of parameter meaning. It explains every parameter with defaults, allowed values, examples like 'NVDA earnings', and nuanced caveats such as min_evidence returning a 400 for invalid sort or bias options.
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 opens with a specific verb+resource pair, 'Search news articles', and enumerates the returned article metadata, making the tool's core function unmistakable. However, it does not explicitly differentiate itself from the sibling tool search_balanced_news, so it falls short of a 5.
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 Args section provides clear operational guidance: empty query returns recent articles, bias sorts by a bias dimension, min_evidence filters for verified quotes, and include_evidence is kept off to preserve payload compactness. It lacks explicit exclusions or alternative-tool routing, such as when to prefer search_balanced_news or search_memes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
search_news1 field changedInput schema / properties / min_evidenceAdded value: +{
+ "default": 0,
+ "title": "Min Evidence",
+ "type": "number"
+}search_news3 fields changedInput schema / properties / biasAdded value: +{
+ "default": "",
+ "title": "Bias",
+ "type": "string"
+}Input schema / properties / query / defaultAdded value: +""Input schema / requiredRemoved value: -[
- "query"
-]get_all_source_biases2 fields changedInput schema / properties / limitAdded value: +{
+ "default": 200,
+ "title": "Limit",
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "title": "Offset",
+ "type": "integer"
+}get_bias_from_url1 field changedInput schema / properties / include_evidenceAdded value: +{
+ "default": true,
+ "title": "Include Evidence",
+ "type": "boolean"
+}get_source_bias2 fields changedInput schema / properties / include_evidenceAdded value: +{
+ "default": false,
+ "title": "Include Evidence",
+ "type": "boolean"
+}Input schema / properties / include_htmlAdded value: +{
+ "default": false,
+ "title": "Include Html",
+ "type": "boolean"
+}search_news2 fields changedInput schema / properties / include_evidenceAdded value: +{
+ "default": false,
+ "title": "Include Evidence",
+ "type": "boolean"
+}Input schema / properties / only_analyzedAdded value: +{
+ "default": false,
+ "title": "Only Analyzed",
+ "type": "boolean"
+}search_memes1 field changedInput schema / properties / days_backAdded value: +{
+ "default": 0,
+ "title": "Days Back",
+ "type": "integer"
+}get_historical_options_dataget_all_source_biasesget_bias_from_urlget_option_priceget_source_biasget_tickerget_top_trading_strategiessearch_balanced_newssearch_memessearch_newsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Live US options chains with Greeks and IV, a screener, SQL, and FMP fundamentals.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
