Server defines 9 tools with consistent naming (verb_noun pattern: get_*) and basic schemas. All tools have descriptions (avg ~40 chars, below 194-char baseline). Input schemas present but sparse: parameters lack detailed descriptions, no enums for constrained values (e.g., blockchain, page_size bounds), no output schemas documented. Error handling and recovery guidance absent. Composition is sound (single responsibility per tool), but parameter documentation is minimal, LLMs cannot infer constraints like valid blockchain names or page_size limits from names alone.

• Add enum constraints to 'blockchain' parameter across all tools. Document valid values (e.g., 'ethereum', 'polygon', 'arbitrum') in parameter description and schema.
• Document output schemas for all tools. Specify returned fields, types, and structure. E.g., get_nfts_by_owner returns {nfts: [{id, contract, owner, metadata}], total_count, next_cursor}.
• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this to retrieve all NFTs held by a specific wallet address'), WHAT it returns, and any prerequisites (e.g., 'Requires valid blockchain identifier').
• Add min/max bounds to numeric parameters. E.g., page_size: 1-100 (default 50), from_block: 0-latest, to_block: 0-latest. Document in parameter descriptions.
• Add error handling guidance to tool descriptions. E.g., 'Returns error if blockchain not supported or wallet address invalid. Call get_supported_networks() to verify blockchain availability.'