Server has 9 tools with basic naming and descriptions, but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (get_, list_, transfer_, call_, onramp, buy_). Descriptions are present but brief (avg ~50 chars, below 194-char baseline). Critical issue: most tools lack detailed parameter descriptions and output schema documentation. No error handling guidance visible. Schemas exist but parameter type definitions are minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is reasonable, tools are single-purpose, but parameter naming lacks consistency (e.g., 'contractAddress' vs 'toAddress' mixing camelCase).

• Add detailed parameter descriptions to all tools. For each param, specify: expected format (e.g., 'Ethereum address in 0x-prefixed hex format'), constraints (e.g., 'max 100 chars'), and examples of valid values. Reference pattern:tool-description.
• Document output schemas for all tools. Define the structure of returned objects (field names, types, required keys). E.g., get_morpho_vaults should document: [{vault_id: string, name: string, apy: number, ...}]. Reference pattern:response-shaper.
• Add error handling guidance to WRITE tools. Include recovery hints: 'If transaction fails with "insufficient balance", call erc20_balance() first.' Reference pattern:recovery-guide.
• Annotate tools with risk hints. Add destructiveHint=true to call_contract, erc20_transfer, transfer_nft, onramp, buy_openrouter_credits. Add readOnlyHint=true to get_morpho_vaults, get_onramp_assets, erc20_balance, list_nfts. Reference pattern:tool-annotations.
• Standardize parameter naming to snake_case across all tools (contract_address, to_address, asset_symbol, owner_address). Consistency reduces LLM confusion and improves tool discoverability.