バイアススコアリング付きのリアルタイムニュース、ライブ市場データ、AIを活用したオプション価格設定 — すべてModel Context Protocolを通じて利用可能です。
Helium MCPを使用すると、AIアシスタントが以下にアクセスできるようになります：
320万件以上のニュース記事（5,000以上のソースから、それぞれ15以上のバイアス次元でスコアリング）
バランスの取れたニュース合成 — 左派、右派、中立の視点を集約し、一貫したストーリーとして提供
ライブ市場データ — 価格、IVランク、AI生成による強気/弱気ケース、価格予測
AIオプション価格設定 — 公正価値推定とITM（イン・ザ・マネー）確率のための独自のMLモデル
ミーム検索 — OCRテキストとキャプションを使用したバイラルミームのセマンティック検索
50件の無料クエリが含まれています。サインアップは不要です。
Related MCP server: Stocks MCP Server
CursorのMCP設定に追加してください：
{
"mcpServers": {
"helium": {
"url": "https://heliumtrades.com/mcp"
}
}
}~/Library/Application Support/Claude/claude_desktop_config.json に追加してください：
{
"mcpServers": {
"helium": {
"type": "streamable-http",
"url": "https://heliumtrades.com/mcp"
}
}
}WindsurfのMCP設定に追加してください：
{
"mcpServers": {
"helium": {
"serverUrl": "https://heliumtrades.com/mcp"
}
}
}.github/copilot-instructions.md またはMCP設定に追加してください：
{
"mcpServers": {
"helium": {
"type": "streamable-http",
"url": "https://heliumtrades.com/mcp"
}
}
}ストリーミング可能なHTTPエンドポイントに接続してください：
https://heliumtrades.com/mcp"ビットコインの強気ケースと弱気ケースは？"
get_ticker("BTC")
→ Bitcoin: $71,040.01
Bull case: "Institutional spot demand resumes... squeeze toward mid/upper-80ks to low-100ks"
Bear case: "Higher-for-longer rates, persistent ETF outflows... slide into 40–55k plausible"
Forecast: +1.8% over 37 days (range: -1.2% to +5.0%)
IV Rank: available
Options strategies: long vol + short vol packs included"CNNのバイアスはどの程度ですか？"
get_source_bias("CNN")
→ Emotionality: 7/10
30+ bias dimensions scored (political lean, fearfulness, opinion, oversimplification...)
Signature phrases: "trump threatens", "mortgage rates", "nuclear weapons"
Similar sources: NBC, PBS, AP, Newsweek, CBS
Per-article bias breakdown on recent stories included"今、最適なオプション取引は何ですか？"
get_top_trading_strategies()
→ AI-ranked short vol + long vol setups
Each includes: ticker, price, bull/bear case, 5 probability-weighted outcomes,
full option pack (strike, expiry, Greeks, ML fair value, probability ITM)"NVIDIAの完全な分析を教えて"
get_ticker("NVDA")
→ NVIDIA: $183.91
5 probability-weighted scenarios (38% mean-revert, 25% +10-25%, 20% -5-12%...)
Forecast: +4.2% over 37 days (range: -2.6% to +8.9%)
IV rank, volatility surface, term structure, return profile charts
27 time-horizon uncertainty visualizations (1-day to 995-day)"株式市場の暴落に関するミームを探して"
search_memes("stock market crash")
→ Babylon Bee: "Kamala Desperately Googles 'What Is A Stock Market Crash'" (32K likes)
→ "Everyone: 'omg the stock market is crashing!' / 500 cigarettes adapter" (437K likes)
Full OCR text, source, date, image URLs included5,000以上のソースから320万件以上の記事を全文検索します。ソース、カテゴリ、日付、最小シェア数でフィルタリング可能です。バイアススコア、AI要約、コンテキストを返します。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | 検索キーワード |
| integer | いいえ | 20 | 最大結果数 (1–100) |
| string | いいえ | — | ソース名でフィルタリング (例: |
| string | いいえ | — | 次のいずれか: |
| integer | いいえ | 720 | 過去N日以内の記事のみを含める |
| integer | いいえ | -1 | 最小合計ソーシャルシェア数 |
| string | いいえ |
| 次のいずれか: |
複数のソースを集約してバランスの取れた報道を提供するAI合成記事。各ストーリーには、要約、要点、証拠の内訳、潜在的な結果、関連ティッカーが含まれます。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | 検索キーワード |
| integer | いいえ | 10 | 最大結果数 (1–50) |
| string | いいえ | — | 次のいずれか: |
| integer | いいえ | 0 | 過去N日以内のストーリーのみを含める (0 = フィルタなし) |
ニュースメディアの深いバイアス分析：政治的傾向、感情的トーン、規範性、特徴的なフレーズ、類似ソース、歴史的傾向。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | ソース名 (例: |
| integer | いいえ | 10 | 含める最近の記事数 (1–50) |
記事URLを分析し、政治的傾向、感情、操作レベル、事実性などの次元ごとのバイアススコアを取得します。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | 記事の完全なURL |
株式、ETF、暗号資産の包括的なデータ：ライブ価格、AI生成による強気/弱気ケース、価格予測、IVランク、ボラティリティサーフェス、トップランクのオプション戦略。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | ティッカーシンボル (例: |
特定のオプション契約に対するHelium独自のMLモデルによる予測公正価値価格。予測価格、ITM確率、データ日付を返します。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | ティッカーシンボル (例: |
| number | はい | — | 行使価格 (例: |
| string | はい | — | 有効期限 ( |
| string | はい | — |
|
AIエッジスコア、期待値、市場状況によってランク付けされたHeliumの確信度の高いオプション設定。ショートボラティリティ戦略とロングボラティリティ戦略の両方を返します。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | いいえ |
| 次のいずれか: |
| integer | いいえ | 5 | 戦略タイプごとの結果数 (1–20) |
追跡されているすべてのニュースソースのバイアススコア。メディアの比較、信頼性によるランク付け、メディア環境の全体像把握に使用できます。100件以上の記事が分析されたすべてのソースを、平均ソーシャルシェア数順で返します。
パラメータ: なし
バイラルミームのセマンティック検索（画像、キャプション、OCRテキスト、いいね数、ソース帰属）。
パラメータ:
パラメータ | 型 | 必須 | デフォルト | 説明 |
| string | はい | — | 検索キーワード (OCRテキストとキャプションに対して照合) |
| integer | いいえ | 20 | 最大結果数 (1–100) |
プラン | 費用 | 詳細 |
無料 | $0 | ネットワークごとに50クエリ — サインアップ不要 |
従量課金 | $0.02/クエリ | Stripe経由で毎日請求。9つのツールすべて、無制限クエリ。 |
APIキーは heliumtrades.com/mcp-page で取得してください。
MIT
Get bias scores for every news source in the Helium database.
Returns a list of all sources (active within the last 36 days, with >100 articles analyzed),
sorted by avg_social_shares descending. Use this to compare sources, find the most credible
outlets, identify politically extreme sources, or build a ranked overview of the media landscape.
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 score (-50 to +50 for bipolar,
0 to +50 for unipolar). These keys are identical to what get_bias_from_url returns,
so you can compare article-level and source-level scores directly.
Political / ideological (bipolar: neg=left pole, pos=right pole):
'liberal conservative bias' neg=liberal, pos=conservative
'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=uncredible, pos=credible
'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
'bearish bullish bias' neg=bearish, pos=bullish
'emotional bias' neg=negative tone, pos=positive tone
Unipolar bias dimensions (higher = more of that trait):
'objective sensational bias' sensationalism
'opinion bias' opinion vs informative
'descriptive prescriptive bias' prescriptive vs descriptive
'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
'scapegoat bias' scapegoating
'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
Tip: use get_source_bias for full narrative descriptions and recent articles on a specific source.
Tip: bias_values keys here are identical to those in get_bias_from_url and search_news — compare them directly.
Warning: get_source_bias returns bias_scores with emoji-prefixed display keys (e.g. '🔵 Liberal <—> Conservative 🔴')
that are NOT interchangeable with the plain-text keys used here. Do not cross-reference them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 of behavioral disclosure. It effectively describes the tool's behavior: it returns a filtered list (active within last 36 days, >100 articles analyzed), sorted by avg_social_shares descending, and details the structure and meaning of the output data. However, it lacks information on potential limitations like rate limits, data freshness, or error conditions, which would be helpful for a tool with such rich output.
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 usage, but it becomes overly detailed in listing all bias dimensions, which might be better summarized or referenced. While the information is valuable, the extensive enumeration of bias keys (over 30 items) makes it less concise, though the tips and warnings at the end are well-placed for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (rich output data, no input parameters, and an output schema), the description is highly complete. It explains the filtering criteria, sorting order, output structure, and detailed semantics of bias scores, including comparisons to sibling tools. With an output schema present, it appropriately focuses on clarifying the meaning and usage of the returned data rather than just its format.
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 has 0 parameters with 100% coverage, so the baseline is 4. The description appropriately does not discuss parameters, as none exist, and instead focuses on the output semantics, which is valuable given the complexity of the returned data. It adds significant meaning by explaining the bias_values mapping and the distinction between bipolar and unipolar scores.
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 purpose: 'Get bias scores for every news source in the Helium database.' It specifies the verb ('Get'), resource ('bias scores for every news source'), and scope ('Helium database'), and distinguishes itself from sibling tools like get_source_bias by indicating this returns comprehensive data for all sources rather than a specific one.
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 explicit guidance on when to use this tool versus alternatives. It states 'Use this to compare sources, find the most credible outlets, identify politically extreme sources, or build a ranked overview of the media landscape,' and includes tips and warnings that differentiate it from get_source_bias and get_bias_from_url, clarifying key distinctions in output formats and use cases.
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:
- title, source, date, link, category
- teaser: article excerpt
- summary: one-sentence AI summary
- context: AI-generated context for the article
- bias_description: narrative description of this specific article's bias
- bias_values: dict of per-dimension bias scores using plain-text keys (same schema as
get_all_source_biases and search_news),
e.g. {"liberal conservative bias": 12.3, "overall credibility": 40.1, "emotional bias": -5.2, ...}
Positive values lean toward the second pole of each dimension (conservative, authoritarian, etc.).
- 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') and are
identical to those in get_all_source_biases and search_news. Note: get_source_bias returns
bias_scores with emoji-prefixed display keys — do not cross-reference them with bias_values here.
Args:
url: Full article URL, e.g. 'https://www.nytimes.com/2024/01/01/us/politics/example.html'.
| Name | Required | Description | Default |
|---|---|---|---|
| url | 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 and does so well by disclosing key behaviors: it describes success/failure outcomes (including HTTP 404 details), automatic queuing for ingestion with retry advice (~24 hours), and clarifies differences in bias value formats compared to other tools. It doesn't mention rate limits or auth needs, but covers most operational aspects.
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 and front-loaded with the core purpose, followed by usage guidance, detailed return values, and parameter info. While comprehensive, some sections (like the detailed bias_values explanation) are slightly verbose but still informative. Most sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bias analysis with multiple dimensions), no annotations, and an output schema (implied by the detailed return description), the description is highly complete. It thoroughly documents success/failure outcomes, return fields, behavioral notes (queuing, retry), parameter details, and sibling tool differentiation, leaving no significant gaps.
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 has 0% description coverage (no schema descriptions), but the description fully compensates by providing detailed parameter semantics in the 'Args' section: it explains the 'url' parameter with a clear example and formatting guidance ('Full article URL, e.g. ...'). This adds substantial value 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 clearly states the tool's purpose with specific verbs ('Get bias analysis') and resources ('for a specific article by its URL'), explicitly distinguishing it from sibling tools like get_source_bias for source-level analysis. It specifies the analysis includes political leaning, credibility, emotionality, and other bias dimensions.
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 explicit guidance on when to use this tool ('when you have a direct link to an article and want to know its political leaning... without needing to know the source name first') and when not to use it (with tips directing to get_source_bias for source-level bias). It also mentions retry timing after failures.
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 |
|---|---|---|---|
| symbol | Yes | ||
| strike | 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
- articles_analyzed: total articles in the bias database for this source
- 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_scores: dict of all measured bias dimensions with scores (-50 to +50 for bipolar,
0 to +50 for unipolar). WARNING: this endpoint returns emoji-prefixed display keys
(e.g. '🔵 Liberal <—> Conservative 🔴') rather than the plain-text keys used by
get_bias_from_url, get_all_source_biases, and search_news (e.g. 'liberal conservative bias').
Do not attempt to cross-reference bias_scores keys here with bias_values keys from other endpoints.
- bias_description: AI-generated overall bias summary narrative
- 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 and per-article bias_values
Throws an error if the source is not found.
Args:
source: Source name (e.g. 'Fox News', 'CNN', 'Reuters') or domain (e.g. 'foxnews.com').
Slug-style input (e.g. 'fox-news') is NOT supported — use full name or domain only.
recent_articles: Number of recent articles to include (1-50, default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| recent_articles | 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 burden and excels at behavioral disclosure. It details the comprehensive return structure (16+ fields), warns about key format differences from other endpoints, specifies error conditions ('Throws an error if the source is not found'), and explains optional field availability ('only present when available').
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 appropriately sized for a complex tool with extensive returns. It's well-structured with clear sections for returns, warnings, and parameters. While comprehensive, every sentence adds value - no fluff or repetition. Could be slightly more front-loaded by moving the parameter details earlier.
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 (comprehensive bias analysis with 2 parameters and extensive returns), no annotations, and an output schema (which handles return structure), the description is remarkably complete. It covers purpose, usage, detailed return semantics, parameter details, warnings, and error conditions - leaving no significant gaps.
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?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains the 'source' parameter accepts name or domain (not slug), gives examples, and clarifies the 'recent_articles' parameter's range (1-50) and default value (10) - information not in the 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 clearly states the tool's purpose: 'Get comprehensive bias analysis for a news source.' It specifies the verb ('Get') and resource ('bias analysis for a news source'), and distinguishes it from siblings like get_bias_from_url (which analyzes URLs) and get_all_source_biases (which lists all 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 provides clear context for when to use this tool: for analyzing bias of a specific news source. It distinguishes from get_bias_from_url (URL analysis) and get_all_source_biases (all sources list), but doesn't explicitly state when NOT to use it or mention alternatives like search_news for article-level analysis.
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 image URLs for future_uncertainty, term_structure, volatility_surface, return_profile (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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns comprehensive data, includes AI-generated and model forecast elements, provides URLs for additional resources when available, and explicitly states it throws an error for unrecognized tickers. This covers most critical aspects, though it could mention rate limits or authentication needs.
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 with clear sections (Returns, Throws, Args) and uses bullet points for readability. It is appropriately sized, but some bullet points could be more concise (e.g., listing individual fields like 'bullish_case' might be streamlined). Overall, it's efficient with minimal waste.
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 (returns diverse data types), no annotations, and an output schema present, the description is highly complete. It thoroughly details return values, error conditions, and parameter usage, compensating for the lack of annotations and low schema coverage. The output schema likely covers return structure, so the description focuses on semantics, which it does effectively.
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 has 0% description coverage, so the description must compensate. It adds meaningful semantics by explaining the 'ticker' parameter as a symbol for stocks, ETFs, or crypto, with examples like 'AAPL' and 'BTC'. This clarifies usage beyond the schema's basic string type, though it doesn't detail format constraints like case sensitivity.
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 specific verb ('Get') and resource ('comprehensive data for a stock, ETF, or crypto ticker'), distinguishing it from siblings like get_option_price or search_news. It explicitly lists the types of data returned, making the purpose unambiguous and distinct.
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 specifying the types of tickers supported (stock, ETF, crypto) and noting it throws an error for unrecognized symbols. However, it lacks explicit guidance on when to use this tool versus alternatives like get_option_price or search_news, leaving some context to inference.
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 |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| 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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | 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 burden. It discloses key behavioral traits: it's a search operation (implied read-only), returns ranked results by relevance, and details the structure of each result (including fields like id, image URL, source, etc.). However, it lacks information on rate limits, authentication needs, or error handling.
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 and front-loaded, starting with the core purpose, followed by return details and parameter explanations. Every sentence adds value without redundancy, making it efficient and easy 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 moderate complexity, no annotations, and the presence of an output schema (which covers return values), the description is complete. It adequately explains the purpose, parameters, and result structure, leaving no critical gaps for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'query' matches against OCR text and captions, clarifies 'limit' as max results with a range (1-100) and default (20), and notes that 'query' is required. This fully compensates for the schema's lack of 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 the specific action ('Search Helium's meme database by text') and resource ('meme database'), distinguishing it from sibling tools that focus on news, biases, or financial data. It explicitly mentions OCR and caption matching, which defines the search scope precisely.
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 searching memes by text, but it does not explicitly state when to use this tool versus alternatives like sibling tools (e.g., search_news). No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.
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:
- title, source, date, link, category, rank, 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)
- context: AI-generated contextual background for the article (when available)
- raw_data: additional raw metadata fields (when available)
Args:
query: Search keywords (required).
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| source | No | ||
| category | No | ||
| days_back | No | ||
| min_shares | No | ||
| sort | No | rank |
| 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 of behavioral disclosure. It describes the return format in detail (list of articles with specific fields) and mentions availability conditions ('when available'), which adds useful context. However, it lacks information on rate limits, authentication needs, or error handling, leaving gaps for a mutation-free search 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-structured and appropriately sized. It starts with the core purpose, details the return format, and lists parameters with clear explanations. While slightly verbose due to the parameter details, every sentence adds value, and it's front-loaded with key information.
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 (7 parameters, no annotations) and the presence of an output schema (implied by 'Returns a list'), the description is largely complete. It thoroughly documents parameters and return values, though it could benefit from more behavioral context (e.g., rate limits). The output schema reduces the need to explain returns in depth.
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 adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose, constraints (e.g., '1-100' for limit, enum values for category and sort), and defaults, fully compensating for the schema's lack of documentation. This is essential given the 7 parameters with minimal structured info.
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 purpose: 'Search news articles.' It specifies the verb ('search') and resource ('news articles'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_balanced_news' or 'search_memes', which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_balanced_news' or 'search_memes', nor does it specify prerequisites or exclusions. Usage is implied by the parameters but not explicitly stated.
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.
v0.1.0get_all_source_biasesget_bias_from_urlget_option_priceget_source_biasget_tickerget_top_trading_strategiessearch_balanced_newssearch_memessearch_newsScored across 9 tools
The tool set covers three distinct domains: news bias analysis (get_all_source_biases, get_bias_from_url, get_source_bias, search_news, search_balanced_news), financial data (get_ticker, get_option_price, get_top_trading_strategies), and meme search (search_memes). However, within the news bias domain, there is significant overlap between get_all_source_biases, get_source_bias, and search_news, as they all retrieve bias scores with similar data structures, potentially causing confusion about which tool to use for source-level vs. article-level analysis.
Most tools follow a consistent verb_noun pattern (e.g., get_all_source_biases, get_bias_from_url, get_source_bias, get_option_price, get_ticker, get_top_trading_strategies, search_balanced_news, search_memes, search_news). The naming is clear and predictable, with 'get_' for retrieval and 'search_' for querying. Minor deviations include 'get_all_source_biases' using 'all' as a modifier, but overall the pattern is well-maintained.
With 9 tools, the count is reasonable for a server covering news bias, financial data, and memes. It's slightly broad in scope, but each domain has a focused set of tools: 5 for news bias, 3 for finance, and 1 for memes. The number is manageable and aligns with the server's purpose of providing diverse analytical insights, though the overlap in news tools might suggest some consolidation could improve efficiency.
For the news bias domain, the tools offer robust retrieval and search capabilities but lack explicit update, delete, or creation operations, which is acceptable for a read-only analysis service. In finance, tools cover ticker data, option pricing, and trading strategies, but there's no direct market data updates or portfolio management. The meme tool is standalone. Overall, the set supports core queries but has notable gaps for interactive or write operations, limiting agent workflows to read-only tasks.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Real-time whale trades, Smart Money Radar, market snapshots, news sentiment, signal outcomes.
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
