Loading ToolBench
On-chain token-safety screening + safe execution for Solana trading agents. Reads token mint data from Solana to check mint/freeze authority, supply, and Token-2022 extension traps. Provides safe swap execution via Jupiter routes with Jito tips.
RugCheck AI demonstrates solid tool design with clear naming conventions (verb_noun pattern: scan_token, verify_token_safety, simulate_sell) and comprehensive parameter schemas. All 12 tools have descriptions and typed input parameters. However, output schemas are defined as Pydantic models in code but not explicitly exposed in tool registration, LLMs cannot see these schemas in the MCP protocol layer. Parameter descriptions are adequate (50-150 chars) but lack actionable constraints (e.g., no enum for verdict values, no format specs for mint addresses). Error handling is present but generic; most tools return an 'error' field without recovery guidance. Security is strong (no secrets in params, read-only operations dominate), but the single WRITE tool (execute_safe_swap) lacks confirmation/dry-run pattern.
Mint/freeze authority and Token-2022 extension report for one mint.
Liquidity depth and recent trading activity for a token (DEX market data).
Build an UNSIGNED buy transaction for a token that passed the safety screen. The agent signs and submits it. Never holds keys, never signs, never sends.
Holder concentration for a token — how much supply the largest wallets control.
Quick yes/no gate for token safety — returns True if the token passes all screens (no active authorities, no dangerous extensions, sellable, adequate liquidity).
Heuristic rug-pull risk forecast — a weighted score over observable on-chain signals (NOT a guarantee).
Output schemas defined in Pydantic models but not exposed in MCP tool registration. LLMs cannot see return types (TokenSafety, Authorities, SellCheck, etc.) in the protocol layer, forcing them to infer structure from descriptions alone.
Parameter descriptions lack actionable constraints. 'mint' is described as 'The token mint address to scan' but no format validation (Solana base58, 44 chars) is documented. LLMs cannot validate input before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Intent score — heuristic assessment of whether the token creator's on-chain behavior suggests malicious intent (rug-pull, honeypot, or pump-and-dump).
Full safety report for a token — the flagship scan combining every screen into one verdict.
Honeypot / sellability result for one mint — whether a buyer could actually sell it back.
Round-trip cost estimate for a buy-then-sell cycle on a token — reveals slippage, fees, and whether the token is a honeypot.
Age of the oldest trading pair for a token — how long it has been tradeable.
On-chain safety verdict for one SPL / Token-2022 mint, produced before you trade it.
Error handling is generic. Tools return 'error' field with messages like 'RPC unavailable' but do not guide recovery (e.g., 'Retry with a different RPC endpoint' or 'Check if mint address is valid'). Errors lack actionability.
execute_safe_swap (WRITE tool) lacks confirmation/dry-run pattern. Tool description states 'Never holds keys, never signs, never sends' but does not offer a dry-run mode or explicit confirmation step before building the transaction. Agents could accidentally build swaps.
Verdict/status fields use free-form strings ('SAFE', 'CAUTION', 'DANGER', 'UNKNOWN') instead of enums. LLMs may hallucinate invalid values like 'RISKY' or 'MODERATE'. Enum constraints would prevent this.