All 5 tools have complete, well-structured input schemas with proper type definitions and comprehensive parameter descriptions. Tool names follow verb_noun convention (saju_chart, ohaeng_balance, gyeokguk, eumyang_johu, yongshin_candidates). Descriptions are detailed (150 - 250 chars) and explain WHAT the tool does, WHEN to use it, and domain context (Korean Saju terminology). All parameters are typed and described. However, output schemas are NOT documented, the code forwards backend JSON responses without declaring the structure LLMs should expect. Error handling is minimal (only 'Unknown tool' rejection visible). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only operations.

• Document output schemas for each tool. Declare the JSON structure returned by /try/panels (e.g., { pillars: [...], elements: {...}, gyeokguk: {...} }) so LLMs know what fields to extract and how to chain results.
• Add readOnlyHint: true to all 5 tool definitions in ListToolsRequestSchema response. This signals to agents that these tools are safe to call without side effects.
• Implement input validation in CallToolRequestSchema handler: validate birth date format (12 digits, valid YYYYMMDDHHMM), gender enum (0 or 1), and optional numeric ranges (loc, option1, option2). Return actionable error messages like 'Invalid birth date: expected YYYYMMDDHHMM (e.g., 199001151030), got "1990-01-15 10:30"'.
• Wrap backend API errors with recovery guidance. E.g., if /try/panels returns 400, parse the error and return 'Invalid birth date or gender. Ensure birth is 12 digits YYYYMMDDHHMM and gender is 0 (female) or 1 (male).' If timeout, return 'Backend service slow. Retry in 5 seconds.'
• Add per-tool schema variants or document which parameters are optional/recommended for each tool. E.g., yongshin_candidates may not use 'name', clarify in tool description or provide tool-specific input schemas.