Loading ToolBench
Model Context Protocol server for interacting with Solana blockchain, providing tools for token operations, swapping, and wallet management
This Solana MCP server has serious definition quality issues across nearly all 12 tools. While tool names follow verb_noun conventions (createToken, mintTokens, etc.), descriptions are either completely missing or trivial (1-10 words). Input schemas exist but lack parameter descriptions in most cases. Output schemas are not documented. The codebase shows Rust contract definitions but no evidence of proper MCP tool registration with complete metadata. Critical patterns like error handling guidance, parameter constraints (enums), and composition chains are absent. The server appears to be an early-stage project that conflates Rust contract code with MCP tool definitions, the contracts are sketches (e.g., Token::default() placeholders, unimplemented Pack traits), not production-ready MCP tools.
Burn tokens from an account, reducing total supply
Create and initialize a new token with name, symbol, and decimals
Get coin data from Pump.fun for a specific mint
Get liquidity pool information from Pump.fun for a token
Get the token balance for a specified account
Get detailed information about a token including price, volume, security info, and social links
Get the total supply of a token
Missing descriptions for all parameters across all 12 tools. Parameter documentation is incomplete or absent entirely (e.g., 'percent' in pumpBuy is described only as 'Take-profit and stop-loss settings (optional)' with no detail on expected object structure).
Output schemas not documented. No tool documents what fields it returns. LLMs cannot infer downstream field names, preventing proper tool chaining (e.g., if createToken returns a 'tokenAddress' vs 'token_id' vs 'mint', the agent cannot reliably pass it to mintTokens).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Execute a token swap using Jupiter DEX aggregator
Mint tokens to a specified destination account
Buy tokens on Pump.fun DEX
Sell tokens on Pump.fun DEX
Transfer tokens between two accounts
No error handling guidance. Tools like burnTokens (destructive) and jupSwap (external DEX interaction) have no documented error cases, recovery paths, or retry semantics.
No enum constraints. Parameters accepting only specific values are documented as free-form strings (e.g., 'from' in jupSwap is described as 'Source of the swap request (api, bot, etc.)', should be an enum ["api", "bot", ...]).
Parameter 'percent' in pumpBuy has no schema definition. It is documented as 'object' with no nested field definitions ('take_profit', 'stop_loss', range, format, etc.). Agents cannot construct valid objects without explicit schema. Similarly, 'coinData' parameter lacks structure.
No parameter ranges or constraints. Numeric parameters (amount, decimals, solToBuy) lack bounds (min, max). An agent could pass amount=999999999999999 or solToBuy=0 without guidance.
No security declarations. Tools like mintTokens, burnTokens, pumpBuy (write operations with financial impact) do not declare required permissions (e.g., 'requires: wallet_control', 'write:token').
Tool composition gaps. Minting requires a token to exist (createToken must run first), but this dependency is not documented. Similarly, transferTokens requires both accounts to exist and hold token state, but source account validation is not described.
Contracts in source code are incomplete sketches. Token::default() and TokenAccount implementations return default() placeholders; Pack::unpack_from_slice and pack_into_slice are unimplemented; parse_instruction() hardcodes example values. These are not production-ready. The codebase does not show a complete, working MCP server, only Rust contract scaffolding.