BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Scored across 16 tools
Each tool targets a distinct resource and action combination with no overlap. For example, get_chinese_astrology_zodiac_animals returns all animals while get_chinese_astrology_zodiac_animals_id returns details for one, and the various calendar tools cover day, month, solar terms, and lunar conversion without ambiguity.
All 16 tools follow a consistent verb_noun pattern with snake_case and a uniform prefix 'get_chinese_astrology_' or 'post_chinese_astrology_'. The naming is highly predictable and self-describing.
With 16 tools covering distinct aspects of Chinese astrology (calendar, zodiac, BaZi, elements), the count is well-scoped for the domain. Each tool earns its place without redundancy or excessive granularity.
The tool set provides comprehensive coverage: CRUD-like operations for zodiac and calendar data, multiple BaZi analysis endpoints, compatibility checks, and date conversions. There are no obvious gaps for the stated purpose.
Return the full almanac reading of one day: its lunisolar date, the year, month and day pillars with their Na Yin, the day officer from the twelve jian chu sequence, the lunar mansion on duty, the zodiac animal the day clashes with, and the activities the officer favours or opposes. The day officer is the layer a printed almanac reaches its verdict from first, and the response says exactly what it rules on rather than reducing the day to a single score. The year and month pillars here are attributed by whole days, which is what an almanac prints: the day a solar term falls on belongs to the new period for its whole length, however late in the day the term arrives. Built for date pickers, daily calendar widgets, and wedding or opening date tools.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Gregorian date in YYYY-MM-DD format, evaluated at the reference meridian. Years 1900 to 2100. | |
| lang | No | Response 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 |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| lunar | Yes | |
| avoids | Yes | |
| favours | Yes | |
| mansion | Yes | |
| dayPillar | Yes | |
| dayOfficer | Yes | |
| yearPillar | Yes | |
| clashAnimal | Yes | |
| monthPillar | Yes | |
| clashAnimalLocalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given that annotations already declare readOnlyHint=true and destructiveHint=false, the safety profile is covered. The description adds genuinely valuable behavior beyond that: it discloses that year/month pillars are attributed by whole days regardless of when a solar term arrives, and that the response 'says exactly what it rules on rather than reducing the day to a single score' — both non-obvious behaviors an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four dense sentences that each earn their place: return contents, the day officer's interpretive role, the pillar-attribution rule, and target use cases. It is front-loaded with the output list and contains no filler, though it runs slightly long due to the inherent complexity of the domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations covering safety, and 100% parameter coverage, the description only needs to resolve domain ambiguities — and it does, explaining the solar-term attribution rule and the day officer's primacy. The tool is complex, but the only notable gap is the absence of explicit sibling routing; everything an agent needs to invoke it correctly is otherwise present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents date format, the lang enum with fallback behavior, and the compact columnar shape. The description adds no parameter-specific semantics beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Return the full almanac reading of one day') and enumerates the exact contents (lunisolar date, pillars with Na Yin, day officer, lunar mansion, clash animal, favoured/opposed activities). The 'one day' scope clearly differentiates it from the monthly and solar-terms-year calendar siblings in the tool list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence states concrete use cases: 'Built for date pickers, daily calendar widgets, and wedding or opening date tools.' This gives clear application context, but the description never names alternatives or states when not to use this tool (e.g., for a monthly range), so explicit exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return every day of one Gregorian month of the Chinese almanac with its lunisolar date, its three pillars, its day officer, its lunar mansion and its clash animal, plus the solar terms that fall inside the month. This is the month view a calendar widget renders in one call rather than thirty one. Omit the year and month to get the month in progress. Built for calendar UIs, almanac pages, and planning tools that show a whole month at a glance.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| year | No | Gregorian year, 1900 to 2100. Defaults to the current UTC year when omitted, together with month. | |
| month | No | Gregorian month, 1 to 12. Defaults to the current UTC month when omitted, together with year. | |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| year | Yes | |
| month | Yes | |
| total | Yes | |
| solarTerms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavior beyond that: it returns every day in the month, includes solar terms falling in the month, and defaults to the month in progress when year and month are omitted. No hidden destructive or state-changing behavior is suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core return behavior and is appropriately sized. The last sentence about being built for calendar UIs and almanac pages is somewhat redundant with the earlier month-view framing, but it does not waste much space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover the safety profile, the description is complete for invocation: it defines scope, default behavior, target use cases, and distinguishes the month view from the day-level alternative. No critical information needed to select or call the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description's only parameter-related statement, 'Omit the year and month to get the month in progress,' largely repeats the schema's stated defaults, adding no new semantic value beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return every day of one Gregorian month of the Chinese almanac' and enumerates the included data fields. It clearly differentiates itself from the single-day and solar-terms siblings by framing itself as the month view rendered in one call rather than thirty one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is built for calendar UIs, almanac pages, and planning tools that show a whole month at a glance, and it contrasts with making thirty-one separate calls. It does not explicitly name the day-level sibling as the alternative, so it falls short of the strongest explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all 24 solar terms of a year as astronomical instants rather than dates, each computed from the moment the sun reaches its exact apparent longitude at 15 degree steps. The year is the SOLAR year, which opens at Li Chun in early February, so Minor Cold and Major Cold, the last two terms, are dated in the January of the following Gregorian year. Every instant is returned twice, once in UTC and once at the UTC+8 reference meridian the Chinese calendar is defined on. Built for calendar apps, festival scheduling, and any BaZi feature that has to place a birth on the correct side of a term boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| year | Yes | Solar year, 1900 to 2100. The year opens at Li Chun rather than on 1 January, so its last two terms fall in the following January. | |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| terms | Yes | |
| total | Yes | |
| referenceOffset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, and the description adds meaningful behavior beyond that: instants are computed from exact solar longitude, the year opens at Li Chun, the last two terms fall in the following Gregorian January, and every instant is returned in both UTC and UTC+8. This gives an agent a strong model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core differentiator and is reasonably concise. The final use-case sentence adds useful context, but some content, such as the solar-year explanation, partially repeats the schema and could be trimmed without losing essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description is complete for invocation: it explains what is returned, the unusual year boundary, the dual timezone representation, and the intended domain. An agent has everything needed to decide to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces the meaning of 'year' with the solar-year convention, but this largely duplicates the schema's parameter description rather than adding new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return all 24 solar terms of a year as astronomical instants rather than dates.' It clearly distinguishes this tool from the calendar day/month siblings by emphasizing exact instants, 15-degree apparent longitude steps, and the solar-year convention opening at Li Chun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit intended use cases: 'Built for calendar apps, festival scheduling, and any BaZi feature that has to place a birth on the correct side of a term boundary.' It does not explicitly name alternatives or state when not to use this tool, so it falls slightly short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the five phases of Wu Xing with the Chinese character, the season and direction each governs, the Heavenly Stems and Earthly Branches that carry it, and both of the cycles that connect them. The generating cycle and the controlling cycle are returned as ordered rings as well as on each phase, so a caller can render either without deriving it. This is the one place the five phase vocabulary is defined: BaZi charts, Na Yin, zodiac element variants and every feng shui star reuse these identifiers rather than restating them.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| limit | No | Maximum items to return per page. Range: 1-5, default 5. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| elements | Yes | |
| generatingCycle | Yes | |
| controllingCycle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds real behavioral detail: generating and controlling cycles are returned both as ordered rings and per phase, so a caller can render without deriving; the uniqueness of the vocabulary is useful context. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first enumerates contents, the second explains the cycle representation and its benefit, the third gives selection context. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and annotations covering the read-only safety profile, the description covers every behavioral aspect an agent needs: itemized return content, cycle representation, and the tool's role in the API family. The optional parameters are all documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lang, limit, offset, and compact; the baseline of 3 applies. The description itself adds nothing parameter-specific, but it does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and resource ('the five phases of Wu Xing') with a detailed list of returned attributes, plus the two cycles. The final sentence differentiates it from all sibling tools by describing it as the canonical definition point for five-phase identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells an agent this is the single source for five-phase vocabulary, so it should be selected over sibling tools when canonical element identifiers or cycles are needed. It does not list explicit exclusions or compare directly to named siblings, stopping one step short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all twelve Chinese zodiac animals in cycle order, from Rat through Pig. Each entry returns the machine id, the Chinese character and tone-marked pinyin for the animal, its Earthly Branch, the fixed Five Element phase and yin or yang polarity of that branch, and a set of trait keywords. Built for sign pickers, zodiac cards and compatibility widgets that need the whole set in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| limit | No | Maximum items to return per page. Range: 1-12, default 12. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| animals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral detail beyond that: the cycle ordering, the specific fields returned per animal (machine id, Chinese character, pinyin, Earthly Branch, Five Element, polarity, keywords), and the single-call intent. It does not disclose pagination behavior, but the schema covers the pagination parameters and the output schema covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence front-loads the core action and result fields; the second sentence adds the use-case context that helps an agent decide when to call this tool. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only catalogue tool with zero required parameters, full schema descriptions, a rich output schema, and safe annotations, the description is complete. It explains what the tool returns, the order, the use case, and the fields, leaving nothing necessary for correct invocation unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters (lang, limit, offset, compact) with types, ranges, defaults, and examples. The description adds no additional parameter-level meaning, which is acceptable since the baseline of 3 applies when the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve all twelve Chinese zodiac animals') and names the exact resource and ordering ('in cycle order, from Rat through Pig'). It also distinguishes itself from sibling tools by explicitly targeting consumers that need the whole set in one call, rather than a single animal or a compatibility pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the intended use case: sign pickers, zodiac cards, and compatibility widgets that need the entire catalogue at once. It does not explicitly name sibling alternatives or exclusion criteria, but the 'whole set in one call' framing provides enough context for an agent to choose this over single-animal or compatibility-focused tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the complete profile of one Chinese zodiac animal: character summary, strengths, weaknesses, trait keywords, the double-hour its Earthly Branch governs, and its five element variants with the Gregorian years that carry each one. Also returns the four classical branch relationships, the three-harmony trine it belongs to, its six-harmony secret friend, its clashing opposite and its harming partner. Built for sign detail pages and compatibility features.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Animal id, case-insensitive and punctuation-insensitive. One of rat, ox, tiger, rabbit, dragon, snake, horse, goat, monkey, rooster, dog, pig. The sheep and the ram are the same animal as the goat and resolve to goat. | |
| lang | No | Response 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 |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| hours | Yes | |
| trine | Yes | |
| branch | Yes | |
| pinyin | Yes | |
| traits | Yes | |
| chinese | Yes | |
| element | Yes | |
| summary | Yes | |
| polarity | Yes | |
| strengths | Yes | |
| weaknesses | Yes | |
| harmPartner | Yes | |
| clashPartner | Yes | |
| secretFriend | Yes | |
| nameLocalized | No | |
| elementVariants | Yes | |
| elementLocalized | No | |
| compatibilitySummary | Yes |
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 known. The description reinforces this with 'Retrieve' and enumerates the returned data, adding modest context but no new behavioral disclosures about rate limits, auth, or side effects. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with no filler. It front-loads the core action, then lists the major returned data in a readable sequence, and ends with a practical use-case sentence. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich output schema, 100% parameter coverage, and annotations already declaring read-only safety, the description is complete enough for an agent to select and invoke the tool correctly. It covers what the tool returns, why it exists, and its intended use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents id, lang, and compact thoroughly. The description adds context about the animal profile but does not describe parameter behavior such as lang fallback or compact's lossless token savings; the schema carries that load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Retrieve the complete profile of one Chinese zodiac animal,' and enumerates the exact content domains. This clearly distinguishes it from siblings like get_chinese_astrology_zodiac_animals (all animals) and get_chinese_astrology_zodiac_compatibility_sign1_sign2 (comparison between two signs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use context with 'Built for sign detail pages and compatibility features,' which tells the agent when this single-animal profile tool is appropriate. It does not explicitly name alternative tools or state when not to use it, but the intended context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score and explain the relationship between two Chinese zodiac animals from the classical branch relations rather than from a lookup table of opinions. Returns which of the six relations the pair stands in, a score out of 100, the phase the two branches combine into where they combine at all, and a composed reading with strengths, frictions and advice. The six relations are mutually exclusive by construction, so exactly one applies to any pair. Built for matchmaking features, relationship reports and compatibility widgets.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| sign1 | Yes | First animal id, case-insensitive. One of rat, ox, tiger, rabbit, dragon, snake, horse, goat, monkey, rooster, dog, pig. | |
| sign2 | Yes | Second animal id, case-insensitive. The relation is symmetric, so swapping the two returns the same relationship and the same score, with the reading written from the first sign point of view. | |
| compact | No | Set 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. |
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| signs | Yes | |
| advice | Yes | |
| summary | Yes | |
| verdict | Yes | |
| frictions | Yes | |
| strengths | Yes | |
| relationship | Yes | |
| sharedElement | No | |
| relationshipName | Yes | |
| relationshipPinyin | Yes | |
| relationshipChinese | Yes | |
| sharedElementLocalized | No | |
| relationshipNameLocalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context: the six relations are mutually exclusive, exactly one applies, and results are computed from classical branch relations rather than opinion lookup tables. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The action and return value are front-loaded, the behavioral guarantee about mutually exclusive relations earns its place, and the intended use cases are stated compactly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only compatibility tool with an output schema, the description covers what it does, what it returns, how it computes results, and when to use it. The symmetric-relation note lives in the schema, and the output schema handles return details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 sign1, sign2, lang, and compact. The tool description does not add parameter-level detail, but that is not necessary here; it remains at the baseline 3 because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Score and explain'), a specific resource ('relationship between two Chinese zodiac animals'), and a distinctive method ('classical branch relations rather than from a lookup table of opinions'). It also enumerates concrete outputs, so an agent can distinguish it from sibling bazi compatibility and zodiac animal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intended contexts: 'matchmaking features, relationship reports and compatibility widgets'. It does not explicitly name alternatives or say when not to use this tool, but the use-case framing is enough for typical selection among the zodiac-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the daily reading for one Chinese zodiac animal, built from the sexagenary day pillar rather than from a rotation of stock text. The day carries its own Earthly Branch, that branch stands in exactly one of six classical relations to the requested sign, and the reading is that relation applied to the sign temperament. Returns the day pillar, the relation, an energy rating, overview, love and career guidance, advice, and the sexagenary year in force with its Ben Ming Nian flag. Content is fixed for a given date and rolls over at midnight, by default UTC.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Animal id, case-insensitive. One of rat, ox, tiger, rabbit, dragon, snake, horse, goat, monkey, rooster, dog, pig. | |
| date | No | Reading date in YYYY-MM-DD format. Past and future dates are both supported, for editorial scheduling and backfill. Defaults to the current day in the timezone parameter. | |
| lang | No | Response 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 |
| compact | No | Set 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. | |
| timezone | No | Selects which day counts as current when date is omitted. Defaults to UTC, so the reading rolls over at 00:00 UTC each day. Pass the timezone of the end user to roll over on their local clock instead. Ignored when date is set. Accepts an IANA name (e.g. "America/New_York"), decimal hours (e.g. 5.5 for IST), or a fixed UTC offset (e.g. "-05:00"). |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| love | Yes | |
| year | Yes | |
| advice | Yes | |
| animal | Yes | |
| career | Yes | |
| overview | Yes | |
| dayPillar | Yes | |
| benMingNian | Yes | |
| energyRating | Yes | |
| relationship | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context beyond that: the reading is generated from the day pillar's Earthly Branch and its classical relation to the requested sign, content is fixed for a given date, and it rolls over at midnight UTC by default. This prevents an agent from assuming the text is static, randomized, or mutable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it states the action, the underlying method, the output fields, and the rollover behavior. It is front-loaded with the core purpose and does not include filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all parameters are fully described in the input schema, the description is complete enough for an agent to call the tool correctly. It adds the key conceptual context an agent cannot infer from schema alone: the day-pillar mechanism, the relation-based generation, and the deterministic rollover behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters with examples, defaults, formats, and enums. The description reinforces the roles of date and timezone ('fixed for a given date', 'by default UTC') but does not add meaningfully new parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the daily reading for one Chinese zodiac animal.' It further differentiates itself from static or generic horoscope tools by explaining that content is built from the sexagenary day pillar rather than rotation of stock text, which makes its scope and method unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when this tool is relevant: daily, per-animal, date-fixed readings that roll over at midnight UTC. However, it does not explicitly name alternatives or state when to use a sibling like get_chinese_astrology_zodiac_animals_id instead, so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one Gregorian year against a natal BaZi chart. Returns the annual pillar for that year, the Ten God relation its stem holds to the natal Day Master, the same reading for the hidden stem of its branch, how the annual branch stands to the natal year branch including the ben ming nian return of the birth animal, and every combination, clash, harm and punishment the annual pillar forms with each of the four natal pillars. Built for yearly horoscope features, timing tools, and agents that need a year read against a specific chart rather than against an animal sign.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth 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. | |
| lang | No | Response 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 |
| time | Yes | Birth 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. | |
| year | Yes | Gregorian year to read against the natal chart. The annual pillar for that year is resolved under the same year boundary the request selected, so a li-chun reading and a lunar-new-year reading of the same calendar year can differ. | |
| compact | No | Set 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. | |
| latitude | No | Birth 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. | |
| timezone | Yes | IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error. | |
| hourClock | No | Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. "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 |
| longitude | No | Birth 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". | |
| dayBoundary | No | Which 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 |
| yearBoundary | No | Which 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 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| animal | Yes | |
| tenGod | Yes | |
| summary | Yes | |
| birthData | Yes | |
| benMingNian | Yes | |
| conventions | Yes | |
| annualPillar | Yes | |
| branchTenGod | Yes | |
| interactions | Yes | |
| animalLocalized | No | |
| yearBranchRelation | Yes | |
| yearBranchRelationMeaning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a safe read (readOnlyHint=true, destructiveHint=false), and the description adds substantive behavioral detail about the computed outputs and the caveats around year-boundary resolution. It stops short of noting latency, rate limits, or error behaviour beyond what the schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and then the return payload; the long enumeration of outputs is dense but each item is decision-relevant. Slightly heavy for a definition whose schema already documents inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters at full schema coverage and an output schema present, the description need not re-document fields; it still usefully frames the domain (natal chart vs animal sign) and output shape. Nothing critical is missing, though explicit sibling routing would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter already carries a rich, self-contained description (timezone resolution, dayBoundary, yearBoundary, hourClock). The description text itself contributes essentially no parameter guidance, so the baseline 3 applies rather than a penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource ('Read one Gregorian year against a natal BaZi chart') and the rest enumerates exactly what is returned (annual pillar, Ten God relation, branch relations, combinations/clashes/harms/punishments). It also differentiates from the zodiac-sign siblings by noting it reads against 'a specific chart rather than against an animal sign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear intended contexts ('yearly horoscope features, timing tools') and one exclusion (not an animal-sign reading), which routes the agent away from the zodiac_sign tools. It does not, however, name or contrast with the closest sibling, post_chinese_astrology_bazi_chart, or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a complete BaZi chart, the Four Pillars of Destiny, from a birth moment. Returns the year, month, day and hour pillars with every Heavenly Stem and Earthly Branch, the stems hidden inside each branch, the Ten God relation each one holds to the Day Master, the Na Yin sound element of each pair, the five-element balance across the chart, and the combinations and clashes running between the pillars. The day boundary, year boundary and hour clock are all selectable and the applied conventions come back on every response, so a chart is self-describing. Built for astrology apps, matchmaking services, and agents that need a Four Pillars reading they can reproduce.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth 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. | |
| lang | No | Response 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 |
| time | Yes | Birth 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. | |
| compact | No | Set 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. | |
| latitude | No | Birth 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. | |
| timezone | Yes | IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error. | |
| hourClock | No | Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. "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 |
| longitude | No | Birth 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". | |
| dayBoundary | No | Which 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 |
| yearBoundary | No | Which 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 |
| Name | Required | Description |
|---|---|---|
| pillars | Yes | |
| summary | Yes | |
| birthData | Yes | |
| dayMaster | Yes | |
| conventions | Yes | |
| fiveElements | Yes | |
| interactions | Yes | |
| zodiacAnimal | Yes | |
| zodiacAnimalLocalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the day-boundary, year-boundary and hour-clock conventions are selectable and the applied conventions are echoed on every response, making charts self-describing and reproducible. It still omits auth/rate-limit behavior, hence not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentences are front-loaded and dense with real information (returned fields, selectable conventions). The closing 'Built for astrology apps...' sentence is audience marketing that does little for an invoking agent, and the return-field enumeration partly duplicates the output schema, so it is efficient but not waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, rich annotations, and 100% schema coverage, the definition is close to complete: it explains the convention choices, the self-describing response, and (via the schema) the error behavior. The only real gap is the absence of any sibling routing or prerequisite/permission context for a complex ten-parameter call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all ten parameters including the enums and their trade-offs. The description restates that the boundary and clock selectors exist but adds no format, unit or default detail the schema does not already carry; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a precise verb+resource ('Calculate a complete BaZi chart, the Four Pillars of Destiny') and scopes it to a birth moment. The enumeration of what comes back (all four pillars, hidden stems, Ten Gods, Na Yin, element balance, combinations/clashes) makes clear this is the whole-chart tool rather than the sibling day-master or luck-pillar endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the audience line ('astrology apps, matchmaking services, and agents...') and the 'complete chart' framing, but there is no explicit when-to-use/when-not guidance and none of the sibling BaZi tools are named as alternatives. An agent can infer the fit but receives no routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two BaZi charts pillar by pillar, the Chinese astrology reading of how two people match. Returns both resolved charts, how the two Day Masters stand to each other on the five-phase cycle, and every combination, clash, harm and punishment that crosses between them, each naming the two positions it joins. A tallied score summarises the balance and the interaction list behind it is returned in full, so a caller that disagrees with the weighting can recompute its own. Built for matchmaking products, relationship features, and agents that need a defensible two-chart reading.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| compact | No | Set 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. | |
| personA | Yes | Birth moment of the first person. Each subject carries its own school switches, so two charts built under different conventions can still be compared. | |
| personB | Yes | Birth moment of the second person. |
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| personA | Yes | |
| personB | Yes | |
| summary | Yes | |
| interactions | Yes | |
| harmoniousCount | Yes | |
| challengingCount | Yes | |
| dayMasterRelation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, non-destructive operation, so the bar is lower. The description adds genuinely useful behavioral context beyond that: the score is a weighting choice and the full interaction list is returned so a caller can recompute independently, which tells the agent how much to trust the tallied result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action and return shape are front-loaded in the first two sentences, with the audience sentence last. It is a dense but unified paragraph with little wasted text, though the closing positioning sentence is the most expendable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with nested birth-data objects and many convention enums, the description adequately conveys the comparison output (resolved charts, Day Master relation, cross-chart interactions, score). With an output schema present it needn't enumerate returns, yet it still does so usefully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the nested personA/personB objects are exhaustively documented, so the schema carries the parameter burden. The description adds no parameter-level meaning beyond implying two symmetric subject blocks, which is the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Compare two BaZi charts pillar by pillar,' and immediately frames it as a two-person matchmaking reading. The two-chart scope inherently separates it from the sibling single-chart post_chinese_astrology_bazi_chart, though that sibling is never named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when it applies ('matchmaking products, relationship features, and agents that need a defensible two-chart reading'). It offers no explicit when-not or routing to alternatives such as post_chinese_astrology_bazi_chart for single-person readings, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess how well the Day Master is supported by the rest of a BaZi chart, and which of the five elements help it. Uses the classical three-factor method: whether the birth month season backs the Day Master element, whether any branch stores a root for it, and whether the other stems and the branches outside the month help or spend it. Returns the verdict, an auditable score with each factor contribution, the seasonal state, the root count, the element headcount, and the favorable and unfavorable element lists that follow from the verdict. Built for chart readers, remedy features, and agents that need the usable half of a Four Pillars reading.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth 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. | |
| lang | No | Response 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 |
| time | Yes | Birth 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. | |
| compact | No | Set 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. | |
| latitude | No | Birth 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. | |
| timezone | Yes | IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error. | |
| hourClock | No | Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. "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 |
| longitude | No | Birth 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". | |
| dayBoundary | No | Which 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 |
| yearBoundary | No | Which 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 |
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| factors | Yes | |
| summary | Yes | |
| verdict | Yes | |
| birthData | Yes | |
| dayMaster | Yes | |
| rootCount | Yes | |
| conventions | Yes | |
| fiveElements | Yes | |
| seasonalState | Yes | |
| favorableElements | Yes | |
| unfavorableElements | Yes | |
| seasonalStateChinese | Yes | |
| seasonalStateMeaning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety bar is low. The description goes further by disclosing the computation method (season, root, other stems/branches) and enumerating the verdict, per-factor score contributions, seasonal state, root count, and element lists that come back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose and method before the return contents and audience. Dense but every clause carries information; the trailing audience sentence is the only mildly expendable part.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a ten-parameter domain tool with an output schema and fully documented schema fields, the description is adequate: it explains what is computed and what is returned. It relies entirely on the schema for parameter caveats, which is acceptable given 100% coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all ten parameters in depth. The description adds no parameter-level guidance (no mention of date/time/timezone, hourClock, dayBoundary, or the longitude dependency), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: assess Day Master support and identify favorable/unfavorable elements, with the three-factor method spelled out. It is clearly a sub-analysis of a BaZi reading rather than a full chart, but it never names the sibling tools (e.g. post_chinese_astrology_bazi_chart) that would distinguish it explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The audience line ('built for chart readers, remedy features, and agents that need the usable half of a Four Pillars reading') implies when this is useful, but there is no explicit when-to-use/when-not and no routing to alternatives among the many bazi siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth 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. | |
| lang | No | Response 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 |
| time | Yes | Birth 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. | |
| count | No | How 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. | |
| gender | Yes | Subject 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. | |
| compact | No | Set 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. | |
| latitude | No | Birth 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. | |
| timezone | Yes | IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error. | |
| hourClock | No | Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. "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 |
| longitude | No | Birth 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". | |
| annualYears | No | How many consecutive years the annual overlay covers, 1 to 20. Ignored unless annualFromYear is present. | |
| dayBoundary | No | Which 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 |
| yearBoundary | No | Which 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 |
| annualFromYear | No | First 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. |
| Name | Required | Description |
|---|---|---|
| gender | Yes | |
| summary | Yes | |
| startAge | Yes | |
| birthData | Yes | |
| direction | Yes | |
| daysToTerm | Yes | |
| conventions | Yes | |
| luckPillars | Yes | |
| boundaryTerm | Yes | |
| annualPillars | No | |
| startAgeMonths | Yes | |
| boundaryTermName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true/destructiveHint=false, so the safety profile is covered; the description adds real behavioral context — the forward/backward direction rule keyed to gender and year stem, and the composition of each returned pillar. It does not add error or rate-limit behavior, but the schema already documents 400 cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then the return shape, then the direction rule and audience. Three sentences with no filler, though the classical-rule sentence is fairly long and largely duplicates domain context the schema carries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, annotations, and 100% parameter coverage, the description only needs to frame the domain. It does that well and is self-contained (birth data is requested directly), though it omits any routing note for how this relates to the annual-forecast sibling it partially overlaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 14 richly documented parameters, so the baseline is 3. The description restates the classical gender/year-stem direction rule that the gender param's own schema already explains, adding no syntax or format detail beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource ("calculate the da yun luck pillars, the ten-year periods a BaZi chart walks through") and enumerates the distinct output it produces — direction, start age, per-pillar Ten God relation, and optional annual overlay. An agent can tell this apart from bazi_chart or bazi_annual_forecast by what it computes, even without an explicit negative comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence gives an audience ("astrology apps, life-timing features, and agents that need a reproducible forecast spine") but never states when to choose this over the sibling bazi_annual_forecast or bazi_chart, nor any prerequisite. Usage is implied by purpose rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a date range for the days a chosen activity is favoured on, ranked by the jian chu day officer and filtered against a zodiac animal to protect. Every candidate day comes back with its officer, its pillars, its lunar date and the animal it clashes with, so a caller can show the reasoning rather than a bare verdict. The range is capped at 93 days, which is a quarter, because date selection is done inside a planning window rather than across a lifetime. Built for wedding planners, business opening tools, and moving and travel date pickers.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response 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 |
| compact | No | Set 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. | |
| endDate | Yes | Last date of the range to search, inclusive. The range may not exceed 93 days. | |
| activity | Yes | Activity to choose a date for. One of wedding, travel, moving-house, opening-business, signing-contracts, construction, groundbreaking, burial, medical-treatment, praying. Matching folds case and punctuation, so moving-house and MOVING_HOUSE both resolve. | |
| startDate | Yes | First date of the range to search, inclusive. | |
| avoidAnimal | No | Zodiac animal to protect. Days that clash with this animal are dropped from the results, which is how a date is chosen around the people attending rather than in the abstract. One of rat, ox, tiger, rabbit, dragon, snake, horse, goat, monkey, rooster, dog, pig. |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| total | Yes | |
| endDate | Yes | |
| activity | Yes | |
| startDate | Yes | |
| avoidAnimal | No | |
| daysSearched | Yes | |
| activityLabel | Yes | |
| avoidAnimalLocalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds the substantive behavior: returns ranked results with officer, pillars, lunar date, and clash details, and enforces the 93-day range cap. Also notes the compact parameter's token savings, but the core behavioral disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that are dense but efficient. Front-loads the core purpose (search + ranking), then adds output details and constraints. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, complete schema, and output schema presence, the description covers all necessary context: what it does, how results are presented, the range constraint, and target use cases. Nothing critical is missing for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all six parameters. The description adds context for the activity and avoidAnimal (why they matter) and the range cap, but doesn't go beyond the schema for lang and compact. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search), resource (date range for a chosen activity), and key filtering criteria (jian chu day officer, zodiac animal). Distinguishes from siblings by focusing on auspicious day search rather than single-day, monthly, or year-based calendar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear that it's for date selection within a planning window, with explicit 93-day cap. Implicitly positioned against siblings (single days, monthly, solar terms), but no explicit 'when not to use' or comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Gregorian date to the Chinese lunisolar calendar or convert a lunar date back, in one endpoint. The calendar is computed at the UTC+8 reference meridian with the month containing the winter solstice fixed as month 11 and the leap month placed as the first month of the cycle carrying no major solar term, so a lunar date is the same worldwide rather than shifting with the caller timezone. The response reports the length of the lunar month, whether the date sits in a leap month, and which month the year doubles if any. Built for festival calendars, birthday features that follow the lunar date, and any app that has to survive a leap month without shifting every date after it.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Gregorian date to convert to the lunisolar calendar. Send this OR the lunar fields, never both. Converts from the first day of lunar year 1551 to the last day of lunar year 2648, a little inside the supported date span, because numbering a lunar month needs the winter solstice on each side of it and placing a leap month needs the year before; a date outside that answers 400 date_out_of_range. | |
| lang | No | Response 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 |
| compact | No | Set 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. | |
| lunarDay | No | Day of the lunar month, 1 to 30. Requires lunarYear and lunarMonth. | |
| lunarYear | No | Lunisolar year to convert back to a Gregorian date. Requires lunarMonth and lunarDay. | |
| lunarMonth | No | Lunar month, 1 to 12. Requires lunarYear and lunarDay. | |
| isLeapMonth | No | Set true to address the leap repetition of lunarMonth rather than the first pass. Requesting a leap month a year does not have returns 400. |
| Name | Required | Description |
|---|---|---|
| lunar | Yes | |
| gregorianDate | Yes | |
| leapMonthOfYear | No | |
| referenceOffset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint/destructiveHint annotations, the description carries real behavioral weight: it discloses the UTC+8 reference meridian, the month-11 winter-solstice fixing rule, the leap-month placement rule, and why a lunar date is timezone-invariant. It also flags range-limited error behavior via the schema, giving the agent operating semantics beyond the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core conversion capability is front-loaded in the first clause, and the remaining sentences explain the calendrical rules that make the output trustworthy. The astronomical justification is slightly verbose but each sentence supports a decision the agent or its caller must make.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, zero-required conversion endpoint with an output schema and read-only annotations, the description adequately covers the conversion model and the leap-month edge case. It could say more about which mode triggers on which input combination and how out-of-range lunars fail, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all 7 parameters are documented there, including mutual exclusivity, ranges, and the leap-month flag, so the baseline is 3. The description adds conceptual meaning to the lunar fields (why a lunar date is globally stable) but no syntax or per-parameter detail beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Convert a Gregorian date to the Chinese lunisolar calendar or convert a lunar date back, in one endpoint'), covering both directions in a single scope. This bidirectional date-conversion scope is clearly separable from the day/month/solar-term siblings and from the bazi and zodiac tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names target use cases ('festival calendars, birthday features that follow the lunar date') but never states when to prefer this over a sibling such as the day or monthly endpoints, nor any exclusion. Usage is implied by the use-case list rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a birth date to its Chinese zodiac animal, the sexagenary year pillar behind it, and the Five Element phase of that year, so a 1990 birth returns Horse as a Metal Horse rather than merely a Horse. The year boundary is a request parameter because the two schools genuinely disagree for dates in January and early February, and the resolved convention is echoed back so the answer is self-describing. Built for sign lookups, onboarding forms and birthday features.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. Only the date is needed: the zodiac animal is a property of the year, so no time, timezone or place changes the answer. | |
| lang | No | Response 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 |
| compact | No | Set 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. | |
| yearBoundary | No | Which instant starts the zodiac year. lunar-new-year is the folk rule and the default on this route, because it is the rule people mean when they say what animal they are: the sign turns on Chinese New Year, between late January and late February. li-chun is the classical rule every Four Pillars text uses, turning the year at the solar term Beginning of Spring around 4 February. The two agree for roughly eleven months of every year and disagree for the weeks between them, so a 14 February 2026 birth is a Snake under lunar-new-year and a Horse under li-chun. The BaZi routes default to li-chun instead, because a chart and a folk sign are answering different questions. | lunar-new-year |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| animal | Yes | |
| element | Yes | |
| polarity | Yes | |
| yearPillar | Yes | |
| conventions | Yes | |
| interpretation | Yes | |
| elementLocalized | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive; the description adds behavioral context by noting the resolved convention is echoed back and that the year boundary can change the result. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: core purpose, boundary caveat, and intended use cases. It is front-loaded with the main value and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, full parameter coverage, and safety annotations, the description supplies the remaining needed context: what is computed, why the boundary parameter exists, and when the tool is appropriate. Nothing essential for correct selection and invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with detailed descriptions, including date format, language fallback, compact shape, and yearBoundary semantics. The prose mostly reinforces these points rather than adding new parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve a birth date') and names the exact resource and outputs: zodiac animal, sexagenary year pillar, and Five Element phase. It distinguishes itself from sibling list/reference tools by emphasizing a computed, self-describing result rather than a simple lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states concrete use cases ('sign lookups, onboarding forms and birthday features') and explains when the yearBoundary choice matters, including the different BaZi route default. It does not explicitly name or exclude a sibling tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
post_chinese_astrology_calendar_lunar_date1 field changedInput schema / properties / date / descriptionPrevious value: -"Gregorian date to convert to the lunisolar calendar. Send this OR the lunar fields, never both."New value: +"Gregorian date to convert to the lunisolar calendar. Send this OR the lunar fields, never both. Converts from the first day of lunar year 1551 to the last day of lunar year 2648, a little inside the supported date span, because numbering a lunar month needs the winter solstice on each side of it and placing a leap month needs the year before; a date outside that answers 400 date_out_of_range."post_chinese_astrology_bazi_annual_forecast2 fields changedInput schema / properties / year / maximumPrevious value: -2100New value: +2649Input schema / properties / year / minimumPrevious value: -1900New value: +1551post_chinese_astrology_bazi_luck_pillars2 fields changedInput schema / properties / annualFromYear / maximumPrevious value: -2100New value: +2649Input schema / properties / annualFromYear / minimumPrevious value: -1900New value: +1551post_chinese_astrology_bazi_annual_forecast1 field changedInput schema / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."post_chinese_astrology_bazi_chart1 field changedInput schema / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."post_chinese_astrology_bazi_compatibility2 fields changedInput schema / properties / personA / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."Input schema / properties / personB / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."post_chinese_astrology_bazi_day_master1 field changedInput schema / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."post_chinese_astrology_bazi_luck_pillars1 field changedInput schema / properties / hourClock / descriptionPrevious value: -"Which 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."New value: +"Which clock the day boundary and the hour branch are read from, so a correction that carries a birth across midnight moves the day pillar with the hour. \"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."get_chinese_astrology_elements2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_chinese_astrology_zodiac_animals2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0post_chinese_astrology_bazi_chart1 field changedOutput schema / properties / pillars / items / properties / naYinElementLocalizedAdded value: +{
+ "type": "string"
+}post_chinese_astrology_bazi_compatibility2 fields changedOutput schema / properties / personA / properties / pillars / items / properties / naYinElementLocalizedAdded value: +{
+ "type": "string"
+}Output schema / properties / personB / properties / pillars / items / properties / naYinElementLocalizedAdded value: +{
+ "type": "string"
+}get_chinese_astrology_elements3 fields changedInput schema / properties / offset / defaultRemoved value: -0Input schema / properties / offset / minimumRemoved value: -0Input schema / properties / offset / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"get_chinese_astrology_zodiac_animals3 fields changedInput schema / properties / offset / defaultRemoved value: -0Input schema / properties / offset / minimumRemoved value: -0Input schema / properties / offset / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"get_chinese_astrology_calendar_day_date1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "avoids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "clashAnimal": {
+ "type": "string"
+ },
+ "clashAnimalLocalized": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "dayOfficer": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "quality": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "quality",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "dayPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "favours": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lunar": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "day": {
+ "type": "number"
+ },
+ "isLeapMonth": {
+ "type": "boolean"
+ },
+ "month": {
+ "type": "number"
+ },
+ "monthLength": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "month",
+ "day",
+ "isLeapMonth",
+ "monthLength",
+ "date"
+ ],
+ "type": "object"
+ },
+ "mansion": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "palace": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "planet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "chinese",
+ "pinyin",
+ "palace",
+ "planet",
+ "animal"
+ ],
+ "type": "object"
+ },
+ "monthPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "yearPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "lunar",
+ "yearPillar",
+ "monthPillar",
+ "dayPillar",
+ "dayOfficer",
+ "mansion",
+ "clashAnimal",
+ "favours",
+ "avoids"
+ ],
+ "type": "object"
+}get_chinese_astrology_calendar_monthly1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "days": {
+ "items": {
+ "properties": {
+ "avoids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "clashAnimal": {
+ "type": "string"
+ },
+ "clashAnimalLocalized": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "dayOfficer": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "quality": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "quality",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "dayPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "favours": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lunar": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "day": {
+ "type": "number"
+ },
+ "isLeapMonth": {
+ "type": "boolean"
+ },
+ "month": {
+ "type": "number"
+ },
+ "monthLength": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "month",
+ "day",
+ "isLeapMonth",
+ "monthLength",
+ "date"
+ ],
+ "type": "object"
+ },
+ "mansion": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "palace": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "planet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "chinese",
+ "pinyin",
+ "palace",
+ "planet",
+ "animal"
+ ],
+ "type": "object"
+ },
+ "monthPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "yearPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "lunar",
+ "yearPillar",
+ "monthPillar",
+ "dayPillar",
+ "dayOfficer",
+ "mansion",
+ "clashAnimal",
+ "favours",
+ "avoids"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "month": {
+ "type": "number"
+ },
+ "solarTerms": {
+ "items": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "instantUtc": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "type",
+ "date",
+ "instantUtc"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "month",
+ "total",
+ "solarTerms",
+ "days"
+ ],
+ "type": "object"
+}get_chinese_astrology_calendar_solar_terms_year1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "referenceOffset": {
+ "type": "number"
+ },
+ "terms": {
+ "items": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "instantUtc": {
+ "type": "string"
+ },
+ "localDate": {
+ "type": "string"
+ },
+ "localTime": {
+ "type": "string"
+ },
+ "longitude": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "longitude",
+ "type",
+ "instantUtc",
+ "localDate",
+ "localTime"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "referenceOffset",
+ "total",
+ "terms"
+ ],
+ "type": "object"
+}get_chinese_astrology_elements1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "controllingCycle": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "elements": {
+ "items": {
+ "properties": {
+ "branches": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "controlledBy": {
+ "type": "string"
+ },
+ "controls": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "generatedBy": {
+ "type": "string"
+ },
+ "generates": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "season": {
+ "type": "string"
+ },
+ "stems": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "season",
+ "direction",
+ "generates",
+ "generatedBy",
+ "controls",
+ "controlledBy",
+ "stems",
+ "branches",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "generatingCycle": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "generatingCycle",
+ "controllingCycle",
+ "elements"
+ ],
+ "type": "object"
+}get_chinese_astrology_zodiac_animals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "animals": {
+ "items": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "traits": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity",
+ "traits"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "animals"
+ ],
+ "type": "object"
+}get_chinese_astrology_zodiac_animals_id1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "clashPartner": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin"
+ ],
+ "type": "object"
+ },
+ "compatibilitySummary": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "elementVariants": {
+ "items": {
+ "properties": {
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "pillar": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "stem": {
+ "type": "string"
+ },
+ "years": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "element",
+ "polarity",
+ "stem",
+ "pillar",
+ "years"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "harmPartner": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin"
+ ],
+ "type": "object"
+ },
+ "hours": {
+ "properties": {
+ "end": {
+ "type": "number"
+ },
+ "start": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "start",
+ "end"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "secretFriend": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "element"
+ ],
+ "type": "object"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "traits": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "trine": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "members": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "number": {
+ "type": "number"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "element",
+ "chinese",
+ "pinyin",
+ "members",
+ "theme"
+ ],
+ "type": "object"
+ },
+ "weaknesses": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity",
+ "traits",
+ "summary",
+ "strengths",
+ "weaknesses",
+ "compatibilitySummary",
+ "hours",
+ "trine",
+ "secretFriend",
+ "clashPartner",
+ "harmPartner",
+ "elementVariants"
+ ],
+ "type": "object"
+}get_chinese_astrology_zodiac_compatibility_sign1_sign21 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "advice": {
+ "type": "string"
+ },
+ "frictions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "relationship": {
+ "type": "string"
+ },
+ "relationshipChinese": {
+ "type": "string"
+ },
+ "relationshipName": {
+ "type": "string"
+ },
+ "relationshipNameLocalized": {
+ "type": "string"
+ },
+ "relationshipPinyin": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "sharedElement": {
+ "type": "string"
+ },
+ "sharedElementLocalized": {
+ "type": "string"
+ },
+ "signs": {
+ "properties": {
+ "first": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "second": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "first",
+ "second"
+ ],
+ "type": "object"
+ },
+ "strengths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signs",
+ "relationship",
+ "relationshipName",
+ "relationshipChinese",
+ "relationshipPinyin",
+ "score",
+ "verdict",
+ "summary",
+ "strengths",
+ "frictions",
+ "advice"
+ ],
+ "type": "object"
+}get_chinese_astrology_zodiac_id_daily1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "advice": {
+ "type": "string"
+ },
+ "animal": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "benMingNian": {
+ "type": "boolean"
+ },
+ "career": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "dayPillar": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "branch": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "animal",
+ "element"
+ ],
+ "type": "object"
+ },
+ "energyRating": {
+ "maximum": 10,
+ "minimum": 1,
+ "type": "number"
+ },
+ "love": {
+ "type": "string"
+ },
+ "overview": {
+ "type": "string"
+ },
+ "relationship": {
+ "type": "string"
+ },
+ "year": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "pillar": {
+ "type": "string"
+ },
+ "relationship": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pillar",
+ "animal",
+ "relationship",
+ "note"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "animal",
+ "date",
+ "dayPillar",
+ "relationship",
+ "energyRating",
+ "overview",
+ "love",
+ "career",
+ "advice",
+ "year",
+ "benMingNian"
+ ],
+ "type": "object"
+}post_chinese_astrology_bazi_annual_forecast1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "annualPillar": {
+ "properties": {
+ "branch": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "animal",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinChinese": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "naYin",
+ "naYinChinese"
+ ],
+ "type": "object"
+ },
+ "benMingNian": {
+ "type": "boolean"
+ },
+ "birthData": {
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "latitude": {
+ "default": 0,
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+ },
+ "longitude": {
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+ },
+ "time": {
+ "format": "time",
+ "type": "string"
+ },
+ "timezone": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "date",
+ "time",
+ "timezone"
+ ],
+ "type": "object"
+ },
+ "branchTenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "interactions": {
+ "items": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "complete": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "members": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "positions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "quality": {
+ "type": "string"
+ },
+ "transformsTo": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "variety": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "chinese",
+ "pinyin",
+ "quality",
+ "positions",
+ "members",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ },
+ "year": {
+ "type": "number"
+ },
+ "yearBranchRelation": {
+ "type": "string"
+ },
+ "yearBranchRelationMeaning": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "birthData",
+ "conventions",
+ "year",
+ "annualPillar",
+ "animal",
+ "tenGod",
+ "branchTenGod",
+ "yearBranchRelation",
+ "benMingNian",
+ "yearBranchRelationMeaning",
+ "interactions",
+ "summary"
+ ],
+ "type": "object"
+}post_chinese_astrology_bazi_chart1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "birthData": {
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "latitude": {
+ "default": 0,
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+ },
+ "longitude": {
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+ },
+ "time": {
+ "format": "time",
+ "type": "string"
+ },
+ "timezone": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "date",
+ "time",
+ "timezone"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "dayMaster": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "nature": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "stem",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity",
+ "nature"
+ ],
+ "type": "object"
+ },
+ "fiveElements": {
+ "items": {
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "level": {
+ "type": "string"
+ },
+ "reading": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "element",
+ "count",
+ "level",
+ "reading"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "interactions": {
+ "items": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "complete": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "members": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "positions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "quality": {
+ "type": "string"
+ },
+ "transformsTo": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "variety": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "chinese",
+ "pinyin",
+ "quality",
+ "positions",
+ "members",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pillars": {
+ "items": {
+ "properties": {
+ "branch": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "animal",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "hiddenStems": {
+ "items": {
+ "properties": {
+ "role": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "stem",
+ "role",
+ "tenGod"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinChinese": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "position": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "position",
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "tenGod",
+ "hiddenStems",
+ "naYin",
+ "naYinChinese",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "zodiacAnimal": {
+ "type": "string"
+ },
+ "zodiacAnimalLocalized": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "birthData",
+ "conventions",
+ "pillars",
+ "dayMaster",
+ "zodiacAnimal",
+ "fiveElements",
+ "interactions",
+ "summary"
+ ],
+ "type": "object"
+}post_chinese_astrology_bazi_compatibility1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "challengingCount": {
+ "type": "number"
+ },
+ "dayMasterRelation": {
+ "type": "string"
+ },
+ "harmoniousCount": {
+ "type": "number"
+ },
+ "interactions": {
+ "items": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "complete": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "members": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "positions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "quality": {
+ "type": "string"
+ },
+ "transformsTo": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "variety": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "id",
+ "chinese",
+ "pinyin",
+ "quality",
+ "positions",
+ "members",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "personA": {
+ "properties": {
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "dayMaster": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "nature": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "stem",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity",
+ "nature"
+ ],
+ "type": "object"
+ },
+ "pillars": {
+ "items": {
+ "properties": {
+ "branch": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "animal",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "hiddenStems": {
+ "items": {
+ "properties": {
+ "role": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "stem",
+ "role",
+ "tenGod"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinChinese": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "position": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "position",
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "tenGod",
+ "hiddenStems",
+ "naYin",
+ "naYinChinese",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strength": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pillars",
+ "dayMaster",
+ "strength",
+ "conventions"
+ ],
+ "type": "object"
+ },
+ "personB": {
+ "properties": {
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "dayMaster": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "nature": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "stem",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity",
+ "nature"
+ ],
+ "type": "object"
+ },
+ "pillars": {
+ "items": {
+ "properties": {
+ "branch": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "animal",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "hiddenStems": {
+ "items": {
+ "properties": {
+ "role": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "stem",
+ "role",
+ "tenGod"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinChinese": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "position": {
+ "type": "string"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "position",
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "tenGod",
+ "hiddenStems",
+ "naYin",
+ "naYinChinese",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strength": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pillars",
+ "dayMaster",
+ "strength",
+ "conventions"
+ ],
+ "type": "object"
+ },
+ "score": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "personA",
+ "personB",
+ "dayMasterRelation",
+ "interactions",
+ "score",
+ "harmoniousCount",
+ "challengingCount",
+ "summary"
+ ],
+ "type": "object"
+}post_chinese_astrology_bazi_day_master1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "birthData": {
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "latitude": {
+ "default": 0,
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+ },
+ "longitude": {
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+ },
+ "time": {
+ "format": "time",
+ "type": "string"
+ },
+ "timezone": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "date",
+ "time",
+ "timezone"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "dayMaster": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "nature": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "stem",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity",
+ "nature"
+ ],
+ "type": "object"
+ },
+ "factors": {
+ "items": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "contribution": {
+ "type": "number"
+ },
+ "detail": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "contribution",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "favorableElements": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "fiveElements": {
+ "items": {
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "level": {
+ "type": "string"
+ },
+ "reading": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "element",
+ "count",
+ "level",
+ "reading"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rootCount": {
+ "type": "number"
+ },
+ "score": {
+ "type": "number"
+ },
+ "seasonalState": {
+ "type": "string"
+ },
+ "seasonalStateChinese": {
+ "type": "string"
+ },
+ "seasonalStateMeaning": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "unfavorableElements": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "birthData",
+ "conventions",
+ "dayMaster",
+ "verdict",
+ "score",
+ "seasonalState",
+ "seasonalStateChinese",
+ "seasonalStateMeaning",
+ "rootCount",
+ "factors",
+ "favorableElements",
+ "unfavorableElements",
+ "fiveElements",
+ "summary"
+ ],
+ "type": "object"
+}post_chinese_astrology_bazi_luck_pillars1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "annualPillars": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "luckPillarIndex": {
+ "type": "number"
+ },
+ "number": {
+ "type": "number"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "id",
+ "number",
+ "tenGod",
+ "luckPillarIndex"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "birthData": {
+ "properties": {
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "latitude": {
+ "default": 0,
+ "maximum": 90,
+ "minimum": -90,
+ "type": "number"
+ },
+ "longitude": {
+ "maximum": 180,
+ "minimum": -180,
+ "type": "number"
+ },
+ "time": {
+ "format": "time",
+ "type": "string"
+ },
+ "timezone": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "date",
+ "time",
+ "timezone"
+ ],
+ "type": "object"
+ },
+ "boundaryTerm": {
+ "type": "string"
+ },
+ "boundaryTermName": {
+ "type": "string"
+ },
+ "conventions": {
+ "properties": {
+ "dayBoundary": {
+ "enum": [
+ "split-zi",
+ "midnight",
+ "early-zi"
+ ],
+ "type": "string"
+ },
+ "hourClock": {
+ "enum": [
+ "clock",
+ "local-mean",
+ "solar"
+ ],
+ "type": "string"
+ },
+ "yearBoundary": {
+ "enum": [
+ "li-chun",
+ "lunar-new-year"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "dayBoundary",
+ "yearBoundary",
+ "hourClock"
+ ],
+ "type": "object"
+ },
+ "daysToTerm": {
+ "type": "number"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "gender": {
+ "type": "string"
+ },
+ "luckPillars": {
+ "items": {
+ "properties": {
+ "branch": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "animal",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "endAge": {
+ "type": "number"
+ },
+ "endYear": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "index": {
+ "type": "number"
+ },
+ "number": {
+ "type": "number"
+ },
+ "startAge": {
+ "type": "number"
+ },
+ "startYear": {
+ "type": "number"
+ },
+ "stem": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chinese",
+ "pinyin",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "tenGod": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "keynote": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "category",
+ "keynote"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "index",
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "tenGod",
+ "startAge",
+ "endAge",
+ "startYear",
+ "endYear"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "startAge": {
+ "type": "number"
+ },
+ "startAgeMonths": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "birthData",
+ "conventions",
+ "gender",
+ "direction",
+ "startAge",
+ "startAgeMonths",
+ "daysToTerm",
+ "boundaryTerm",
+ "boundaryTermName",
+ "luckPillars",
+ "summary"
+ ],
+ "type": "object"
+}post_chinese_astrology_calendar_auspicious_days1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "activity": {
+ "type": "string"
+ },
+ "activityLabel": {
+ "type": "string"
+ },
+ "avoidAnimal": {
+ "type": "string"
+ },
+ "avoidAnimalLocalized": {
+ "type": "string"
+ },
+ "days": {
+ "items": {
+ "properties": {
+ "avoids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "clashAnimal": {
+ "type": "string"
+ },
+ "clashAnimalLocalized": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "dayOfficer": {
+ "properties": {
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "quality": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "quality",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "dayPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "favours": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "lunar": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "day": {
+ "type": "number"
+ },
+ "isLeapMonth": {
+ "type": "boolean"
+ },
+ "month": {
+ "type": "number"
+ },
+ "monthLength": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "month",
+ "day",
+ "isLeapMonth",
+ "monthLength",
+ "date"
+ ],
+ "type": "object"
+ },
+ "mansion": {
+ "properties": {
+ "animal": {
+ "type": "string"
+ },
+ "animalLocalized": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "palace": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "planet": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "chinese",
+ "pinyin",
+ "palace",
+ "planet",
+ "animal"
+ ],
+ "type": "object"
+ },
+ "monthPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ },
+ "yearPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "naYin": {
+ "type": "string"
+ },
+ "naYinElement": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch",
+ "chinese",
+ "naYin",
+ "naYinElement"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "lunar",
+ "yearPillar",
+ "monthPillar",
+ "dayPillar",
+ "dayOfficer",
+ "mansion",
+ "clashAnimal",
+ "favours",
+ "avoids"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "daysSearched": {
+ "type": "number"
+ },
+ "endDate": {
+ "type": "string"
+ },
+ "startDate": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "activity",
+ "activityLabel",
+ "startDate",
+ "endDate",
+ "daysSearched",
+ "total",
+ "days"
+ ],
+ "type": "object"
+}post_chinese_astrology_calendar_lunar_date1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "gregorianDate": {
+ "type": "string"
+ },
+ "leapMonthOfYear": {
+ "type": "number"
+ },
+ "lunar": {
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "day": {
+ "type": "number"
+ },
+ "isLeapMonth": {
+ "type": "boolean"
+ },
+ "month": {
+ "type": "number"
+ },
+ "monthLength": {
+ "type": "number"
+ },
+ "year": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "year",
+ "month",
+ "day",
+ "isLeapMonth",
+ "monthLength",
+ "date"
+ ],
+ "type": "object"
+ },
+ "referenceOffset": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "gregorianDate",
+ "lunar",
+ "referenceOffset"
+ ],
+ "type": "object"
+}post_chinese_astrology_zodiac_sign1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "animal": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "chinese": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nameLocalized": {
+ "type": "string"
+ },
+ "pinyin": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "chinese",
+ "pinyin",
+ "branch",
+ "element",
+ "polarity"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "yearBoundary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "yearBoundary"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "elementLocalized": {
+ "type": "string"
+ },
+ "interpretation": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "yearPillar": {
+ "properties": {
+ "branch": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "stem": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "number",
+ "stem",
+ "branch"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "animal",
+ "yearPillar",
+ "element",
+ "polarity",
+ "interpretation",
+ "conventions"
+ ],
+ "type": "object"
+}get_chinese_astrology_calendar_monthly2 fields changedInput schema / properties / month / typePrevious value: -"number"New value: +"integer"Input schema / properties / year / typePrevious value: -"number"New value: +"integer"get_chinese_astrology_calendar_solar_terms_year1 field changedInput schema / properties / year / typePrevious value: -"number"New value: +"integer"get_chinese_astrology_calendar_monthly4 fields changedInput schema / properties / month / maximumAdded value: +12Input schema / properties / month / minimumAdded value: +1Input schema / properties / year / maximumAdded value: +2100Input schema / properties / year / minimumAdded value: +1900get_chinese_astrology_calendar_solar_terms_year2 fields changedInput schema / properties / year / maximumAdded value: +2100Input schema / properties / year / minimumAdded value: +1900get_chinese_astrology_calendar_day_date1 field changedInput schema / properties / date / formatAdded value: +"date"post_chinese_astrology_bazi_annual_forecast1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."post_chinese_astrology_bazi_chart1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."post_chinese_astrology_bazi_compatibility2 fields changedInput schema / properties / personA / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."Input schema / properties / personB / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."post_chinese_astrology_bazi_day_master1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."post_chinese_astrology_bazi_luck_pillars1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA 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."New value: +"IANA 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 offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."get_chinese_astrology_calendar_day_dateget_chinese_astrology_calendar_monthlyget_chinese_astrology_calendar_solar_terms_yearget_chinese_astrology_elementsget_chinese_astrology_zodiac_animalsget_chinese_astrology_zodiac_animals_idget_chinese_astrology_zodiac_compatibility_sign1_sign2get_chinese_astrology_zodiac_id_dailypost_chinese_astrology_bazi_annual_forecastpost_chinese_astrology_bazi_chartpost_chinese_astrology_bazi_compatibilitypost_chinese_astrology_bazi_day_masterpost_chinese_astrology_bazi_luck_pillarspost_chinese_astrology_calendar_auspicious_dayspost_chinese_astrology_calendar_lunar_datepost_chinese_astrology_zodiac_signChinese almanac: lunar calendar, BaZi 八字, daily 宜忌, lucky-day picker, public holidays.
Generate BaZi charts from birth details. Explore Four Pillars, solar terms, and Luck Pillars for d…
Chinese metaphysics (bazi, qimen, 5-element) as decision-support tools for AI agents.
BaZi four pillars, Zi Wei Dou Shu, the Chinese calendar and feng shui.
Add one secure layer between your agents and this server.
