Loading ToolBench
Token holder distribution -- top holders, concentration %, whale count. On-chain due diligence for agents.
Single tool with adequate naming and schema, but description is verbose and mixes concerns. The tool name 'token_get_holder_analysis' follows verb_noun convention. Input schema is present with proper types and descriptions for both parameters. However, the description (380+ chars) violates the 10-1024 char guideline by being overly detailed, including multiple use-case warnings and cross-references that belong in agent instructions, not tool descriptions. Output schema is documented in prose but not as a formal JSON Schema structure. No error handling guidance provided. The tool lacks idempotency guarantees and does not declare read-only semantics formally.
Use this when you need to analyze token holder distribution and concentration risk. Returns holder metrics in JSON. 1. topHolders: array of top 10 holders with address, balance, percentage of supply 2. top10Concentration: percentage of total supply held by top 10 wallets 3. whaleCount: number of wallets holding >1% of supply 4. totalHolders: total unique holder count 5. isConcentrated: boolean flag if top 10 hold >50% supply (centralization risk) Example output: {"topHolders":[{"address":"0xab...cd","balance":"1250000","percent":12.5}],"top10Concentration":45.2,"whaleCount":7,"totalHolders":15420,"isConcentrated":false} Use this BEFORE buying a token to assess centralization and whale dump risk. Essential for on-chain due diligence and token research. Do NOT use for token price data -- use token_get_ohlcv_history instead. Do NOT use for token safety -- use token_check_safety instead. Do NOT use for liquidity depth -- use dex_analyze_orderbook_depth instead.
Description is verbose (380+ chars) and mixes tool purpose with cross-tool routing guidance ('Do NOT use for token price data'). Tool descriptions should focus on WHAT the tool does and WHEN to use it, not warn against other tools.
Output schema is documented in prose (example JSON in description) rather than as a formal JSON Schema structure. LLMs cannot parse prose examples reliably. Provide a structured outputSchema field.
No error handling guidance. Tool description does not explain what happens if the token address is invalid, the chain is unsupported, or the API fails. LLMs need recovery hints.
Chain parameter accepts 'base' and 'ethereum' but description does not state these are the only valid values. Should be declared as an enum constraint, not free-form string.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Tool is marked READ_ONLY in risk field but does not declare this formally via toolAnnotations (readOnlyHint). Current MCP spec supports tool annotations for clarity.