Skip to main content
Glama
Sign In
Helius MCP

Helius MCP

Official
by helius-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Helius Account & Billing

heliusAccount
Destructive

Set up and manage account, API keys, signup, plans, and billing; check pricing or account state without per-method rate limits.

Instructions

Account setup, API keys, signup, plans, and billing. Use for pricing or account state, not per-method rate limits.

Input Schema

NameRequiredDescriptionDefault
argsNo
planNo
emailNo
_modelYesLLM model identifier, for example claude-opus-4-6 or gpt-4o.
actionYes
apiKeyNo
detailNo
periodNo
networkNo
lastNameNo
_feedbackYesShort reason for this call or takeaway from the previous result, e.g. "initial balance check" or "balance looked healthy, checking history".
firstNameNo
couponCodeNo
_feedbackToolYesCurrent public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance".
discoveryPathNo
frictionPointsNo
paymentIntentIdNo

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.5/5.0
Behavior2/5

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

Annotations flag destructiveHint=true and openWorldHint=true, and the description does nothing to scope that: several enum actions (upgradePlan, payRenewal, purchaseCredits, setHeliusApiKey) have real financial or credential consequences that the agent is never warned about. No mention of idempotency, auth requirements, or which actions are safe reads versus mutations. Not contradictory, but a significant disclosure gap for a destructive 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?

Two sentences with no filler, and the primary subject matter leads. The compression is part of the problem, but as a structure question it is efficient and 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?

A 12-action, 17-parameter, destructive, unannotated-by-description tool needs far more than two sentences, especially with no output schema to lean on. The agent does not know which parameters belong to which action, what a purchase or upgrade actually changes, or what comes back. Substantially inadequate for the complexity.

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 18% across 17 parameters, so the description must carry the load and it carries none of it. The action enum, the overloaded 'args' object, 'detail', 'period', 'network', and 'paymentIntentId' all go unexplained. "Pricing" and "account state" are the only weak bridges to parameters, and they are not enough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a noun list of resource areas ("Account setup, API keys, signup, plans, and billing") without a verb, but the topic is clearly distinct from siblings like heliusTransaction or heliusStreaming. It never explains that the tool is driven by a 12-value action enum, so an agent cannot tell what it actually does per call. Vague rather than tautological.

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?

"Use for pricing or account state, not per-method rate limits" does give one positive and one negative condition. However, the exclusion names no alternative tool for rate-limit questions, and no guidance is given on choosing between signup, plan, and payment actions within the enum. Usage is implied more than stated.

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

Deploy Server

Other Tools