Chinese almanac API with Tong Shu day officers and 28 lunar mansions, plus auspicious date selection for weddings, openings and moves.
This server wraps a third-party API (RoxyAPI) and exposes 2 tools with basic descriptions and input schemas. However, critical gaps prevent production use: (1) Tool names lack action verbs, 'getAlmanacDay' and 'lookupAuspiciousDays' use camelCase instead of snake_case verb_noun convention; (2) Parameter descriptions are minimal (10-20 chars) and lack constraints, ranges, or format guidance; (3) Output schemas are completely undocumented, no field descriptions, types, or structure visible in the tool definitions; (4) No error handling guidance; (5) No pagination support despite 'lookupAuspiciousDays' returning potentially large result sets. The examples show rich structured responses (lunar dates, pillars, mansions, clash animals) but none of this is documented in the tool schema itself, forcing LLMs to infer output structure.
Get the Tong Shu reading of one day, returning the lunisolar date, the year, month and day pillars with their Na Yin, the jian chu day officer, the lunar mansion on duty, the clash animal, and the activities the officer favours or opposes.
Scan a bounded date selection window for auspicious days for a specific activity (wedding, opening, move, etc.), with optional filtering to avoid days that clash with a specific zodiac animal.
Tool names use camelCase instead of snake_case verb_noun convention. 'getAlmanacDay' should be 'get_almanac_day'; 'lookupAuspiciousDays' should be 'search_auspicious_days'. LLMs rely on consistent naming to parse intent.
Output schemas completely undocumented. Examples show complex nested structures (lunar, pillars, dayOfficer, mansion objects with multiple fields) but tool definitions provide zero schema documentation. LLMs cannot plan downstream calls or extract fields reliably.
Parameter descriptions are too brief (10-20 chars) and lack constraints. 'The date in YYYY-MM-DD format' is minimal; should specify valid range (e.g., '1900-2100'), whether past/future dates are allowed, and timezone assumptions. 'The activity type' lacks enum values, LLM must guess valid activities.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
'lookupAuspiciousDays' returns potentially large result sets (46 days in example window) with no pagination, limit, or offset parameters. Large responses blow context windows and degrade LLM reasoning. No guidance on result limits.
No error handling guidance. Tool definitions provide no recovery hints for common failures (invalid date format, date out of range, no auspicious days found, API timeout). LLM cannot self-correct or plan fallbacks.