Loading ToolBench
MCP server providing Solana blockchain RPC methods and documentation resources
Four read-only RPC tools with basic Zod schemas and minimal descriptions. All tools are properly registered with schemas visible in index.ts. However, descriptions are extremely brief (20-75 chars), parameter descriptions are missing entirely, and there is no documented output schema. Tool naming follows verb_noun convention and is clear, but parameter documentation and schema detail lag significantly behind production baselines. No error recovery guidance, no parameter constraints beyond type, and output handling is generic JSON stringification. This server demonstrates foundational pattern understanding but lacks the depth expected of production-grade tools.
Used to look up account info by public key (32 byte base58 encoded address)
Used to look up balance by public key (32 byte base58 encoded address)
Used to look up minimum balance required for rent exemption by data size
Used to look up transaction by signature (64 byte base58 encoded string)
Parameter descriptions entirely missing. All four tools accept parameters (publicKey, dataSize, signature) with zero description text. LLMs cannot infer what 'publicKey' means (base58 format, account vs signer, network-specific behavior) without explicit documentation.
Tool descriptions are too brief (20-75 characters) and lack context for LLM selection. 'Used to look up account info by public key' does not explain WHEN to call this vs getBalance, WHAT fields are returned, or what account info contains. Minimum baseline is 10-1024 chars with WHAT/WHEN/HOW guidance.
No documented output schema. Tools return raw JSON via connection.getAccountInfo(), connection.getBalance(), etc., but the response structure (field names, types, nested objects) is never documented. LLMs cannot plan downstream operations or extract required IDs without knowing the response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Generic error handling with no recovery guidance. All four tools catch errors and return 'Error: <message>' as plain text. No categorization (retryable vs fatal), no suggestions for next steps (e.g., 'Try using a different public key format'), no actionable constraints.
Input validation entirely missing. Parameters accept free-form strings with no validation that publicKey is valid base58 or signature is 64 bytes. Invalid inputs fail at the Solana SDK layer with unhelpful errors instead of at the tool boundary with constraint violations.
No parameter format constraints. The 'publicKey' parameter is described in tool summary as '32 byte base58 encoded address' but this constraint is NOT in the Zod schema or parameter description. Zod accepts any string, forcing LLMs to reason about format compliance without explicit guidance.