Two tools with clear, domain-specific descriptions (airdrop-eligibility, hot-contracts-scanner). Both have input schemas with enums and constraints. However, output schemas are not documented in the source code provided, and parameter descriptions lack depth on expected formats and error cases. Tool names follow verb_noun convention but descriptions are moderate length (90-120 chars, below the 194-char baseline for A+ tools). No evidence of error recovery guidance or actionable error messages in the code samples.

• Document output schemas for both tools. Specify all returned fields, types, and whether results are paginated. Example: 'Returns array of {contract_address, protocol_name, interaction_count, last_activity_timestamp}'.
• Expand parameter descriptions with format constraints and examples. For address: 'Ethereum wallet address (0x-prefixed 40-char hex string, e.g. 0x1234...abcd)'. For timeframe: 'Time window for trend analysis. 1h = last hour, 4h = last 4 hours, 24h = last 24 hours.'
• Add error recovery guidance to tool descriptions. Example: 'If address is invalid, returns error with suggestion to validate format. If API rate-limited, retry after 60 seconds.'
• Expand tool descriptions to 150 - 250 chars with explicit use-case guidance. Example for airdrop-eligibility: 'Analyze wallet history to estimate airdrop eligibility. Call this before claiming airdrops to assess likelihood. Checks wallet age, balance, multi-chain activity, and Sybil resistance patterns.'
• Document pagination behavior for hot-contracts-scanner. Clarify default limit (20), max limit (100), and whether results are sorted by interaction count or recency.

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained