Server has 7 tools with complete input schemas (Zod-validated enums and strings) and detailed descriptions (avg 180 chars). Naming is action-oriented (vet_token, launch_radar, rug_check). However, output schemas are entirely undocumented, tools return raw JSON text without field definitions, forcing LLMs to parse unstructured responses. Error handling is minimal: 402 payment errors return JSON guidance, but no recovery patterns for network failures, timeouts, or invalid inputs. Parameters lack granular descriptions (e.g., 'address' has no format hint for EVM vs Solana). No tool annotations (readOnlyHint, destructiveHint). Composition is sound, each tool has one responsibility, but chaining is weak: tools return opaque text, not structured objects with IDs for downstream calls.

• Document output schemas for all tools. Define the JSON structure returned by each endpoint (e.g., vet_token returns { verdict: 'clear'|'caution'|'avoid', risk_score: number, reasons: string[] }). Return structured objects, not raw text.
• Add format hints to address parameters: 'token contract address (0x… for EVM, mint address for Solana)' is present but should be in the parameter description, not just the tool description.
• Add tool annotations: mark all tools with readOnlyHint=true since they are all read-only queries. This signals to LLMs that retries are safe.
• Implement error classification and recovery guidance. For 402 errors, suggest 'Set X402_BUYER_PK or use vet_token (free demo).' For timeouts, suggest 'Retry after 5s.' For invalid chains, return 'Invalid chain. Valid: base, eth, bsc, polygon, arbitrum, optimism, solana.'
• Add pagination to launch_radar and track_record. Accept optional limit (default 20, max 100) and offset parameters. Return total_count and next_offset in response so LLMs can iterate safely.