Helium MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation3/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on April 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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 structured data (including AI-generated analysis and forecasts), throws an error for unrecognized tickers, and notes conditional availability of certain fields (e.g., 'when available'). However, it omits details like 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.
Conciseness4/5
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 detailed return values and parameter explanation. While comprehensive, some sentences could be more concise (e.g., listing return fields is lengthy but necessary). Overall, it avoids waste and maintains clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (returns extensive data) and the presence of an output schema, the description is complete enough. It thoroughly details return values, parameter semantics, and error behavior, compensating for the lack of annotations and low schema coverage, making it self-sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains the 'ticker' parameter with examples (e.g., 'AAPL', 'BTC'), clarifies it's for stocks, ETFs, or crypto, and notes error behavior for unrecognized symbols, fully compensating for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get comprehensive data') and resources ('stock, ETF, or crypto ticker'), distinguishing it from siblings like get_option_price or search_news. It precisely identifies what data is retrieved, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the tool returns comprehensive ticker data, but it lacks explicit guidance on when to use this tool versus alternatives like get_option_price or search_news. No exclusions or prerequisites are mentioned, leaving usage context inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it returns two separate ranked lists, explains what fields each entry contains, documents the five sort options with their meanings, and specifies default values. However, it doesn't mention rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, starting with the core purpose, then detailing return format, then sort options, then parameters. While comprehensive, some sentences could be more concise, and the field listing is quite detailed but necessary for understanding the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sort options, detailed return structure) and the presence of an output schema, the description is remarkably complete. It explains the dual-list return format, documents all sort options with semantics, fully describes parameters, and references the output structure. The output schema existence means the description doesn't need to exhaustively document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by providing comprehensive parameter semantics. It explains both parameters in detail: 'sort' with all five possible values and their meanings, and 'limit' with its range (1-20) and default. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve top-ranked trading strategies, specifically distinguishing between short volatility and long volatility strategies. It explicitly names the resource (trading strategies) and verb (get), and differentiates itself from sibling tools like get_ticker by focusing on ranked lists rather than individual ticker data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it returns ranked lists of strategies, but doesn't explicitly state when to use this tool versus alternatives like get_ticker or search tools. No guidance is provided about prerequisites, timing, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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's a read operation (implied by 'Get'), uses historical data up to 5 days back, throws errors for missing data or contracts, and returns specific fields. It could improve by mentioning rate limits or authentication needs, but covers core operational aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It front-loads the purpose, explains the process, lists return values, and details parameters—all in clear, efficient sentences with zero waste. Every sentence adds value, such as clarifying data freshness or error conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (ML-based prediction with 4 parameters) and the presence of an output schema (implied by the detailed return fields), the description is complete. It covers purpose, process, return values, parameters, and error conditions, providing all necessary context for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema: explains what each parameter represents (e.g., 'Ticker symbol', 'Strike price as a number'), provides examples (e.g., 'AAPL', 150.0), and specifies constraints (e.g., date format 'YYYY-MM-DD', option_type must be 'call' or 'put'). This fully documents all 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Helium's proprietary ML model-predicted price for a specific option contract.' It specifies the verb ('Get'), resource ('price'), and method ('Helium's proprietary ML model-predicted'), distinguishing it from siblings that focus on biases, news, or tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: to obtain a predicted fair-value price for a specific option contract using Helium's ML model. It mentions prerequisites (options chain data availability within 5 days) but does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by detailing the return format (list of stories with specific fields), search functionality, and filtering capabilities. However, it doesn't mention rate limits, authentication requirements, or error behaviors, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose statement, sibling differentiation, return format details, and parameter explanations in logical order. Every sentence adds value with zero wasted text, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), the description provides excellent context: clear purpose, sibling differentiation, detailed parameter semantics, and behavioral transparency about what the tool returns. This is complete for a search tool with output schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantic explanations for all 4 parameters: query purpose, limit range and default, category options with explicit enum values, and days_back meaning. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for 'balanced news stories — AI-synthesized articles that aggregate multiple sources' and explicitly distinguishes it from sibling tool 'search_news' which returns individual RSS articles. This provides specific verb+resource differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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: 'Unlike search_news (which returns individual RSS articles), this returns Helium's own synthesized stories.' This directly addresses sibling tool differentiation with clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![helium-mcp MCP server](https://glama.ai/mcp/servers/connerlambden/helium-mcp/badges/card.svg)](https://glama.ai/mcp/servers/connerlambden/helium-mcp)

Score Badge

Copy to your README.md:

[![helium-mcp MCP server](https://glama.ai/mcp/servers/connerlambden/helium-mcp/badges/score.svg)](https://glama.ai/mcp/servers/connerlambden/helium-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/connerlambden/helium-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server