Real-time news with bias scoring, live market data, and AI-powered options pricing
Scored across 10 tools
Most tools target clearly distinct resources: articles, source bias, URL bias, options chains, option prices, tickers, strategies, and memes. A couple of pairs could be confused at a glance—search_news vs search_balanced_news and get_source_bias vs get_all_source_biases—but the descriptions draw explicit boundaries.
All tools follow a consistent get_ or search_ prefix with descriptive nouns, e.g. get_ticker, get_source_bias, search_news, search_memes. The naming pattern is predictable and there is no style mixing.
Ten tools is well within the ideal 3–15 range, and each tool covers a distinct part of the news, bias, and markets surface. The meme search is slightly peripheral to the server's main purpose but does not make the set feel bloated.
The core workflows—searching news, analyzing article/source bias, fetching ticker data, options chains, option prices, and trading strategies—are well covered. Minor gaps exist, such as no direct article-by-ID lookup or ticker-scoped news aggregation, but search tools can work around these.
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
'optimistic pessimistic bias' neg=pessimistic, pos=optimistic
'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
'fraud bias' fraud-promoting framing
'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
'big pharma bias' reflexive trust in medical/pharma authority
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?
Beyond the readOnlyHint and destructiveHint annotations, the description richly discloses behavior: it filters sources by activity and article count, sorts by avg_social_shares descending, returns pagination metadata (total, offset, limit, has_more), includes a shared bias_score_methodology block, and explains score scale differences requiring normalization. It also details bias key polarity semantics and backward compatibility. No contradictions with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but most content is justified because the bias key taxonomy and score scales are essential for correct interpretation. It is front-loaded with the core behavior, followed by structured lists. There is minor redundancy—the advice to normalize magnitudes and use canonical names appears more than once—so a point is lost, but overall it earns its length.
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?
For a read-only paginated list tool with an output schema, the description is complete: it covers filtering, sorting, pagination, entry fields, score ranges, polarity mappings, and cross-tool key compatibility. Nothing an agent needs to decide whether to call or correctly parse the response is missing.
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%, so the description carries the full burden. It explains limit as 'Sources to return (1-1000, default 200)' and offset as 'Number of sources to skip for pagination (default 0)', adding range, purpose, and behavioral meaning not present in the input schema. Both parameters are fully clarified.
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 opening line states a specific action and resource: 'Get a page of news-source bias scores.' It further differentiates itself by listing the inclusion criteria (active within 36 days, >100 articles) and sort order, and later explicitly contrasts with get_source_bias for source-specific narratives. This clearly distinguishes it from siblings like get_source_bias and get_bias_from_url.
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 gives concrete guidance: use get_source_bias when full narrative descriptions or recent articles on a specific source are needed, and references get_bias_from_url for canonical key names. It stops short of explicitly saying 'use this tool only when you need many sources' or providing a when-not-to-use rule for all siblings, so it is clear but not exhaustive.
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',
'evidence_failed' (all scored dimensions' quotes failed verification, so the scores do
not match the article text), '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?
The description is otherwise rich—it documents failure modes, evidence statuses, scales, and the 404 'queued for ingestion' side effect. However, that side effect contradicts the annotation readOnlyHint=true: a read-only tool should not enqueue ingestion or modify server state. Per the rubric, this is an annotation contradiction.
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 purpose and usage guidance are front-loaded, and the text is organized with clear headers for success/failure/tips/args. It is somewhat long and duplicates return-value detail that an output schema would already cover, but each section earns its place for a complex 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?
For a tool with two parameters and many failure/evidence modes, the description covers the important operational facts: found=true/false shapes, evidence status enums, score scales, 24-hour retry expectation, and the sibling alternative. Nothing essential appears missing.
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 carries full responsibility for both parameters. The Args section gives a full-URL example for url and explains what include_evidence toggles (claim-level evidence and limitations) plus its default value.
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 and resource: 'Get bias analysis for a specific article by its URL' and names the dimensions (political leaning, credibility, emotionality). It also distinguishes itself from the sibling get_source_bias by explicitly saying this is article-level rather than source-level.
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 states the precise condition for use ('when you have a direct link to an article') and what it lets the agent avoid ('without needing to know the source name first'). The tip 'if you want source-level bias, use get_source_bias instead' gives an explicit alternative and when-not-to-use.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by disclosing the data_source values ('recent' or 's3') and the proprietary model fields baked into each contract, which goes beyond the annotation-only safety profile.
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 and then organized into Returns and Args sections. It is somewhat verbose, enumerating many contract fields, but that detail is organized and useful; no sentence is wasted, though it could be tightened by referencing the output schema.
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?
For a two-parameter read-only tool, the description covers the purpose, parameters, return shape, and key contract fields. It even goes beyond what's needed given an output schema exists, ensuring an agent has a full picture of what to expect.
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 compensates fully by explaining both parameters with examples and format requirements: symbol as a ticker like 'AAPL' and date as 'YYYY-MM-DD'. This gives the agent everything needed to fill the parameters correctly.
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 'Get the full historical options chain for a ticker on a specific date,' which is a specific verb+resource. It doesn't explicitly reference sibling tools like get_option_price, so it lacks explicit sibling differentiation, but the resource is distinct enough.
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 the tool is for retrieving a complete historical options chain, but it doesn't provide explicit guidance on when to use it versus alternatives (e.g., get_option_price for a single contract price). No exclusions are stated, so usage is only implied.
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?
The description goes well beyond the readOnly and destructive annotations. It discloses that data may be up to 5 days stale, that prob_itm can be null when the model is unavailable, and specifies exact error conditions when chain data or the contract is missing. This gives the agent a clear behavioral model of the 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?
The description is well-organized into purpose, process, returns, errors, and args. The first sentence front-loads the core action, and every section 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 description covers return fields, data freshness, error behavior, and parameter formats. Even though an output schema is said to exist, the description's Returns list and error details give an agent everything needed to invoke the tool and interpret results 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 0%, so the description carries the full burden. The Args section fully compensates by documenting every parameter with a type, a concrete example, and format constraints (e.g., 'YYYY-MM-DD', numeric strike, option_type must be 'call' or 'put').
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?
First sentence names a specific verb and resource: 'Get Helium's proprietary ML model-predicted price for a specific option contract.' The process description—looks up the options chain, matches the exact contract, runs it through the model—makes the tool's function unmistakable and clearly distinguishes it from historical-data siblings like get_historical_options_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?
No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternatives are named. The intended use is implied by the purpose statement, but an agent is not explicitly told to prefer this tool over get_historical_options_data or to avoid it when raw market prices are needed.
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').
Compact names ('NBC News' -> 'NBC') resolve too. Ambiguous input returns candidate sources.
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?
The annotations declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds substantial behavioral detail: deterministic match method, error on missing source, candidate-source returns on ambiguity, optional include_evidence payload tradeoffs, legacy score labeling, and methodology caveats.
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 a one-line purpose, a detailed return-field list, and a separate Args section. The length is justified by the tool's complex, multi-field response, and the most decision-relevant information is front-loaded.
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 four parameters, rich response structure, and existing output schema, the description is very complete. It covers return fields, parameter semantics, error behavior, ambiguity handling, and performance-related payload caveats, leaving no critical invocation detail missing.
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 carries the entire semantic burden for parameters. The Args section fully explains source identifier formats, resolution and ambiguity behavior, recent_articles range and default, plus the meaning and purpose of include_evidence and include_html.
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 comprehensive bias analysis for a news source.' It further clarifies the accepted identifier types (name, slug, or domain), which distinguishes it from sibling tools like get_bias_from_url and get_all_source_biases.
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 intended use case is implied by the tool name and description, but there is no explicit guidance about when to choose this tool over alternatives such as get_bias_from_url or get_all_source_biases. The source identifier semantics and error behavior are useful context, but they do not provide when/when-not selection guidance.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: it throws an error on unrecognized tickers, notes when fields are 'when available' (e.g., future_uncertainty_urls, option packs), and explains the structure of future_uncertainty_urls. This goes beyond the annotations and gives the agent a clear expectation of failure modes and optionality.
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 deliberately structured with bullet points and an Args section, front-loading the core purpose and return summary. Each line adds value—listing fields, explaining the Plotly data source, and noting optional availability. It is not tautological; every sentence earns its place, though it could be tightened without losing content.
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?
For a read-only tool with a single parameter, the description is exceptionally complete. It covers the return payload in detail, error behavior, parameter format, and even clarifies that some fields are conditional. The output schema exists but is not described, so the description fills the gap entirely. An agent can call this tool correctly without any additional context.
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 must compensate. It does so with an explicit 'Args' section that defines the ticker parameter with format and concrete examples ('AAPL', 'AMZN', 'BTC', 'ETH', 'SPY'). This is exactly the kind of semantic guidance the schema lacks, and it fully covers the single 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 states a specific verb ('Get') and resource ('comprehensive data for a stock, ETF, or crypto ticker'), and it enumerates the distinct data categories returned, making it clear this is the go-to for ticker information. It clearly distinguishes from siblings like get_historical_options_data or search_news, which cover different domains.
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 by saying 'Get comprehensive data' and lists the data categories, but it does not explicitly state when not to use it or mention alternatives. However, the sibling tools are clearly different (news, biases, options), so an agent would infer this is the primary ticker data tool. The lack of explicit exclusions keeps it from a 5.
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?
The readOnlyHint and destructiveHint annotations already establish that this is a safe read operation. The description adds substantial behavioral context beyond annotations: it returns two distinct lists, each ticker entry includes AI-generated fields when available, and it documents optional data like IV rank and option packs. It also specifies default and allowed argument ranges, giving the agent a full picture of what to expect. No contradictions with annotations exist.
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 every section earns its place: the one-sentence summary, the return structure with field details, the sort options table, and the Args block. It is well-organized with clear labels and front-loads the core behavior before diving into details. Nothing is redundant or 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?
For a tool with zero required parameters, a descriptive output schema signal, and no sibling ambiguity, this description is comprehensive. It explains the full output shape, every parameter, valid values, defaults, and the meaning of ranking options. An agent has everything needed to invoke the tool correctly and interpret the result without opening external schema definitions.
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 parameter names, types, and defaults with no textual descriptions, so the description carries the full burden. It thoroughly explains both parameters: sort lists all five allowed values with the default and meaning, and limit specifies the range (1-20) and default (5). This is rich semantic value that goes well 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 defines what the tool returns (two ranked lists) and distinguishes this from siblings like get_ticker, which provides individual ticker data, and get_historical_options_data, which retrieves historical option prices. The purpose is unambiguous and well-scoped.
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 what the tool does and how it can be configured via sort and limit. It names the default ranking method and all possible sort options. However, it does not explicitly state when to use this tool instead of a sibling alternative, only implicitly differentiating itself by its ranked-list output and reference to get_ticker fields. This is clear context but lacks explicit exclusion criteria.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context: it explains the output is AI-synthesized from multiple sources, lists the exact return fields, and describes the nature of the content (summary, takeaway, evidence, etc.). This goes well beyond annotations and gives the agent a precise mental model of the tool's behavior.
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 one-line purpose, a clear sibling contrast, a list of return fields, and a parameter list. Every sentence adds value and there is no redundancy. It is front-loaded with the purpose and differentiation before diving into details.
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 is a search operation with an output schema, and the description covers all required context: purpose, distinction from sibling, return shape, and parameter semantics. It also mentions the date filter and category options. Nothing an agent needs to call this correctly is missing.
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 must compensate. It does so fully: it explains each parameter's meaning and constraints (query required, limit range 1-50 default 10, category enum values listed, days_back semantics with 0 meaning no filter). This is exactly what the agent needs to construct valid arguments.
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 searches Helium's balanced news stories, explicitly distinguishing it from search_news which returns individual RSS articles. It names the specific resource and the unique value proposition (AI-synthesized stories from multiple sources).
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 with search_news ('Unlike search_news...'), telling the agent when to use this tool instead of the sibling. This is direct, unambiguous usage guidance that selects between alternatives.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral context: it ranks results by relevance, lists the exact return fields (id, caption, ocr, image, source, num_likes, date, is_video, rank), and explains the matching source. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a compact bulleted list of return fields, and a clear parameter breakdown. It is front-loaded with the core purpose and every sentence earns its place without redundancy.
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 fully covers the tool's purpose, parameters, and return format. It even includes field names that align with an output schema, making it self-sufficient for an agent to call correctly. The only minor omission is pagination details, but these are not critical for a search tool with a limit parameter.
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 carries the full burden. It thoroughly explains each parameter: query is required and matched against OCR/captions, limit has a range (1-100) and default (20), and days_back semantics (0 = no date filter) are clarified. This adds meaning 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 'Search Helium's meme database by text (OCR + caption)', a specific verb-resource-scope statement that clearly differentiates it from sibling tools (which are news, bias, and options focused). It also enumerates the result fields, leaving no ambiguity about what the tool does.
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 search semantics ('Matched against OCR text and captions') and details each parameter, making the intended usage clear. It doesn't explicitly state when NOT to use it or name an alternative, but the sibling set is so different that no exclusion is necessary.
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',
'evidence_failed' (all scored dimensions' quotes failed verification, so the scores do
not match the article text), '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: 90. Widen this (e.g. 720) for older coverage.
min_shares: Minimum total social shares.
sort: Sort order. One of: 'rank' (relevance, default), 'date' (newest), 'shares' (most shared).
bias: Bias dimension to rank by, highest score first. This is a ranking, not a
standalone filter: an empty query still returns other recent articles, ranked
with the bias dimension on top. Any canonical bias key, e.g.
'liberal conservative bias', 'overall credibility', 'conspiracy bias'.
Ranking is scoped to recent articles (the days_back window, or 365 days when
days_back is 0) so one old high-scoring outlier cannot dominate.
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. Pair it with only_analyzed to get quotable results instead of
pending records with empty bias_values. 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?
Annotations already mark the tool readOnly and non-destructive, so the bar is lower. The description goes well beyond this by enumerating bias analysis statuses, evidence_ratio semantics, quote verification behavior, ranking scope, and the explicit 'Returns a 400 if sort or bias is not a valid option.' No contradiction with annotations 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 one-line purpose, a scannable response-field list, and a per-argument section. Some output-field prose may overlap with the existing output schema, but the structure is clear and front-loaded enough to remain usable.
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?
For a complex 11-parameter, read-only search tool with rich provenance/evidence output, the description is complete: every parameter is explained, defaults are given, edge cases and ranking behavior are clarified, and error behavior is disclosed. An agent has enough to select and call it correctly without external context.
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%, and the description fully compensates by documenting all 11 parameters with defaults, allowed values, examples, and non-obvious behavior (e.g., min_evidence, bias as ranking, days_back=0 semantics). This is significantly more useful than the bare input 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 'Search news articles' – a specific verb and resource – and the detailed response/args breakdown makes the tool's purpose unmistakable. However, it never directly distinguishes itself from the sibling search_balanced_news or related bias-lookup tools, so it stops short of full sibling 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 Args section provides strong invocation guidance: empty query returns recent articles, bias is a ranking rather than a filter, min_evidence should be paired with only_analyzed, and days_back can be widened for older coverage. It lacks explicit 'when not to use this tool' or 'use sibling X instead' guidance, so it does not reach a 5.
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.
search_news1 field changedInput schema / properties / days_back / defaultPrevious value: -720New value: +90search_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_newsStock market data for AI agents: real-time quotes, financials, options, SEC filings and news.
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.
Realtime financial context for AI agents: what changed, who is affected, and what to watch next. One suite covering news, events, guidance, filing changes, sentiment, stakeholders, and alerts. Information-efficient responses with evidence for every result. First-class point-in-time safety for backtests. Pairs well with web search and a market-data API. All data is our own.
Add one secure layer between your agents and this server.
