BaZi (Four Pillars) calculation from birth date, time, and location via public remote MCP.
Scored across 1 tool
With a single tool there is no possibility of misselection; the tool's purpose (compute a BaZi chart from birth data) is stated explicitly and unambiguously. The description also clearly delineates what the tool does not do (no interpretation, no duplicated output).
The lone name follows a clean verb_noun pattern (calculate_bazi_chart) in consistent snake_case. There are no competing conventions to conflict with.
One tool is defensible for a narrowly scoped chart engine, but the described surface (chart plus optional interpretation and text-chart output) is folded into a single call, making the set feel thin. Borderline rather than clearly well-scoped.
Chart calculation is covered, but typical BaZi workflows — compatibility/synastry analysis, date selection, or a dedicated interpretation/text-output path — have no counterpart tool. These gaps are workable since the model can interpret the structured result itself, but they are notable.
Calculates a BaZi (Four Pillars of Destiny, 八字, 四柱推命, Saju) chart from a birth date, time and place with the InsightBaZi engine, and shows it as a chart card. Use it when the user asks for a BaZi chart, or for their Four Pillars, Day Master, Ten Gods, element balance or 10-year luck pillars to be worked out from a birth date. It applies true solar time from the birthplace longitude and historical daylight-saving rules, changes the Day Pillar at 23:00, the year at Lichun and months at solar terms. The chart card is the user-facing result. After a chart-only request, briefly confirm it is ready; do not duplicate its chart, tables or element breakdown. Interpret the structured result only if requested, or provide a text chart if explicitly requested.
| Name | Required | Description | Default |
|---|---|---|---|
| gender | No | Needed only for the 10-year luck pillars, whose direction depends on it. | |
| language | No | Language for chart labels. Use the closest match to the user's language; use en when none matches. | en |
| timezone | Yes | IANA time zone of the birthplace, for example Asia/Bangkok or America/New_York. | |
| longitude | No | Longitude of the birth city in decimal degrees, east positive, used only for the true-solar-time correction. Give the city's longitude when the birth city is known; never the user's current location. | |
| birth_date | Yes | Birth date in the Gregorian calendar, YYYY-MM-DD. | |
| birth_time | No | Clock time on the birth record, 24-hour HH:MM, exactly as recorded (do not adjust for daylight saving). Omit when the user does not know it. | |
| birthplace | No | Birth city as the user gave it, shown on the card. This is the place of birth, never the user's current location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a safe, closed-world read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description adds genuinely useful domain behavior beyond that: true solar time from birthplace longitude, historical daylight-saving rules, the 23:00 Day Pillar rollover, and Lichun/solar-term boundaries. It still doesn't say whether results are cached or how the card is delivered, so it isn't exhaustive.
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?
Purpose, trigger conditions, computational rules and post-call behavior are front-loaded in that order with no filler. It is on the long side for a single tool, and the final interpretation sentence could be tightened, but every sentence carries operational 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?
For a domain-heavy calculation tool with no output schema, the description supplies what an agent needs: the inputs it draws on, the calendrical rules that determine the result, that the chart card is the user-facing artifact, and how to respond afterward. Nothing essential to correct 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?
Schema description coverage is 100%, so the schema already explains gender, language, timezone, longitude, birth_date, birth_time and birthplace. The description reinforces why longitude and birthplace matter (solar-time correction vs. user's current location), but adds no syntax or edge-case detail beyond the schema. Baseline 3 applies when structured fields carry the parameter 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 opens with a precise verb-plus-resource statement ('Calculates a BaZi ... chart from a birth date, time and place with the InsightBaZi engine') and includes the alternate names users may use (Four Pillars, 八字, Saju), so an agent can match many phrasings without ambiguity.
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 explicitly when to use it ('when the user asks for a BaZi chart, or for their Four Pillars, Day Master, Ten Gods, element balance or 10-year luck pillars') and what to do after calling it: confirm briefly, don't duplicate the chart, interpret only if requested. That is both selection guidance and post-call routing.
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.
calculate_bazi_chartBaZi MCP gateway: 14 tools (6 fortune / 5 forum / 3 meta). API key required. Entertainment only.
Free Qimen Dunjia and BaZi charts via MCP - deterministic engine, nine palaces and four pillars.
Generate BaZi charts from birth details. Explore Four Pillars, solar terms, and Luck Pillars for d…
BaZi (Chinese Four Pillars) chart calculator. Structured chart data only, no predictions.
Add one secure layer between your agents and this server.
