Server has 5 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short) and Zod-based input schemas with type definitions. However, descriptions lack depth, they state WHAT but not WHEN or WHY to use each tool. Parameter descriptions are present but minimal (e.g., 'Token symbol (e.g., OP, USDC)' lacks format constraints). Output schemas are not documented, responses are free-text strings, not structured objects. Error handling is generic ('Failed to retrieve X. Please try again.') with no recovery guidance. The swap-tokens tool is marked IRREVERSIBLE but has no confirmation/dry-run pattern. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions. Token info uses mock fallback data, reducing reliability. Overall: functional but below production baseline.

• Document output schemas for all tools. Return structured objects (e.g., {symbol, name, address, decimals} for get-token-info) instead of free-text strings. Include all fields needed for downstream tool chaining (e.g., token addresses for swap-tokens).
• Add confirmation/dry-run pattern to swap-tokens. Implement a 'preview_swap' tool or add a 'dry_run' boolean parameter so agents can see impact before committing irreversible trades.
• Enhance error handling with actionable recovery guidance. E.g., 'Token symbol "XYZ" not found. Available symbols: OP, USDC, ETH, DAI, WETH. Try one of these or call get-token-info to search.' Include error classification (retryable vs user-fixable).
• Add min/max bounds and format constraints to parameter descriptions. E.g., 'slippage tolerance in percentage (0.01 - 50%, default 0.5)' and 'recipient address (optional, must be valid Ethereum address)'.
• Annotate tools with readOnlyHint/destructiveHint. Mark get-* and quote tools as readOnly=true; mark swap-tokens as destructive=true. This guides agent retry logic and safety reasoning.