Loading ToolBench
Solana token intelligence and analytics MCP server providing wallet balance checks, token information, trending tokens, token holders analysis, and yield opportunities
tokenMCP exhibits significant quality gaps across naming, descriptions, schemas, and error handling. Tool names lack consistent verb-first convention (GetSolanaTokenInfo violates verb_noun pattern). Descriptions are minimal and lack WHEN-to-use context. Input schemas present but parameter descriptions are sparse. Output schemas are completely undocumented. Error handling is absent, no recovery guidance, no actionable error messages. The server mixes .js compiled output with .ts source, creating maintenance ambiguity. No pagination despite tools returning potentially large result sets (e.g., getTrendingTokens, getTopTokenHolders). No validation of input constraints (e.g., count 1-50 is declared but not validated in code).
Get Solana token relevant information using the contract address
get balance of a wallet
Get top yield opportunities on Solana across lending and farming protocols
Get top N holders of a Solana token by contract address, along with their percentage ownership
Get top 10 Solana tokens by 24h volume using Birdeye
Inconsistent tool naming convention, GetSolanaTokenInfo violates verb_noun pattern (camelCase with capital G instead of verb_noun snake_case). LLMs expect action verbs at the start; inconsistent casing increases cognitive load during tool selection.
Output schemas completely undocumented. Tools return free-text strings or objects with no schema documentation. LLMs cannot infer what fields to expect, cannot chain tools reliably, and cannot extract structured data for downstream operations. For example, getTrendingTokens and getBestYields return complex objects but no schema is visible.
No error handling or recovery guidance. Code catches exceptions but returns generic error strings like 'Failed to retrieve wallet address'. Does not classify errors as retryable, user-fixable, or fatal. Does not provide actionable next steps (e.g., 'Try a valid Solana address'). Violates recovery-guide pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Parameter descriptions incomplete or missing. getTrendingTokens has no input parameters declared but no documentation of what it returns or when to use it. getTopTokenHolders declares count (1-50) but no validation code visible; constraint is metadata-only. Descriptions should state format, range, and validation rules explicitly.
No pagination support for large result sets. getTrendingTokens returns 'top 10' but no page/offset/limit parameters. getTopTokenHolders accepts count but no way to retrieve holders beyond top N. Large results without pagination risk context window exhaustion and degrade LLM reasoning.
Tool descriptions lack WHEN-to-use context. 'Get top yield opportunities' does not explain whether this is for finding DeFi pools, comparing APYs, or planning capital allocation. LLMs need explicit guidance on when to select each tool vs. alternatives. Descriptions should be 50-200 characters with clear intent.
Source code organization ambiguous. Both src/index.js and src/index.ts exist; package.json 'main' points to build/index.js but source files are .ts. Maintenance risk: unclear which file is canonical, git diffs may show both, tooling confusion.
No input validation or constraint enforcement in code. getTopTokenHolders declares count 1-50 but no runtime check visible. getBalance does not validate Solana address format before API call (catches error after). Early validation with clear error messages prevents wasted API calls and guides LLM self-correction.
API keys and RPC URLs exposed in code as environment variables checked at startup. While env vars are better than hardcoded secrets, no documentation exists for how to safely configure them, no mention of secret rotation, and error message on missing keys leaks which APIs are required to a potential attacker.