The server defines 6 tools with basic descriptions and parameter schemas, but has significant quality gaps. All tools have descriptions and input schemas are visible (positive), but descriptions are often too brief (10-50 chars) or generic, parameter descriptions lack depth and constraints, and there is no documented output schema. Error handling is present but minimal, most errors are caught generically and return unstructured text rather than actionable recovery guidance. The tools are well-named with action verbs (bazi_calculate, calendar_convert, etc.), but parameter naming inconsistencies and lack of enum constraints reduce clarity. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, and all tools return formatted markdown/text rather than structured JSON, limiting downstream tool composition.

• Add structured JSON output schemas to all tools. For example, bazi_calculate should return {year_pillar: string, month_pillar: string, day_pillar: string, hour_pillar: string, complete_bazi: string, five_elements: object, na_yin: object} instead of formatted markdown. This enables reliable field extraction and downstream composition.
• Replace free-form string parameters with enums. Change 'convert_to' parameter to enum: ['lunar', 'solar']. Add enum constraints for any finite set of valid values.
• Add format validation and bounds to all parameters. 'date' params should declare format: 'YYYY-MM-DD' and validate in code. 'year' should declare minimum and maximum bounds (e.g. 1900 - 2100). 'birth_time' should validate HH:MM format with 24-hour or 12-hour AM/PM constraints.
• Expand tool descriptions to 100 - 250 characters. Include context: what the tool does, when to use it vs alternatives, and the output format. Example for calendar_convert: 'Convert a date between solar (Gregorian) and lunar (traditional Chinese) calendars. Returns both calendar systems plus zodiac and Gan Zhi information. Use this when the user provides a date in one calendar and needs the equivalent in the other.'
• Implement actionable error messages. When date parsing fails, return: 'Invalid date format. Expected YYYY-MM-DD (e.g., 2024-01-15). Got: {user_input}'. When missing a parameter, return: 'Missing required parameter: date. Please provide a date in YYYY-MM-DD format.'
• Add readOnlyHint annotation to all tools in the tool definition (this is a current MCP 2026-07-28 feature). All six tools are read-only and should signal this to the client.