Skip to main content
Glama

Mingpath

bazi_chart

Compute a BaZi four-pillars chart from birth data (Gregorian). Returns pillars, Day Master, Ten Gods, hidden stems, element tally, luck pillars and the conventions used (true solar time, Zi-hour rule, solar-term boundaries). The year pillar changes at 立春 and the month pillar at each 节 by comparing the birth instant (converted to UTC+8) with the 节 instant, so a birth abroad switches at the same moment as in China; day and hour pillars use apparent solar time at the birthplace. When the birth is within two hours of a 节, chart.jieBoundary names it and gives the year/month pillars on the other side. Free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>",
      "month": "<month>",
      "day": "<day>"
    },
    "name": "bazi_chart"
  }
}

Input Schema

NameRequiredDescriptionDefault
tzNoIANA time zone of the birthplace, e.g. Asia/Shanghai, America/Los_Angeles. Preferred over tz_hours: historical summer time is applied (the mainland observed it 1986–1991, Hong Kong and Taiwan in many earlier years), so a clock time read off a birth certificate in summer time gives the right hour pillar
dayYes
hourNo0-23 local clock hour; omit if unknown
yearYes
monthYes
genderNo
minuteNo
zi_ruleNo子时 convention: 1 = a birth after 23:00 counts as the next day; 2 (default) = same day
tz_hoursNofixed UTC offset of the birthplace in hours, e.g. 8 (no summer time); used only when tz is absent
longitudeNobirthplace longitude in degrees east, e.g. 103.82 for Singapore

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the exact rule set (year pillar flips at 立春, month pillar at each 节, birth instant normalized to UTC+8 so overseas births switch at the same moment, day/hour pillars use apparent solar time at the birthplace), the edge-case behavior within two hours of a 节 via chart.jieBoundary, and that the call is free. It also names the returned convention block an agent can use to sanity-check results.

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

Conciseness4/5

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

Three sentences, front-loaded with purpose and outputs, then the calculation rules, then the boundary edge case — nothing is filler. It is dense, though: the middle sentence packs several rules together and is harder to parse than its content requires.

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

Completeness4/5

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

For a 10-parameter tool with no annotations and no output schema, it covers the essentials: what comes back, how time zones and solar time are handled, and the ambiguous-boundary case. It does not state what happens when hour is omitted (a documented 'omit if unknown' option in the schema) or what gender changes in the computation, which are the remaining gaps.

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

Parameters4/5

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

Schema coverage is 50%, so the description must compensate, and it partly does: it explains why tz beats tz_hours (historical summer time affects the hour pillar) and why longitude matters (apparent solar time), adding rationale beyond the schema's field notes. It adds nothing for gender, minute, or zi_rule beyond what the schema already documents, leaving a few parameters thin.

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

Purpose5/5

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

States a specific verb and resource ('Compute a BaZi four-pillars chart from birth data (Gregorian)') and then enumerates the returned artifacts (pillars, Day Master, Ten Gods, hidden stems, element tally, luck pillars, conventions). This is unambiguous and cannot be confused with the ziwei_chart sibling, which is a different astrological system.

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

Usage Guidelines3/5

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

The description implies usage (supply birth data to obtain a chart) and gives conditional guidance about which conventions apply, but never says when to pick this over ziwei_chart or auspicious_dates, nor any prerequisite/exclusion. Usage is inferable but not routed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources