Helius MCP

Official

by helius-labs

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Webhooks & Streaming

heliusStreaming

Destructive

Create and manage Helius webhooks, configure live Solana subscriptions, discover Parsed Streams programs, and check Preconfirmations coverage for real-time event monitoring.

Instructions

Webhook CRUD, live subscription configuration, Parsed Streams program discovery, and Preconfirmations coverage. Use for actual webhook/subscription setup, not how-to guides.

Input Schema

Name	Required	Description
`args`	No
`slots`	No
`_model`	Yes	LLM model identifier, for example claude-opus-4-6 or gpt-4o.
`action`	Yes
`active`	No
`detail`	No
`failed`	No
`region`	No
`account`	No
`program`	No
`encoding`	No
`programs`	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
`includeCpi`	No
`signatures`	No
`webhookURL`	No
`webhookType`	No
`accountRoles`	No
`instructions`	No
`_feedbackTool`	Yes	Current public tool and action in "tool.action" form, e.g. "heliusWallet.getBalance".
`accountOwners`	No
`includeFailed`	No
`includeSource`	No
`regionInclude`	No
`signerExclude`	No
`signerInclude`	No
`accountExclude`	No
`accountInclude`	No
`accountRequired`	No
`accountAddresses`	No
`instructionNames`	No
`transactionTypes`	No
`subscribeAccounts`	No
`notificationDetails`	No
`transactionAccountExclude`	No
`transactionAccountInclude`	No
`transactionAccountRequired`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv2.1.2Nov 4, 2026

addedInput schema / properties / accountRoles

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / action / enum

Previous value: -[
-  "createWebhook",
-  "getAllWebhooks",
-  "getWebhookByID",
-  "updateWebhook",
-  "deleteWebhook",
-  "transactionSubscribe",
-  "accountSubscribe",
-  "laserstreamSubscribe"
-]New value: +[
+  "createWebhook",
+  "getAllWebhooks",
+  "getWebhookByID",
+  "updateWebhook",
+  "deleteWebhook",
+  "toggleWebhook",
+  "transactionSubscribe",
+  "accountSubscribe",
+  "laserstreamSubscribe",
+  "describeProgram",
+  "getPreConfCoverage",
+  "parsedTransactionSubscribe",
+  "preconfSubscribe",
+  "preprocessedSubscribe"
+]

addedInput schema / properties / active
```
Added value: +{
+  "type": "boolean"
+}
```
addedInput schema / properties / failed
```
Added value: +{
+  "type": "boolean"
+}
```
addedInput schema / properties / includeCpi
```
Added value: +{
+  "type": "boolean"
+}
```
addedInput schema / properties / includeFailed
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / properties / includeSource

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / instructionNames

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / instructions

Added value: +{
+  "items": {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / notificationDetails
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / program
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / programs

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / regionInclude

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / signatures

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / signerExclude

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / signerInclude

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / slots
```
Added value: +{
+  "type": "boolean"
+}
```

Changed2 schema fields changedv2.1.1Oct 22, 2026

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"
+  }
+]

First observedv2.1.0Jul 10, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is partly covered. The description adds nothing beyond that: it does not say which actions delete or mutate (deleteWebhook, toggleWebhook, updateWebhook), whether subscriptions are persistent or session-bound, what happens to an existing webhook on update, or any auth/rate-limit context. For a destructive, non-idempotent, open-world tool this is a substantial 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?

Two sentences, front-loaded with the resource list and ending with the discriminating exclusion. There is no filler or redundancy. It is arguably too terse for the surface area, but that is a completeness problem rather than a structure problem.

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?

This is a multiplexed tool with 14 distinct actions, 40 parameters, nested objects, no output schema, and destructive semantics. The description covers the topic area but gives an agent nothing to actually select an action or populate parameters correctly. It should at minimum group the actions into CRUD vs subscription vs discovery and note the destructive subset.

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 8% across roughly 40 parameters, so the description must compensate and does not. It mentions no parameter names at all, and critically does not map the 14-value action enum to intents or explain which of the many filter parameters (accountInclude, signerInclude, transactionAccountRequired, regionInclude, etc.) belong to which action. The diagram of args, slots, commitment, encoding is entirely undiscussed.

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 concrete resources covered: webhook CRUD, live subscription configuration, Parsed Streams program discovery, and Preconfirmations coverage. That is a specific verb+resource statement an agent can match against a request. It loses a point because it bundles four quite different capabilities into one sentence without saying what each actually produces, and it does not differentiate against most siblings beyond heliusKnowledge.

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?

There is one explicit exclusion: 'not how-to guides', which usefully routes documentation questions to heliusKnowledge. However, there is no guidance on which of the 14 action enum values to choose for a given intent, and no warning that some actions are destructive while others are read-only. Usage is implied from the resource list rather 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

Webhooks & Streaming

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools