Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have names starting with action verbs (audit, check, send, swap, token-price) and descriptions present. However, descriptions are inconsistent in depth, some lack context on when to use them or prerequisites. Parameter descriptions are present but minimal (avg ~50 chars). Critical issue: send-solana and send-token lack confirmation/dry-run patterns despite being IRREVERSIBLE operations. No output schemas documented. Error handling is generic ('Failed to X: error message') without recovery guidance. Schemas use Zod types but lack explicit JSON Schema format in responses.

• Add explicit confirmation/dry-run step to send-solana and send-token. Implement a two-phase pattern: first call returns transaction details for review, second call with confirmation_token executes. Prevents accidental transfers.
• Enhance error messages with recovery guidance. E.g., 'Invalid wallet address: must be 44-character base58 string. Example: 11111111111111111111111111111111' instead of generic 'Failed to check balance'.
• Document output schemas for all tools. Include field names, types, and ranges. E.g., balanceInSOL is number with 6 decimal places, balanceInLamports is integer.
• Add parameter constraints to descriptions. E.g., amount: 'Positive number in SOL (0.001 - 1000000). Converted to lamports internally.' slippageTolerance: 'Percentage 0.1 - 50 (default 1). Swap fails if actual slippage exceeds this.'
• Implement idempotency keys for send-solana and send-token to prevent duplicate transactions on retry. Accept optional idempotency_key parameter and return transaction signature for verification.