Loading ToolBench
Model Context Protocol server for interacting with Solana blockchain. Enables wallet management, balance queries, slot information retrieval, and SOL token transfers.
This server has significant gaps in definition quality. Of 4 tools, none have documented input schemas in the visible code, descriptions are minimal (14-42 chars, well below the 50-200 char baseline for LLM-optimized tools), and there are no parameter descriptions. The code shows tool implementations but tool registration with schemas is not visible in the provided src/index.ts excerpt. Tool names follow verb conventions (get-*, transfer) but lack the specificity needed for clear disambiguation. The transfer tool accepts critical parameters ('to', 'amount') with type hints in code but no descriptions for the LLM. Error handling returns generic error messages without recovery guidance. No output schemas are documented.
Retrieves the latest slot number from the Solana blockchain
Retrieves the wallet address of the configured keypair
Retrieves the wallet balance in lamports, SOL, and USD equivalent
Transfers SOL tokens to a specified recipient wallet address
No input schemas visible in tool registration. Tools accept parameters (e.g., transfer accepts 'to' and 'amount') but JSON Schema definitions with types and descriptions are not shown in the code excerpt.
Tool descriptions are too short (14-42 characters) and generic. Rubric baseline: 50-200 chars for LLM-optimized descriptions. Examples: 'Retrieves the latest slot number from the Solana blockchain' (57 chars, acceptable but minimal context); 'Retrieves the wallet address of the configured keypair' (55 chars, lacks WHEN to use it or what it returns). Below 20 chars, description score MUST be 0-20.
No parameter descriptions. The transfer tool accepts 'to' (recipient address) and 'amount' (SOL amount) but the code shows no descriptions for these parameters. LLMs cannot infer that 'to' must be a valid Solana address or that 'amount' is in SOL units (not lamports).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No output schemas documented. Tools return untyped responses (e.g., getSlotTool returns a raw slot number, transferTool returns a transaction object). LLMs have no visibility into field names, types, or what data is available for chaining. Rubric: '100% of A+ tools have documented return types.'
Generic, non-actionable error messages. All tools catch errors and return error.message as plain text (e.g., 'Error reading keypair file'). No guidance on what the LLM should do next (retry, ask user, abort). Rubric: 'Error responses must tell the LLM what to do next.' Example: transfer tool catches Solana preflight failure but only logs context without recovery guidance.
transfer tool accepts 'amount' as a free-form number with no documented constraints. No minimum, no maximum, no mention that amounts must be > 0 or within user's balance. LLMs may pass negative, zero, or astronomically large values. Rubric: 'Specify minimum and maximum for numeric parameters.'
Irreversible operation (transfer) lacks dry-run or confirmation pattern. The tool directly sends SOL to a recipient address with no preview or user confirmation step.
Keypair secret stored in environment variable (KEYPAIR_PATH) but passed as a file path. If the keypair JSON is accidentally logged or included in error messages, the agent context exposes the secret. No indication in tool descriptions that this is a sensitive operation or that the agent should guard the keypair.
Tool names lack specificity for disambiguation. 'get-wallet-balance' could return balance in lamports, SOL, or USD. Code shows it returns all three (lamportsToSol conversion + getSolanaPrice call) but the name and description do not hint at this multi-unit response. Better names: 'get-wallet-balance-in-sol-and-usd' or separate tools.