Server provides 8 EVM RPC tools with basic schemas and descriptions. All tools have input schemas (via Zod) and descriptions present, but descriptions are minimal (10-50 chars, well below the 194-char baseline). Parameter descriptions exist but lack detail on formats, constraints, and valid ranges. No output schemas documented. Error handling is generic ('RPC call failed'). Tools follow EVM naming conventions but descriptions do not explain WHEN to use each tool or what distinguishes them. No parameter validation guidance (e.g., address format, block number format). Schemas are present but descriptions are too terse to guide LLM selection effectively.

• Expand tool descriptions to 100-200 chars. Example: 'eth_getBalance: Retrieve the balance of an account at a specific block. Use this to check wallet balances or verify account state. Returns balance in wei (hex string). Requires address (0x-prefixed) and optional block number (default: latest).'
• Add format constraints to parameter descriptions. For 'address': 'Ethereum address (0x-prefixed, 40 hex chars). Example: 0x1234...abcd'. For 'block': 'Block identifier: number (decimal or hex), "latest", "pending", or "earliest".'
• Document output schemas for each tool. Create a separate schema definition showing what fields the RPC response includes and their types. Example: 'eth_getBalance returns {result: string (hex wei), jsonrpc: string, id: number}'.
• Implement error classification and recovery guidance. Catch RPC errors and return: 'Invalid address format (must be 0x-prefixed, 40 hex chars). Try: search_address() or validate_address().' Distinguish retryable (timeout, rate limit) from fatal (invalid params).
• Add parameter validation with clear error messages. Validate address format, block number range, and data encoding before calling RPC. Return 'Invalid address: got "abc123", must be 0x-prefixed 40-char hex string' instead of raw RPC error.