Helius MCP

Official

by helius-labs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation5/5
Each tool has a clearly distinct domain (e.g., Asset vs Compression, Transaction vs Wallet), and their descriptions explicitly state what to use and what not to use, eliminating ambiguity.
Naming Consistency4/5
Nine tools follow the 'helius<Category>' pattern (e.g., heliusAccount, heliusChain), but 'expandResult' deviates, breaking full consistency. Casing is uniform (camelCase).
Tool Count5/5
With 10 tools, the set is well-scoped for a comprehensive Solana blockchain API, covering accounts, assets, chain state, compression, transactions, wallets, streaming, writes, and knowledge.
Completeness5/5
The tool surface is remarkably complete for the domain: account setup, asset queries, raw chain state, compressed state, transaction history, wallet portfolios, webhooks, writes, and documentation – no obvious gaps for common operations.
Average 3.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 50 commits in the last 12 weeks
- Last stable release on June 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool returns 'parsed transactions' but does not mention side effects, authentication requirements, rate limits, or whether it is read-only. The agent lacks critical information about network calls and potential mutability, which is essential for safe invocation.
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 concise with two short sentences. The first sentence states the purpose, and the second provides a usage hint. While it is not verbose, it is too minimal for a complex tool and lacks depth, bordering on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, 4 required, no output schema, no annotations), the description is severely incomplete. It does not describe return values, pagination, error handling, or how to use the various optional parameters. The agent has insufficient information to correctly construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 18 parameters with only 17% coverage (only _model, _feedback, _feedbackTool have descriptions). The description does not explain any parameters, such as the critical 'action' enum or optional filters like 'address', 'signature', 'limit', etc. For a tool with many parameters, the description must compensate for the schema's lack of descriptions, but it entirely fails to do so.
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 states 'Parsed transactions and wallet transaction history' which clearly identifies the tool's scope as transaction-related. The phrase 'not raw account state' hints at differentiation from sibling tools like heliusAccount. However, it could be more specific by listing the actions (parseTransactions, getTransactionHistory, getTransfersByAddress) that are defined in the schema.
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 says 'Use for activity analysis, not raw account state.' This provides a general guideline on when to use the tool (activity analysis) and hints at when not to use it (raw account state). However, it does not explicitly mention alternative tools or provide clear scenarios for each action, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It mentions a range of operations (e.g., 'simulateTransaction' implies a simulation, not a real mutation), but it does not disclose side effects, authentication needs, rate limits, or whether operations are read-only or state-changing. The lack of detail for a complex tool is a significant gap.
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 concise at two sentences, covering purpose and a usage hint. However, given the tool's complexity, the conciseness comes at the cost of omitted essential detail. Still, it is not verbose and gets the core idea across quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far from complete for a tool with 24 parameters, many actions, no output schema, and no annotations. It does not explain the role of the 'action' parameter, parameter dependencies, or expected outputs. Sibling tools exist for more specific tasks, but this tool's scope is poorly delineated. The description needs to be expanded significantly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 13% schema description coverage, the description should compensate by explaining key parameters. However, the description provides zero information about parameters such as 'action', 'address', 'mint', 'slot', etc. It does not even mention that 'action' selects the operation. This is a critical omission for a tool with 24 parameters.
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 lists multiple capabilities ('Raw chain state, token accounts, stake reads, blocks, network status, priority fees, and transaction simulation') which gives a broad but clear sense of the tool's domain. It also explicitly states what not to use it for ('not wallet portfolio summaries'), distinguishing it from sibling heliusWallet tool. A more specific verb like 'read' or 'query' could improve clarity.
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 includes a negative guideline ('not wallet portfolio summaries') which helps avoid misuse, but it does not explicitly mention when to use alternative sibling tools (e.g., heliusTransaction for transactions, heliusAccount for account data). It gives some context but lacks comprehensive alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must convey behavioral traits. It only states the tool's purpose but fails to disclose any side effects, authorization needs, rate limits, or whether actions are destructive. For a tool with CRUD and subscription actions, this lack of transparency is a significant gap.
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 short (two sentences) and front-loads purpose, but it is too terse for a tool with many parameters. While concise, it sacrifices necessary detail, making it only adequately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, no output schema, and no annotations, the description is insufficient. It does not explain return values, parameter dependencies, or how actions relate to parameters, leaving major gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, and the tool has 24 parameters. The description adds no parameter information, leaving the agent to guess the meaning and usage of parameters like 'args', 'action', 'detail', etc. This is a critical failure given the parameter complexity.
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 'Webhook CRUD and live subscription configuration' clearly identifies the tool's purpose as managing webhooks and subscriptions, distinguishing it from sibling tools like heliusAccount or heliusAsset. However, it could be more specific about the range of actions (e.g., CRUD and subscription types).
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 phrase 'Use for actual webhook/subscription setup, not how-to guides' gives minimal guidance on when to use the tool, implying it's for real configuration rather than educational purposes. No explicit alternatives or exclusions are mentioned, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the action 'Expand' without specifying whether it is a read-only operation, any side effects, required permissions, rate limits, or what gets destroyed. The description is insufficient for understanding the tool's impact.
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 a single efficient sentence with no wasted words. It conveys the core purpose directly and is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 4 required, no output schema, and no annotations, the description is too brief to be complete. It does not explain the return value, behavior in edge cases, or relationship to prior results, leaving agents with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (30%), and the description only lists parameter names (resultId, section, range, page, continuation) without explaining their meaning, format, or constraints. Parameters like 'item', 'detail', and 'page' are not elaborated, leaving the agent with little understanding beyond names.
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 verb 'Expand', the resource 'prior summary-first result', and the expansion criteria (resultId, section, range, page, or continuation). It implies a specific use case but does not explicitly differentiate from sibling tools, which are all helius-prefixed and likely unrelated in function.
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?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description assumes the user already knows the context of 'prior summary-first result' without explaining the scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 implies read-only access by mentioning 'ownership or metadata' but never explicitly states that the tool is read-only, nor does it mention side effects, auth needs, or rate limits. This is a significant gap for a tool with 22 parameters.
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 a single sentence, concise and front-loaded with key terms. However, it sacrifices necessary detail for brevity, which harms overall utility. For a complex tool, it is overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 22 parameters, no output schema, and low schema coverage, the description is severely incomplete. It does not explain how to perform actions, what the inputs mean, what responses look like, or how to handle the tool effectively. This is totally inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, yet the tool description adds no information about any parameters. It does not explain what 'id', 'ids', 'action', etc., mean or how they relate to the tool's purpose. For a tool with 22 parameters, the description must compensate but fails to do so.
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 identifies the tool covers assets, NFTs, collections, proofs, and token holders. It specifies it is for DAS ownership or metadata, distinguishing it from transaction history. However, it does not explicitly mention the available actions (e.g., getAsset) which are in the schema, leaving some ambiguity about the full scope.
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 provides a guideline: 'Use for DAS ownership or metadata, not transaction history.' This hints at when to use vs alternative tools like heliusTransaction, but it lacks explicit when-not-to-use scenarios and does not mention other sibling tools that might overlap, leaving usage decisions partially unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies read-only behavior ('queries') but does not explicitly disclose whether it's read-only, destructive, or any other traits like rate limits or authentication needs. The minimal context is insufficient.
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?
Two concise sentences, front-loaded with the key purpose and usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (15 parameters, no output schema, no annotations), the description is very brief. It does not explain return values, pagination, or how to select among the 22 enumerated actions. The description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, yet the description adds no information about any of the 15 parameters. It fails to compensate for the low coverage, leaving the agent without guidance on how to use parameters like 'action', 'args', or 'cursor'.
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 handles compressed account, proof, balance, and compression history queries for zk-compression state, distinguishing it from standard DAS assets. However, it uses a broad category rather than a specific verb+resource, making it less precise.
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 explicitly says 'Use for zk-compression state, not standard DAS assets,' providing clear context for when to use this tool. It does not elaborate on when not to use it beyond this contrast, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. The description only lists topics (setup, billing, etc.) without disclosing side effects, permissions, or whether actions are read-only vs destructive. For a tool with many actions (including upgradePlan, payRenewal), behavioral details are missing.
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 two sentences, front-loaded with the purpose and followed by a usage guideline. No filler or redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, 12 action enum values, no output schema, no annotations), the description is insufficient. It does not cover the variety of actions or the many parameters. For example, it doesn't explain that 'action' determines the specific operation, leaving the agent to guess based on enum names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, meaning most parameters have no documentation in the schema. The tool description does not explain any parameters beyond hinting at the domain. For example, it does not clarify the 'action' enum values or the purpose of 'email', 'plan', etc. The description adds no parameter meaning beyond what the schema's minimal descriptions provide.
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 states a broad domain: 'Account setup, API keys, signup, plans, and billing.' It is clear about the resource category but lacks a specific verb-resource combination. The action enum provides more specificity, but the description itself is generic. It distinguishes from siblings by noting 'not per-method rate limits,' which adds context.
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 explicitly says 'Use for pricing or account state, not per-method rate limits.' This gives clear context on when to use this tool versus others (like heliusTransaction). However, it does not name specific alternative tools or conditions when not to use it, just a negative hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It indicates the tool is mutating (write) but provides no details on authentication requirements, rate limits, error behavior, or side effects beyond basic mutation. This is insufficient for a 13-parameter mutation 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 consists of one succinct sentence with a clear front-loaded verb and resource. It is concise and waste-free, though it could include a bit more detail without harming brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, 4 required, no output schema), the description is incomplete. It does not explain the distinct actions, parameter dependencies (e.g., destination for transfers, stakeAccount for staking), or response format. An agent would struggle to use this tool correctly without examining the schema extensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 23%, requiring the description to compensate. It does not explain any parameter beyond the implicit hint of 'transfer' and 'staking'. Required parameters like action, _feedback, _feedbackTool, and _model are not described, and optional parameters like destination, amount, etc., are unmentioned. The description adds minimal semantic value over 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 identifies the tool as performing mutating SOL/token transfer and staking actions. It uses specific verbs ('mutating', 'sends', 'staking') and explicitly distinguishes it from read-only queries, differentiating it from siblings like heliusChain or heliusAsset.
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?
Explicitly states to use for 'sends or staking' and not for 'read-only queries', providing clear context on when to use the tool. While it doesn't list alternative tools by name, the sibling tool names imply read-heavy operations, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It implies read-only operations by listing data types (balances, holdings), but does not explicitly state safety, side effects, or auth requirements. Adequate but not explicit.
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?
Two concise sentences that front-load the primary purpose and provide immediate actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, no output schema, no annotations), the description is far too brief. It omits critical details such as pagination, action descriptions, and return format, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 15%, and the description provides no additional parameter details beyond the high-level purpose. With 20 parameters and an action enum of 9 values, the agent lacks guidance on how to use them correctly.
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 is for wallet-centric data (balances, holdings, identity, history) and explicitly distinguishes it from raw token account tools, providing a specific resource and scope for portfolio views.
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?
It says to use for portfolio views and not for raw token accounts, giving clear context and exclusion. However, it does not explicitly name sibling tools like heliusAccount as alternatives, which would strengthen guidance.
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 takes on full burden. It correctly indicates the tool is non-mutating ('not live mutations'), which implies read-only behavior. However, it lacks details on side effects, error handling, or return behavior, so it is not fully transparent.
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 a single sentence followed by a short usage note, both front-loaded and concise. Every part adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (21 parameters, 17 action enums, no output schema, no annotations), the description is too brief. It does not explain the purpose of each action or how parameters interact, leaving a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, yet the description provides no guidance on the meaning of the 21 parameters (e.g., args, path, repo, slug, query, topic). It does not compensate for the low schema coverage.
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 covers 'Docs, guides, pricing references, troubleshooting, source, blog, and SIMD research.' and explicitly distinguishes from live mutations, making it clear this is a knowledge/reference tool distinct from sibling tools like heliusWrite or heliusTransaction.
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 explicitly says 'Use for guides, rate limits, or errors, not live mutations,' providing direct guidance on when to use this tool and when to use alternatives (other heliusX tools for mutations).
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:

[![core-ai MCP server](https://glama.ai/mcp/servers/helius-labs/core-ai/badges/card.svg)](https://glama.ai/mcp/servers/helius-labs/core-ai)

Score Badge

Copy to your README.md:

[![core-ai MCP server](https://glama.ai/mcp/servers/helius-labs/core-ai/badges/score.svg)](https://glama.ai/mcp/servers/helius-labs/core-ai)

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/helius-labs/core-ai'

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