Skip to main content
Glama
openfate-ai

OpenFate Bazi MCP

Official
by openfate-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Calculate Bazi Chart

calculate_bazi_chart
Read-onlyIdempotent

Calculate a deterministic Bazi chart from birth data with True Solar Time correction, Day Master, Da Yun cycles, and branch interactions, returning explicit receipts when onset data is unavailable.

Instructions

Calculate a deterministic OpenFate Bazi/Four Pillars chart with True Solar Time correction, Day Master, DAYUN_SECOND_V2 onset receipts, Da Yun cycles, and branch interactions. Pass an exact birth time plus timezone or timezoneId for a calculated V2 onset; otherwise inspect the explicit unavailable/fallback receipt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayYesBirth day, 1-31.
hourNoBirth hour in local civil time, 0-23. Omit when birth time is unknown.
yearYesBirth year. Use the lunar year when calendarType is lunar.
monthYesBirth month, 1-12.
genderYesBirth gender used for Da Yun direction.
minuteNoBirth minute in local civil time.
secondNoBirth second in local civil time.
timezoneNoUTC offset in hours for the birth clock time, such as 8 for China or -5 for US Eastern Standard Time.
dstOffsetNoDaylight saving offset in hours to remove from civil clock time. Use 1 for one-hour DST.
longitudeNoBirthplace longitude in decimal degrees. Enables true solar time correction.
timezoneIdNoOptional IANA timezone ID, such as Asia/Shanghai or America/New_York.
isLeapMonthNoWhether the lunar input month is a leap month. Used only when calendarType is lunar.
calendarTypeNoInput calendar type.solar
dayBoundaryModeNoDay-change rule. ZI_HOUR_23 means 23:00 starts the next day pillar.ZI_HOUR_23
enableTrueSolarTimeNoApply true solar time when longitude and timezone data are available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.1
    • addedInput schema / properties / second
      Added value: +{
+  "default": 0,
+  "description": "Birth second in local civil time.",
+  "maximum": 59,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

The annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value beyond them: it declares the calculation is deterministic, names the specific configurable outputs (True Solar Time correction, DAYUN_SECOND_V2 onset receipts), and discloses the degraded/fallback path when birth time is absent. It stops short of explaining what a 'receipt' contains or the fallback response shape.

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?

Two dense sentences, front-loaded with the core verb and outputs, then the input/fallback condition. Terminology like 'DAYUN_SECOND_V2 onset receipts' is jargon-heavy but appears to be the tool's own domain vocabulary, so it is not wasted space.

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

Completeness4/5

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

With no output schema and 15 parameters, the description carries the return-value burden, and it does name the headline results (Day Master, Da Yun cycles, branch interactions, onset/fallback receipts). It is nearly complete, though the unexplained 'receipt' concept and fallback payload are a small residual gap given there is no output schema to fall back on.

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 description coverage is 100%, so the baseline is 3; the description earns above baseline by tying parameters together, explaining that an exact birth time combined with timezone or timezoneId is what yields a calculated V2 onset versus the fallback branch. It adds the cross-parameter dependency the schema states only field-by-field.

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

Purpose4/5

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

States a specific verb and resource ('Calculate a deterministic OpenFate Bazi/Four Pillars chart') and enumerates the outputs (Day Master, Da Yun cycles, branch interactions, onset receipts), so an agent knows exactly what it produces. It does not, however, distinguish itself from siblings that also compute Bazi-related data (detect_bazi_interactions, calculate_true_solar_time).

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?

It gives a useful conditional: supply an exact birth time plus timezone/timezoneId to get a calculated V2 onset, otherwise inspect the fallback receipt. That is implied usage guidance for inputs, but it never addresses when to choose this tool over the sibling tools or any exclusions, leaving the alternative-selection decision to inference.

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

Deploy Server

Other Tools