Loading ToolBench
Check wallet eligibility for active crypto airdrops -- token, value, deadline, claim URL via Etherscan.
Single tool with complete input schema and detailed description. Input schema properly typed with required fields. Output schema present but vague (array items lack property definitions). Description is comprehensive (500+ chars) with use-case guidance and anti-patterns, exceeding baseline (194 chars avg). However, output schema uses generic 'object' types for array items without specifying airdrop structure, violating pattern:response-shaper. No error handling guidance or recovery paths documented. Tool name 'crypto_check_airdrops' is verb-noun compliant but lacks clarity on what 'check' returns (eligible vs potential vs both). Duplicate route definitions (GET and POST) create confusion about canonical tool identity.
Use this when you need to check if a wallet address is eligible for crypto airdrops. Scans wallet interactions against known airdrop contracts and returns eligible claims. 1. eligible: array of airdrops the wallet qualifies for 2. Each airdrop contains: tokenName, tokenSymbol, estimatedValueUsd, deadline (ISO date), claimUrl, status (claimable/claimed/expired) 3. totalEligible: number of eligible airdrops found 4. totalEstimatedValue: combined estimated USD value of all eligible airdrops 5. walletAddress: the address checked 6. checkedAt: timestamp of the check Example output: {"eligible":[{"tokenName":"LayerZero","tokenSymbol":"ZRO","estimatedValueUsd":450,"deadline":"2026-06-30T00:00:00Z","claimUrl":"https://claim.layerzero.network","status":"claimable"}],"totalEligible":3,"totalEstimatedValue":1250,"walletAddress":"0x742d...","checkedAt":"2026-04-13T12:00:00Z"} Use this FOR discovering unclaimed airdrops, monitoring multiple wallets for eligibility, or building airdrop farming dashboards. Do NOT use for wallet balance -- use wallet_get_portfolio. Do NOT use for token safety -- use token_check_safety. Do NOT use for NFT data -- use nft_get_collection_data.
Output schema uses generic 'object' type for array items without property definitions. Airdrop objects lack documented fields (tokenName, tokenSymbol, estimatedValueUsd, deadline, claimUrl, status mentioned in description but not in schema).
No error handling guidance. Description lacks recovery paths for invalid addresses, rate limits, or API failures. LLM cannot determine if errors are retryable or user-fixable.
Duplicate tool registration (GET /api/check and POST /api/check) with identical toolName creates ambiguity. MCP clients cannot distinguish which route to invoke.
Output schema declares 'eligible' and 'potential' as required but description example shows only 'eligible' array. Mismatch between schema and documented behavior.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Address parameter accepts only Ethereum (0x...) but description claims 'wallet address' without specifying chain. No validation guidance for malformed addresses.