Loading ToolBench
MCP server for Solana blockchain operations and agent kit integrations, providing access to token trading, DeFi protocols, and wallet management
This server has severe definition quality gaps across all dimensions. Tool descriptions are extremely sparse (most are 5-15 chars, well below the 34 char p10 baseline). No input schemas are visible in the provided source code, the tool files (e.g., operations/agent-kit/dexscreener/tools/get_token_data.js) are referenced but not shown, making it impossible to verify parameter types, constraints, or structured output documentation. The server mixes financial operations (token trading, launches) with infra tools (balance checks, transfers) without clear composition or error recovery patterns. Security is a major concern: tools execute write operations (trade, launch_pumpfun_token, transfer, close_empty_token_accounts) with no visible confirmation, permission gates, or rate limiting. The codebase shows 'solana-agent-kit' dependency, suggesting tool implementations are delegated to an external SDK, but there is no evidence of custom MCP tool wrapping with proper schemas. Most tool definitions appear to be inferred from action names rather than explicitly registered with JSON Schema.
Close empty token accounts on Solana
Fetch token price from Jupiter DEX aggregator
Get SOL balance for a wallet address
Get token balance for a wallet address
Get all token balances for a wallet
Get token data by ticker symbol from Jupiter
Get token data from DexScreener
Get Solana network transactions per second
NO INPUT SCHEMAS VISIBLE, all 14 tools have schema score 0. Tool implementation files (get_token_data.js, trade.js, etc.) are referenced in file paths but not provided in source code. Cannot verify parameter types, constraints, enums, or descriptions. This is a HARD FAILURE per scoring rules: 'If a tool has NO input schema at all: its schema score MUST be 0.' Tools cannot be safely invoked by LLMs without structured input schemas.
DESCRIPTIONS ARE CRITICALLY SHORT, all 14 tools have descriptions under 30 characters (5 - 15 chars typical). Baseline p10 for tool descriptions is 34 chars; these fall far below. Examples: 'Get token data from DexScreener' (31 chars), 'Fetch token price from Jupiter DEX aggregator' (45 chars, only one near acceptable). Per scoring rules, descriptions under 20 chars have hard cap of 0-20. LLMs cannot determine when/why to select these tools based on such sparse docstrings.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Get the current wallet address
Launch a new token on Pump.fun
Request funds from Solana faucet
Check token for rug pull indicators
Execute token trade via Jupiter DEX aggregator
Transfer tokens or SOL on Solana
NO PARAMETER DESCRIPTIONS, tool definitions show only short descriptions at the tool level; no evidence of per-parameter documentation. Per Arcade baseline, 100% of A+ tools have descriptions for every parameter. This server shows 0%. Without parameter docs, LLMs cannot understand what fields to provide, what formats are expected, or constraints on values.
WRITE OPERATIONS LACK CONFIRMATION & PERMISSION GATES, tools like 'trade', 'launch_pumpfun_token', 'transfer', 'close_empty_token_accounts', 'request_faucet_funds' are irreversible financial operations with no visible dry-run, confirmation prompt, or permission checks. Agents will execute these without guardrails, risking unintended token launches, fund transfers, or account closures. Pattern 'confirmation-request' and 'permission-gate' are missing.
ERROR HANDLING NOT VISIBLE, no evidence in the index.ts or package.json of error handling, recovery guidance, or error classification (retryable vs. user-fixable vs. fatal). Per pattern 'recovery-guide', error responses must tell the LLM what to do next. This server provides no guidance.
OUTPUT SCHEMAS NOT DOCUMENTED, no evidence in the provided source code that tools define their return types or response structures. Tools should document what fields are returned (e.g., token_address, price, decimals). Without documented outputs, LLMs cannot chain tool calls or extract necessary fields for subsequent operations.
NO PAGINATION SUPPORT VISIBLE, 'get_token_balances' and similar list-returning tools show no evidence of limit, offset, page, or cursor parameters in their descriptions. Baseline pattern 'paginated-result' requires accept_page/offset/limit and return total_count or next_cursor. Without this, large result sets blow context windows.
TOOL COMPOSITION UNCLEAR, mixing read-only infra tools (get_balance, get_tps) with financial operations (trade, launch token) without clear composition guidance. No evidence of tool chains (e.g., lookup token → check rug → trade) or dependencies documented.
SECRETS NOT PROTECTED, no evidence of secret injection pattern (environment variable or vault loading before tool invocation). If any tool requires API keys to DexScreener, Jupiter, Pump.fun, Rugcheck, or Solana RPC, they must be injected server-side, not exposed as parameters.