Qi Men Dun Jia charts, BaZi Four Pillars, best-time ranking and solar terms. Free, no key.
Scored across 4 tools
Each tool targets a distinct output: natal pillars, a single Qi Men chart, a multi-day ranking of windows, and the solar-term table. The only soft overlap is best_times, which internally casts Qi Men charts and could be momentarily conflated with qimen_chart, but the descriptions make the ranking-versus-single-chart distinction clear.
All four names are lowercase snake_case and are noun phrases describing the artifact returned (bazi_pillars, qimen_chart, solar_terms, best_times), so there is no stylistic mixing. The only deviation from the ideal is the absence of a verb_noun pattern, though a noun-based convention suits these computational tools.
Four tools is well within the healthy range and each covers a genuinely different need: natal calculation, moment casting, timing search, and calendar reference. Nothing feels redundant or padded for the scope of a BaZi/Qi Men server.
Core casting workflows — birth pillars, Qi Men charts, auspicious timing, and solar terms — are all covered with no dead ends for chart generation. Gaps exist on the BaZi side (luck cycles/da yun, ten-gods interpretation, transit or compatibility views), but these are analytical extras an agent can partly derive rather than blocking operations.
Four Pillars (八字) for a birth moment: converts the clock time with the zone rules for that date (daylight saving included) and the longitude to true solar time; the year follows Li Chun and the day changes at 23:00 true solar time. Returns the pillars, Day Master, five-element counts and the time conversion details.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | Yes | IANA time zone of the birthplace, e.g. "Asia/Shanghai". | |
| longitude | No | Birthplace longitude, east positive. Default: the standard meridian of the time zone. | |
| birth_datetime | Yes | Birth wall-clock time "YYYY-MM-DDTHH:mm", as on the birth certificate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description goes well beyond them: it discloses that timezone/DST rules and longitude→true-solar-time conversion are applied, that the year rolls at Li Chun, and that the day changes at 23:00 true solar time. These are non-obvious domain conventions that materially affect interpreting the 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?
Two sentences, zero filler, front-loaded with what is computed before the return-value summary. The parentheticals earn their place by pinning down the two most easily misread conventions.
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?
No output schema exists, yet the description enumerates the return contents (pillars, Day Master, five-element counts, time conversion details) and covers the edge cases an agent would otherwise guess at — DST, Li Chun year boundary, 23:00 day rollover. Complete enough 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 baseline is 3, but the description adds real meaning: it explains why timezone and longitude matter (zone rules with DST, true solar time conversion). It does not restate the accepted datetime format, which the schema already handles.
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 pair: computes the Four Pillars (八字) for a birth moment. The domain specificity makes it clearly distinct from the sibling tools best_times, qimen_chart and solar_terms without needing to name them.
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 phrase 'for a birth moment' implies the intended use case, but there is no explicit guidance on when to choose this tool over qimen_chart or solar_terms, and no stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cast a Qi Men chart for every double-hour of the next few days and rank them for a goal, using the person's Day Master from the birth date. Returns the top windows with date, hour branch, true-solar-time range, score and the lucky direction at that time.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | How many windows to return, 1-10. Default 5. | |
| days | No | How many days ahead to scan, 1-7. Default 7. | |
| focus | No | Goal to rank for. Default general. | |
| longitude | No | Longitude of where the person is now, east positive. Default 120 (Beijing meridian). | |
| birth_date | Yes | Birth date "YYYY-MM-DD" (sets the Day Master). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and closed-world, and the description adds the meaningful behavioral fact that results are computed across a rolling 'next few days' horizon, which explains the idempotentHint=false. It also enumerates the returned fields (date, hour branch, true-solar-time range, score, lucky direction). It does not mention cost/latency of scanning up to 84 double-hours.
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, both earning their place: the first covers computation and ranking, the second covers the return payload. Nothing is repeated from the title or schema.
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 no output schema, the description carries the return-value burden and does so adequately by listing the output fields. The remaining gap is operational (expected runtime for a multi-day scan) and edge-case behavior, which is minor for a read-only analytical tool.
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 baseline is 3; the description goes beyond it by tying birth_date to the Day Master and longitude to the true-solar-time range, clarifying why those inputs matter. It still doesn't clarify how 'focus' changes ranking or how 'top' interacts with 'days'.
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 ('Cast a Qi Men chart for every double-hour'), the scope ('next few days'), and the operation ('rank them for a goal'). It also names the data source (Day Master from the birth date), which makes it clearly distinct from a single-chart sibling like qimen_chart.
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 use case (find ranked windows for a goal) is implied by the description, but there is no explicit when-to-use / when-not-to-use guidance and no named alternative such as qimen_chart for a single-moment reading. The agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cast an hour-based Qi Men Dun Jia (奇门遁甲) chart for a moment and place: four pillars, ju, Chief Star and Door, and for each of the nine palaces the deity, star, door, heaven/earth/hidden stems, void, horse star, punishment and door pressure, plus detected patterns, palace scores for the chosen focus and the lucky directions.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | What the question is about; changes palace scores and lucky directions. Default general. | |
| datetime | No | Local wall-clock time "YYYY-MM-DDTHH:mm" in `timezone`. Omit for now. | |
| timezone | No | IANA time zone, e.g. "Asia/Shanghai", "America/New_York". Default Asia/Shanghai. | |
| longitude | No | Longitude of the place in degrees, east positive, west negative. Default: the standard meridian of the time zone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context by detailing the complexity and depth of the expected output (e.g., 'deity, star, door, heaven/earth/hidden stems'). This informs the agent that the tool performs deep analysis, going far beyond simple structural execution.
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 tool definition is packed with necessary technical detail, but it is presented as a single, extremely long run-on sentence. While efficient in information density, it lacks structural clarity.
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 no output schema exists, the description is exceptionally complete. It outlines every major component that an agent must expect in the response, making it a complete guide for both selection and invocation.
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?
Although the schema provides 100% coverage, the description provides critical semantic meaning for the `focus` parameter, clarifying that selecting a focus 'changes palace scores and lucky directions,' thereby explaining the impact of the input on the analysis.
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 is highly specific, stating exactly what is cast (Qi Men Dun Jia chart) and listing all constituent elements of the result, such as 'four pillars,' 'ju,' and 'palace scores.' This leaves no ambiguity for the agent.
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?
While it doesn't offer a formal 'when/when-not' rule, the exhaustive list of output components implies that this tool is intended for the comprehensive, full-fidelity analysis of the chart, distinguishing it from a simpler tool that might only return 'pillars'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 24 solar terms (节气) of a calendar year, 1900-2100, with UTC and Beijing-time instants from the same table the charts use (within about a minute of the Hong Kong Observatory).
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, so the description only needs to add context. It does that usefully by disclosing the data source, dual time zones (UTC and Beijing), and an accuracy bound relative to the Hong Kong Observatory.
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?
A single front-loaded sentence with the resource and range stated first, followed by the time-zone and accuracy qualifiers. No wasted text.
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 no output schema, the description usefully signals what is returned (instants in UTC and Beijing time) and the year bounds. It could say more about the shape of the returned list, but is adequate for a one-parameter lookup.
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% and the single parameter is fully documented, so the schema carries the semantics. The description restates the 1900-2100 range already enforced by the schema's min/max, adding no new syntax or format detail.
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 the specific resource (the 24 solar terms) and scope (a calendar year, 1900-2100), so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from the sibling tools, but the resource is distinctive enough that confusion is unlikely.
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 only implied: needing solar-term dates/times for a given year. There is no statement of when to use this over bazi_pillars, best_times, or qimen_chart, nor any prerequisites or exclusions.
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.
bazi_pillarsbest_timesqimen_chartsolar_termsFree BaZi, I Ching, tarot, Zi Wei and bilingual learning tools with transparent methods. No API key.
Bazi (Four Pillars) and Qimen Dunjia charts with true solar time and historical time zones.
Generate BaZi charts from birth details. Explore Four Pillars, solar terms, and Luck Pillars for d…
Read-only Bazi, True Solar Time, and Chinese almanac tools in English and Traditional Chinese.
Add one secure layer between your agents and this server.