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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered elsewhere. Beyond that, the description says nothing about what happens with a stale or unknown resultId, how continuation strings are obtained or exhausted, or what the detail levels change – the real behavioral questions for this 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?

A single front-loaded sentence with no filler. It is efficient, though the brevity edges into under-specification rather than pure concision.

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?

A 10-parameter, no-output-schema expansion tool needs far more: how the five addressing modes (section, range, page, item, continuation) relate or conflict, expected resultId provenance, and what full versus standard detail yields. None of this is present.

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 30% schema coverage across 10 parameters, the description should compensate but instead merely echoes parameter names (resultId, section, range, page, continuation). It adds no meaning for item, detail, or the three required _-prefixed bookkeeping parameters, which carry the most agent-facing burden.

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?

States a specific verb and resource: 'expand a prior summary-first result' and names the keys that drive the expansion. It is distinguishable from the sibling namespaces, though 'summary-first result' is unexplained jargon an agent may not resolve without extra 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?

No guidance on when to call this versus re-querying the originating helius* tool, nor on prerequisites such as whether the resultId must come from a prior call in the same session. Usage is only implied by the word 'prior'.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered structurally. Beyond that the description only adds the DAS-scope boundary; it discloses nothing about per-action behavior, pagination via page/limit, proof freshness, or response volume for a tool with nine heterogeneous read operations.

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 sentences with zero wasted words and the resource list front-loaded, which is structurally clean. But it is sized for a single narrow capability, not a nine-action multiplexer, so the brevity reads as under-specification rather than economy.

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 nine enum actions, 22 parameters at 14% schema coverage, and no output schema, the description is far too thin for the complexity it fronts. An agent knows the general topic but has no guidance on action selection or on what any of the undocumented parameters mean in practice.

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% across 22 parameters, so the description would need to compensate — and it does not, adding no meaning for `action`, `id`/`ids`, `ownerAddress`, `groupKey`/`groupValue`, `detail`, `page`, or `limit`. The only credit is that several parameter names are self-descriptive and 'token holders' lightly hints at mint-based holder lookup, which keeps this above the floor.

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 names the resource domain concretely (assets, NFTs, collections, proofs, token holders) and explicitly excludes transaction history, which routes the agent away from heliusTransaction. It stops short of naming the dispatch mechanism (the `action` enum of nine values), so the agent still can't tell from prose which capability is which.

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?

"Use for DAS ownership or metadata, not transaction history" gives one clear positive context and one exclusion, which is real routing value. However, with nine actions in a single tool, the critical usage decision — which action to pick for ownership vs. metadata vs. proof vs. holders — is completely unaddressed, and the alternative tool is never named.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered by structured data. The description adds no behavior beyond that: it never notes that getProgramAccounts and getBlock are expensive/large responses, says nothing about commitment levels, rate limits, or response depth, and only implicitly signals that the simulate* actions do not broadcast transactions. For a tool spanning 11 actions, that is a meaningful disclosure 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?

It is compact at two sentences with no redundancy, and the routing exclusion is placed at the end where it is easy to miss. The dominant style is a comma-separated capability dump rather than a front-loaded statement of what the tool is and how to drive it, so an agent must parse the list to extract scope.

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 11 actions, 26 parameters, 12% schema coverage, and no output schema, the description is far too thin to arm an agent for correct invocation. It does establish the read-only chain-data domain and one exclusion, but leaves action selection and per-action argument requirements entirely undocumented. Complexity here warrants at least a short action-to-purpose map.

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 12% across 26 parameters, so the description must compensate and largely does not: there is no action-to-parameter mapping (e.g. that getBlock needs slot, getTokenAccounts needs owner or mint, simulateTransaction needs transaction, getBundleStatuses needs bundleIds). Only faint hints leak through phrases like 'stake reads' and 'priority fees' implying stakeAccount, priorityLevel, and includeAllLevels. An agent calling this cannot infer required arguments from the description at all.

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 enumerates the concrete resource families covered (raw chain state, token accounts, stake reads, blocks, network status, priority fees, simulation, bundle status), which tells an agent it is a read-only chain-data dispatcher rather than a wallet/portfolio tool. The explicit 'not wallet portfolio summaries' exclusion separates it from heliusWallet. It stops short of naming sibling alternatives like heliusTransaction, so the boundary is only partially drawn.

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?

There is one concrete routing rule: 'Use for token accounts or blocks, not wallet portfolio summaries,' which is a real when-to-use/when-not pair. However, the tool exposes 11 distinct actions and the description gives no guidance on which action to pick for a given need, nor any prerequisites or exclusions against heliusTransaction, heliusAccount, or heliusAsset. Usage is implied by the capability 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.

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds almost no behavioral context beyond calling these queries: it does not mention indexing freshness, pagination, rate limits, auth requirements, or how action-specific behavior differs.

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 short sentences, front-loaded with the resource scope and followed immediately by the routing exclusion. There is no redundant wording or filler.

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?

