Loading ToolBench
MCP server that provides Claude access to Solana RPC methods
Server exposes 25 Solana RPC tools with consistent naming (all start with action verbs like 'get_', 'send_'). All tools have descriptions (10-100 chars baseline met). Input schemas are present and properly typed for all tools. However, descriptions are uniformly terse (40-80 chars), lacking context about WHEN to use each tool, what data is returned, or error handling. Output schemas are not documented, LLMs cannot plan downstream calls or know what fields to expect. Parameters lack constraints (e.g., commitment enum values are mentioned in description but not formalized as enum constraints). No error guidance or recovery hints. The tools are functionally complete but optimized for API completeness rather than agent usability.
Returns all information associated with the account of provided Pubkey
Returns the balance of the account of provided Pubkey
Returns identity and transaction information about a confirmed block in the ledger
Returns the current block height of the node
Returns the estimated production time of a block
Returns information about all the nodes participating in the cluster
Returns information about the current epoch
Output schemas not documented. LLMs cannot infer what fields are returned, breaking downstream tool composition. For example, does getAccountInfo return account_owner, lamports, executable, rent_epoch? What type are they? Without this, agents cannot chain tools.
Commitment parameter across 16 tools mentions values (processed, confirmed, finalized) only in description text. Must be formalized as enum constraint in schema so LLMs see valid options as structured data, not free-form suggestions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 16 | - | v1 |
Returns the genesis hash
Returns the current health of the node
Returns the latest blockhash
Returns minimum balance required to make account rent exempt
Returns the account information for a list of Pubkeys
Returns the statuses of a list of signatures
Returns the slot that has reached the given or default commitment level
Returns information about the current supply
Returns the token balance of an SPL Token account
Returns all SPL Token accounts by token owner
Returns transaction details for a confirmed transaction
Returns the current Transaction count from the ledger
Returns the current Solana version running on the node
Returns the account info and associated stake for all the voting accounts in the current bank
Returns whether a blockhash is still valid or not
Requests an airdrop of lamports to a Pubkey (only available on devnet/testnet)
Submits a signed transaction to the cluster for processing
Simulate sending a transaction
Descriptions are uniformly terse (35 - 60 chars). Rubric baseline for A+ is 50 - 200 chars. Current descriptions lack WHEN to use the tool (e.g., getSlot vs getBlockHeight, when use each?), what output structure is returned, and what errors to expect. Expand with 1 - 2 sentences of context and error hints.
No error handling documentation. Tools like sendTransaction (IRREVERSIBLE) do not document failure modes, recovery steps, or when to retry. A tool that sends a signed transaction should warn agents: 'If the transaction fails with error X, retry is safe; error Y means double-spend risk, do not retry.' Agents have no guidance.
requestAirdrop (WRITE) and sendTransaction (IRREVERSIBLE) lack risk-acknowledgment text in descriptions. These are state-mutating and potentially irreversible. Descriptions must explicitly state 'This modifies the ledger and cannot be undone' or similar, so agents understand consequences.
Parameters lack type-level constraints. For example, address and signature parameters accept any string; no validation of base58 encoding or signature format is documented. Descriptions mention 'base58 encoded' but schema does not formalize this as a pattern or format constraint. LLMs cannot self-validate before calling.
No pagination guidance. Tools returning lists (getMultipleAccounts, getClusterNodes, getTokenAccountsByOwner) do not document limits or pagination. If getMultipleAccounts accepts 100+ addresses, does the API cap the request? Response? What does the LLM see? This risks context overflow.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in schema. Modern MCP (2026-07-28) supports tool annotations to signal risk profile. sendTransaction should be marked destructiveHint, simulateTransaction should be idempotentHint, and most get* tools should be readOnlyHint.