Loading ToolBench
Scan new Solana token launches from pump.fun, Raydium, PumpSwap, Orca -- with liquidity and holder data.
Single tool 'solana_scan_new_tokens' has a detailed description (350+ chars) explaining use cases and anti-patterns, which is strong. However, the input schema lacks type information for parameters (limit and minLiquidity are declared as 'number' but lack min/max bounds, defaults are mentioned in description but not in schema). Output schema is documented in the description but not formalized in the tool definition. Parameter descriptions are present but generic. No error handling guidance or recovery paths documented. The tool name is clear and action-oriented (scan_*), but the schema completeness falls short of production standards.
Use this when you need to find newly launched tokens on Solana. Returns recent token launches from pump.fun, Raydium, PumpSwap, and Orca with market data and safety signals. 1. tokens: array of recently launched tokens sorted by recency 2. Each token contains: mint (address), name, symbol, creator, poolType (pump.fun/Raydium/PumpSwap/Orca), initialLiquidity, currentLiquidity, marketCap, holderCount, ageMinutes 3. totalFound: number of tokens matching filters 4. filters: applied filters (minLiquidity, limit) Example output: {"tokens":[{"mint":"7xKX...","name":"PEPE2","symbol":"PEPE2","creator":"5abc...","poolType":"pump.fun","initialLiquidity":5200,"currentLiquidity":12400,"marketCap":48000,"holderCount":156,"ageMinutes":23}],"totalFound":45,"filters":{"minLiquidity":1000,"limit":20}} Use this FOR discovering early-stage Solana tokens, monitoring new launches, or building sniper/scanner bots. Essential for identifying opportunities before they trend. Do NOT use for token safety checks -- use token_check_safety. Do NOT use for swap quotes -- use jupiter_get_swap_quote. Do NOT use for pool liquidity depth -- use solana_scan_pool_liquidity.
Input schema lacks numeric constraints (min/max for limit and minLiquidity). Rubric requires 'Specify minimum and maximum for numeric parameters' to prevent LLMs from passing absurd values.
Output schema documented only in description text, not formalized in tool definition. Rubric requires 'Document the output schema' as a structured definition so LLMs can reliably extract fields.
No error handling guidance. Tool description lacks recovery paths (e.g., 'If no tokens found, try increasing minLiquidity' or 'If API timeout, retry with smaller limit'). Rubric requires 'Error responses must tell the LLM what to do next.'
Parameter descriptions are minimal (e.g., 'Number of results to return' lacks guidance on typical use cases or performance implications). Rubric baseline: average param annotation is 72 chars; these are ~40 chars.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
No pagination guidance in schema. Tool accepts 'limit' but no 'offset' or 'cursor' parameter, and no 'totalFound' or 'nextCursor' in documented output. Rubric requires 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.'