For a tool with 23 actions, 15 parameters, low schema description coverage, and no output schema, the description is far too thin. It establishes the domain but leaves action selection, parameter requirements, and return behavior largely unexplained.

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%, so the description needs to compensate for undocumented parameters, but it does not explain action, hash, mint, owner, limit, cursor, detail, or the array parameters. It loosely groups query categories, yet gives no mapping from query type to required parameters or action selection.

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 names specific compressed-data resources (accounts, proofs, balances, compression history) and clarifies that this is for zk-compression state rather than standard DAS assets. That is enough to distinguish the domain from heliusAsset, though it does not identify a specific verb or enumerate the 23 action variants.

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 gives a clear when-to-use condition (zk-compression state) and an explicit exclusion (not standard DAS assets), which helps route away from asset-oriented siblings. It stops short of naming the alternative tool or explaining which action to choose for each query type.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile needs no restatement. The description adds nothing beyond that: no mention of action-specific behavior, pagination via paginationToken, detail-level effects, scan cost for scanTransactionHistory, or rate limits. A statement that scanning can be expensive or truncated by maxScannedTransactions would have been valuable context.

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 sentences, front-loaded with the resource, zero filler — good density and no repetition of annotations. But the brevity is under-specification rather than discipline for a 26-parameter tool with four actions; the second sentence is the only thing carrying operational 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?

For a tool with 26 parameters, four actions, low schema coverage, and no output schema, a two-sentence description leaves an agent without enough to invoke it correctly. There is no explanation of which arguments belong to which action, what the returned parsed transaction shape contains, or how pagination is continued. This is materially inadequate for the tool's complexity.

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 12% across 26 parameters, so the description must carry the burden and it carries none. Terms like mode, detail, returnShape, tokenAccounts, transactionDetails, sortOrder, and maxScannedTransactions are entirely opaque from both schema and description. Not one parameter or action is explained.

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 names the resource (parsed transactions, wallet transaction history) and the broad use case (activity analysis), which separates it from account-state siblings. However, it never mentions the four actions the enum exposes (parseTransactions, getTransactionHistory, scanTransactionHistory, getTransfersByAddress), so an agent cannot tell from the description which mode of the tool it is selecting. The purpose is implied rather than stated at the granularity the schema demands.

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?

"Use for activity analysis, not raw account state" gives one explicit exclusion and implicitly routes account-state queries to heliusAccount/heliusChain. What is missing is any guidance among the four actions and when each applies, which is the primary selection decision an agent faces here. The negative guidance is real but shallow.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing behavioral on top — no rate-limit or credit-cost notes, no pagination behavior despite cursor/limit/after/before parameters, and no indication of how expensive the nine actions are relative to each other.

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 short sentences, front-loaded with the resource scope followed by the usage rule, with no filler or repetition. It is efficient, though the brevity is partly under-specification rather than discipline given the tool's breadth.

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?

For a nine-action, twenty-parameter tool with no output schema and very low schema description coverage, two sentences are not enough to call it correctly. The agent is left guessing action selection, parameter applicability, and pagination semantics with no compensating documentation.

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 20 parameters and only 15% schema description coverage, the description carries the burden of explaining parameters but only loosely gestures at "balances, holdings, identity and history" with no mapping to actions or fields like mint, slot, detail, showNfts, showZeroBalance, or addresses. An agent still cannot infer which parameters apply to which action, which is the largest gap in this definition.

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 names the resource domains (balances, holdings, identity, history) but uses a noun-phrase list with no verb and never enumerates the nine actions in the `action` enum, so an agent cannot tell from the text that transfers, funded-by, batch identity, or historical-slot queries are supported. It does distinguish itself conceptually from raw token accounts, but the scope of the mega-tool stays fuzzy.

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?

"Use for portfolio views, not raw token accounts" gives one when-to-use case and one exclusion, which is real guidance. However, the exclusion does not name a concrete sibling tool (heliusAsset or heliusTransaction), and no guidance is given for choosing between the nine actions, which is the actual routing decision an agent faces.

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

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

The annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the description's burden is to add context such as irreversibility of transfers, fee implications, or whether a signature/confirmation step is required — it adds none of that. Calling the operations 'mutating' merely restates readOnlyHint=false, so the description contributes essentially nothing beyond the structured fields for a high-risk value-moving 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?

Two short, front-loaded sentences with no filler or redundancy. It is efficient, though the brevity tips into under-specification rather than disciplined concision.

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?

For a destructive, non-idempotent tool with 13 parameters at 23% schema coverage and no output schema, the description is far too thin — it says nothing about parameter-to-action mapping, required fields per action, or what a successful call returns (a signature? a transaction?). An agent could guess the entry point but not call it correctly from this text 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 23% across 13 parameters, and the description supplies no compensating meaning for action, amount, destination, recipientAddress, mintAddress, stakeAccount, owsWallet, sendMax, or detail. The only hint is that 'SOL/token' and 'staking' exist, which weakly signals the two action families but leaves the agent to infer which parameters apply to which action.

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 names a specific verb class and resource: 'Mutating SOL/token transfer and staking actions', which maps onto the action enum (transferSol, transferToken, stakeSOL, etc.) and clearly separates this tool from read-only siblings like heliusWallet or heliusChain. It stops short of enumerating the full action set (unstakeSOL, withdrawStake are only implied by 'staking actions'), so an agent must open the schema to see everything it can do.

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?

'Use for sends or staking, not read-only queries' gives both a positive use case and an explicit exclusion, which is more than most definitions offer. However, it names no alternative sibling for the excluded read path (heliusWallet/heliusTransaction) and gives no prerequisites such as a funded wallet or a required destination.

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