Skip to main content
Glama

Helius Docs & Knowledge

heliusKnowledge

Look up Helius and Solana docs, guides, pricing, rate limits, webhooks, troubleshooting, source files, blogs, and SIMD research; use for reference and error fixes, not live mutations.

Instructions

Docs, guides, pricing references, troubleshooting, source, blog, and SIMD research. Use for guides, rate limits, or errors, not live mutations.

Input Schema

NameRequiredDescriptionDefault
argsNo
pathNo
repoNo
slugNo
queryNo
scaleNo
topicNo
_modelYesLLM model identifier, for example claude-opus-4-6 or gpt-4o.
actionYes
branchNo
budgetNo
detailNo
numberNo
sectionNo
categoryNo
rememberNo
_feedbackYesShort reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history".
errorCodeNo
complexityNo
descriptionNo
_feedbackToolYesCurrent public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / args / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": true,
      -    "properties": {},
      -    "type": "object"
      -  },
      -  {
      -    "type": "string"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": {},
      +    "properties": {},
      +    "type": "object"
      +  },
      +  {
      +    "type": "string"
      +  }
      +]
  2. First observedv2.1.0

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and openWorldHint=true, but the description never reconciles this with its claim of being a non-mutation knowledge tool; the undocumented 'remember' parameter suggests state persistence that is never explained. It also discloses nothing about network fetching for source/blog/SIMD retrieval, caching, or rate limits on these lookups.

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?

Two short sentences with no filler, and the usage constraint comes after the scope statement. The opening is a dense noun list rather than a front-loaded statement of purpose, which costs it a point.

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?

For a 21-parameter, 17-action, open-world tool with no output schema, the description is drastically under-specified. An agent cannot infer from it which action to select or what any argument means, so it fails to make the tool callable from the description 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 14% across 21 parameters, so the description must compensate and does not. It hints at the existence of source/blog/SIMD content but never maps those to the action enum values, nor explains args, path, repo, slug, budget, scale, detail, or remember.

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 names the resource precisely: Helius docs, guides, pricing references, troubleshooting, source, blog, and SIMD research. That distinguishes it from the chain/wallet/write siblings, although it does so with a bare noun list rather than a verb, and never mentions the 17-action dispatch surface that defines the tool.

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?

It gives a positive trigger (guides, rate limits, errors) and one exclusion ("not live mutations"), which implies heliusWrite is the alternative without naming it. However, it says nothing about how to choose among the 17 actions, so the guidance covers only a fraction of the real selection decisions an agent faces.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.