Provides comprehensive access to Solana blockchain data and Helius infrastructure, allowing users to query account balances, parse transactions, manage digital assets (NFTs and tokens) via the DAS API, and execute SOL or token transfers.
MCP server for Helius — Solana blockchain data access for AI assistants, provided by Solana's fastest, most reliable infrastructure provider
See the CHANGELOG for version history and release notes.
Interested in contributing? Read the contribution guide before opening a PR.
Add to your MCP host's config (works with Claude, Cursor, Windsurf, and any MCP-compatible client):
{
"mcpServers": {
"helius": {
"command": "npx",
"args": ["helius-mcp@latest"]
}
}
}Or if you're using Claude Code:
claude mcp add helius npx helius-mcp@latestIf you already have a Helius API key:
export HELIUS_API_KEY=your-api-keyOr set it from your AI assistant by calling the setHeliusApiKey tool.
If you need a new account:
The MCP includes a signup tool with three modes:
Call the generateKeypair tool — it creates a Solana wallet and returns the address
Call signup with mode: "link" — returns a paymentUrl (e.g. https://dashboard.helius.dev/pay/<id>) you open in any browser to pay with any wallet
After paying in the browser, call signup with mode: "resume" — finalizes provisioning and configures the API key automatically
Or skip the browser: call signup with mode: "autopay" to pay USDC from the local keypair (wallet must hold ~0.001 SOL + the plan amount in USDC)
All paid plans:
signupandupgradePlanrequirefirstName, andlastNamefor new signups (every plan, including Agent).
Or do the same from the terminal:
npx helius-cli@latest keygen # Generate keypair
npx helius-cli@latest signup --plan agent # Print hosted payment link
# (pay in browser, then:)
npx helius-cli@latest signup --resume # Finalize account
# Or autopay USDC from the local keypair:
npx helius-cli@latest signup --plan agent --payAsk questions in plain English — the right tool is selected automatically:
"What NFTs does this wallet own?"
"Parse this transaction: 5abc..."
"Get the balance of Gh9ZwEm..."
"Create a webhook for <address>"
Related MCP server: DFlow MCP Server
Helius MCP exposes 10 public tools total: 9 routed domain tools plus expandResult.
heliusAccount — account setup, auth, plans, billing
heliusWallet — wallet balances, holdings, wallet history, identity
heliusAsset — assets, NFTs, collections, token holders
heliusTransaction — transaction parsing and wallet transaction history
heliusChain — chain state, token accounts, blocks, network status, stake reads, transaction simulation
heliusStreaming — webhook CRUD and subscription config
heliusKnowledge — docs, guides, pricing, troubleshooting, source, blog, SIMDs
heliusWrite — transfers and staking mutations
heliusCompression — compressed account, balance, proof, and history actions
expandResult — expand summary-first outputs by resultId
The 9 routed domain tools share a common shape:
action — the Helius action name to run, such as getBalance or createWebhook
domain-specific params — for example address, signatures, or webhookURL
optional detail — summary, standard, or full
telemetry fields — _feedback, _feedbackTool, _model
Each routed tool takes an action field with the Helius action name:
{
"name": "heliusWallet",
"arguments": {
"action": "getBalance",
"address": "Gh9ZwEmdLJ8DscKNTkTqPbNwLNNBjuSzaG9Vp2KGtKJr",
"_feedback": "initial balance check",
"_feedbackTool": "heliusWallet.getBalance",
"_model": "your-model-id"
}
}Heavy responses are summary-first. Routed tools return a compact summary plus resultId when the full response would be large or when detail: "summary" is requested. Use expandResult with that resultId to fetch a specific section, range, page, or continuation slice on demand.
This package ships with pre-built system prompts that teach AI models how to use Helius tools effectively. Find them in system-prompts/:
system-prompts/
├── helius/ # Core Helius skill
├── helius-dflow/ # DFlow trading skill
├── helius-phantom/ # Phantom frontend skill
└── svm/ # SVM architecture skillEach contains three variants:
openai.developer.md — for OpenAI Responses/Chat Completions API (developer message)
claude.system.md — for Claude API (system prompt)
full.md — self-contained with all references inlined (Cursor Rules, ChatGPT, etc.)
See helius-skills/SYSTEM-PROMPTS.md for integration guides and code examples.
Mainnet Beta (default) and Devnet. Set via HELIUS_NETWORK env var or setNetwork in the session
Expand a prior summary-first result by resultId, section, range, page, or continuation.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | ||
| page | No | ||
| range | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| detail | No | ||
| section | No | ||
| resultId | Yes | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| continuation | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". |
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.
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.
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.
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.
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.
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.
Account setup, API keys, signup, plans, and billing. Use for pricing or account state, not per-method rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| plan | No | ||
| No | |||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| apiKey | No | ||
| detail | No | ||
| period | No | ||
| network | No | ||
| lastName | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| firstName | No | ||
| couponCode | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| discoveryPath | No | ||
| frictionPoints | No | ||
| paymentIntentId | No |
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.
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.
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.
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.
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.
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.
Assets, NFTs, collections, proofs, and token holders. Use for DAS ownership or metadata, not transaction history.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| ids | No | ||
| args | No | ||
| mint | No | ||
| name | No | ||
| page | No | ||
| burnt | No | ||
| limit | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| detail | No | ||
| frozen | No | ||
| address | No | ||
| groupKey | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| compressed | No | ||
| groupValue | No | ||
| onlyVerified | No | ||
| ownerAddress | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| creatorAddress | No | ||
| authorityAddress | No |
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.
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.
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.
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.
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.
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.
Raw chain state, token accounts, stake reads, blocks, network status, priority fees, and transaction simulation. Use for token accounts or blocks, not wallet portfolio summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| mint | No | ||
| page | No | ||
| slot | No | ||
| limit | No | ||
| owner | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| detail | No | ||
| address | No | ||
| dataSize | No | ||
| encoding | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| addresses | No | ||
| programId | No | ||
| sigVerify | No | ||
| commitment | No | ||
| accountKeys | No | ||
| transaction | No | ||
| stakeAccount | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| priorityLevel | No | ||
| includeAllLevels | No | ||
| replaceRecentBlockhash | No |
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.
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.
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.
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.
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.
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.
Compressed account, proof, balance, and compression history queries. Use for zk-compression state, not standard DAS assets.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| hash | No | ||
| mint | No | ||
| limit | No | ||
| owner | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| cursor | No | ||
| detail | No | ||
| hashes | No | ||
| address | No | ||
| delegate | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| addresses | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". |
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.
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.
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.
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.
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.
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.
Docs, guides, pricing references, troubleshooting, source, blog, and SIMD research. Use for guides, rate limits, or errors, not live mutations.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| path | No | ||
| repo | No | ||
| slug | No | ||
| query | No | ||
| scale | No | ||
| topic | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| branch | No | ||
| budget | No | ||
| detail | No | ||
| number | No | ||
| section | No | ||
| category | No | ||
| remember | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| errorCode | No | ||
| complexity | No | ||
| description | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". |
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.
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.
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.
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.
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.
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.
Webhook CRUD and live subscription configuration. Use for actual webhook/subscription setup, not how-to guides.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| detail | No | ||
| region | No | ||
| account | No | ||
| encoding | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| signature | No | ||
| webhookID | No | ||
| commitment | No | ||
| webhookURL | No | ||
| webhookType | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| accountOwners | No | ||
| accountExclude | No | ||
| accountInclude | No | ||
| accountRequired | No | ||
| accountAddresses | No | ||
| transactionTypes | No | ||
| subscribeAccounts | No | ||
| transactionAccountExclude | No | ||
| transactionAccountInclude | No | ||
| transactionAccountRequired | No |
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.
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.
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.
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.
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.
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.
Parsed transactions and wallet transaction history. Use for activity analysis, not raw account state.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| mode | No | ||
| limit | No | ||
| until | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| before | No | ||
| detail | No | ||
| status | No | ||
| address | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| signature | No | ||
| sortOrder | No | ||
| signatures | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| tokenAccounts | No | ||
| paginationToken | No | ||
| transactionDetails | No |
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.
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.
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.
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.
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.
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.
Wallet-centric balances, holdings, identity, and wallet history. Use for portfolio views, not raw token accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| mint | No | ||
| page | No | ||
| slot | No | ||
| time | No | ||
| after | No | ||
| limit | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| before | No | ||
| cursor | No | ||
| detail | No | ||
| address | No | ||
| datetime | No | ||
| showNfts | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| addresses | No | ||
| showNative | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| showZeroBalance | No |
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.
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.
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.
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.
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.
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.
Mutating SOL/token transfer and staking actions. Use for sends or staking, not read-only queries.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| _model | Yes | LLM model identifier, for example claude-opus-4-6 or gpt-4o. | |
| action | Yes | ||
| amount | No | ||
| detail | No | ||
| sendMax | No | ||
| _feedback | Yes | Short reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history". | |
| owsWallet | No | ||
| destination | No | ||
| mintAddress | No | ||
| stakeAccount | No | ||
| _feedbackTool | Yes | Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance". | |
| recipientAddress | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0expandResultheliusAccountheliusAssetheliusChainheliusCompressionheliusKnowledgeheliusStreamingheliusTransactionheliusWalletheliusWriteEach 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.
Nine tools follow the 'helius<Category>' pattern (e.g., heliusAccount, heliusChain), but 'expandResult' deviates, breaking full consistency. Casing is uniform (camelCase).
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Hosted MCP server for live Bittensor chain reads and self-custodial on-chain writes.
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
