Skip to main content
Glama

Chinese Astrology MCP Server by RoxyAPI

Calculate luck pillars - BaZi Da Yun ten-year cycle API

post_chinese_astrology_bazi_luck_pillars
Read-only

Calculate the da yun luck pillars, the ten-year periods a BaZi chart walks through after birth. Returns the direction the sequence runs, the age it begins at with the day count behind that age, each ten-year pillar with the Ten God relation its stem holds to the natal Day Master, and an optional year-by-year annual overlay. Direction follows the classical rule: a male born in a yang-stem year and a female born in a yin-stem year run forward through the sexagenary cycle, the other two combinations run backward. Built for astrology apps, life-timing features, and agents that need a reproducible forecast spine.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesBirth date in YYYY-MM-DD format. Sets the year, month and day pillars. The year pillar turns at Beginning of Spring rather than on 1 January, and the month pillar turns at each of the twelve minor solar terms rather than at a calendar month boundary.
langNoResponse language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.en
timeYesBirth time in 24-hour HH:MM:SS format. Sets the hour pillar, which is one of the four and carries the whole picture of later life and offspring. Each Earthly Branch covers two hours, so a birth within a few minutes of an odd hour can land in either. All four pillars are read in the local clock of the birth, and the day boundary is applied in that same clock; only the lunisolar calendar date itself is a world constant, fixed at UTC plus 8 so one instant has one Chinese date everywhere.
countNoHow many ten-year luck pillars to return, 1 to 12. Eight covers eighty years from the start age, which reaches past a normal lifetime for most start ages.
genderYesSubject sex, used only to pick the luck-pillar direction: a male born in a yang-stem year and a female born in a yin-stem year run forward through the sexagenary cycle, and the other two combinations run backward. It affects nothing else in the response.
compactNoSet true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
latitudeNoBirth latitude in decimal degrees. Accepted for consistency with the other birth-data endpoints and does not affect any part of a BaZi chart. Defaults to 0.
timezoneYesIANA name (e.g. "America/New_York", "Europe/London", "UTC"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. "-05:00", "+01:00"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error.
hourClockNoWhich clock the HOUR branch is read from. "clock" is civil time exactly as a birth certificate records it, which is what most calculators use and the default here. "local-mean" shifts to the mean sun over the birth longitude, a correction of up to 59 minutes at the edge of a wide time zone. "solar" adds the equation of time on top of that, up to a further 16 minutes. Both non-civil options need "longitude" in the request and return 400 without it.clock
longitudeNoBirth longitude in decimal degrees. Positive is East, negative is West. Required when hourClock is "local-mean" or "solar", which shift the hour branch to the sun over the birth place; omitting it in either case returns 400. Ignored when hourClock is "clock".
annualYearsNoHow many consecutive years the annual overlay covers, 1 to 20. Ignored unless annualFromYear is present.
dayBoundaryNoWhich instant starts the sexagenary DAY, which only matters for a birth between 23:00 and 23:59. "midnight" is the classical position of the Ming compendium San Ming Tong Hui: the day turns at 00:00 and 23:00 to 23:59 is the late zi hour of the day that is ending, so the hour stem is taken from that day. "early-zi" turns the whole day at 23:00, the practice in Hong Kong, Taiwan and much of South East Asia. "split-zi" is the compromise most software implements and the default here: the day still turns at 00:00, but the hour stem is taken from the next day. The three give three different answers for a late-evening birth and identical answers for every other birth.split-zi
yearBoundaryNoWhich instant starts the sexagenary YEAR. "li-chun" is Beginning of Spring, around 4 February, and is the classical rule every BaZi text uses, so it is the default on this endpoint. "lunar-new-year" is the folk rule people mean when they say which animal they are, and it falls between late January and late February. The two disagree for any birth in the weeks between them: 14 February 2026 is a Wood Snake year under lunar-new-year and a Fire Horse year under li-chun.li-chun
annualFromYearNoFirst Gregorian year of the annual pillar overlay. Omit it to leave annualPillars out of the response entirely. The annual pillar is the year the chart is currently walking through, read against the ten-year luck pillar underneath it.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the direction rule for forward/backward sequence, the inclusion of a day count behind the start age, and the optional annual overlay. No contradictions with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no fluff: the first states purpose and outputs, the second captures the critical direction rule, and the third gives use cases. It is front-loaded and every sentence earns its place without repeating schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description appropriately summarizes the return values at a semantic level. The 100% schema coverage handles parameter documentation, including boundary rules such as solar terms, day boundary, and timezone handling. It is complete enough for an agent to select and invoke the tool correctly, though concrete output field names are not given.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 14 parameters including defaults, formats, enums, and conditional requirements. The description mentions output semantics but adds no parameter-level meaning beyond what the schema already provides, matching the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Calculate') and a specific resource ('da yun luck pillars, the ten-year periods a BaZi chart walks through after birth'). It enumerates exactly what the endpoint returns (direction, start age, ten-year pillars, Ten God relation, annual overlay), which makes its purpose unmistakable and clearly distinguishes it from siblings like bazi_chart or bazi_day_master.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: 'Built for astrology apps, life-timing features, and agents that need a reproducible forecast spine.' It does not explicitly name alternatives or state when not to use it, so it falls short of a full 5, but the intended use case is clear enough for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: single-day almanac, month view, solar terms, lunar conversion, auspicious day search, zodiac list/profile/compatibility/daily, and BaZi chart/forecast/compatibility/day-master/luck-pillars. Even adjacent calendar and zodiac tools are separated by clear input/output differences, so an agent is unlikely to misselect.

Naming Consistency4/5

All names are snake_case with a consistent get_/post_ prefix, a chinese_astrology domain segment, and predictable subdomain grouping for calendar, zodiac, and bazi. Minor inconsistencies remain, such as zodiac_animals_id versus zodiac_id_daily and calendar_day_date versus calendar_monthly, but the overall pattern is readable and systematic.

Tool Count4/5

16 tools is one above the typical 3–15 sweet spot, but the server covers three distinct subdomains: almanac/calendar, zodiac, and BaZi. Each tool maps to a concrete feature, so the count feels slightly broad rather than bloated, though a few reference lookups could theoretically be consolidated.

Completeness5/5

The tool surface covers the main Chinese astrology workflows end to end: calendar/almanac, lunar conversion, solar terms, auspicious day selection, zodiac profiles, compatibility, daily readings, BaZi chart calculation, day master analysis, luck pillars, annual forecasts, and two-chart compatibility. There are no obvious dead ends or missing operations for the stated domain.

Resources