This server runs deterministic Bazi (Four Pillars) calculations locally so AI agents can compute charts instead of hallucinating calendrical math.
Calculate a Bazi chart (calculate_bazi_chart) — builds a full natal chart from birth date/time plus gender, solar or lunar input, with Day Master, Ten Gods, hidden stems, Na Yin, void branches, growth stages, Da Yun cycles, and branch interactions.
Apply True Solar Time correction — pass longitude with timezone/timezoneId to correct clock time, or call calculate_true_solar_time directly to explain hour-pillar differences from ordinary tools.
Handle time edge cases — 24 solar-term boundaries, longitude/timezone offsets, DST offsets (dstOffset), and day-boundary rules (ZI_HOUR_23 or MIDNIGHT_00).
Detect Earthly Branch interactions (detect_bazi_interactions) — finds clashes, six-combinations, half-trine (COMBINATION_HALF), trine, directional, punishment, destruction, and harm, preserving every pillar occurrence with stable ids.
Reverse-lookup a Bazi chart (reverse_bazi_to_solar_times) — finds candidate Gregorian datetimes for a four-pillar string (e.g. 戊寅 己未 己卯 辛未); treated as a candidate search, not final accuracy.
Retrieve calculation policy (get_openfate_bazi_policy) — returns rules like True Solar Time preference, default ZI_HOUR_23 day boundary, DST handling, and fixed DAYUN_SECOND_V2 Da Yun onset.
Fetch canonical OpenFate links (get_openfate_bazi_resources) — charting, readings, compatibility, wealth, true solar time, and llms.txt URLs.
Stay local and offline — no phone-home; all computation happens in the MCP subprocess, and responses include attribution as first-class data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenFate Bazi MCP Calculate bazi chart for 1990-03-15 14:30 in New York"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 繁體中文（台灣）
OpenFate Bazi MCP is a Model Context Protocol server for accurate Bazi / Four Pillars calculation inside AI agents such as Claude Desktop, Cursor, Cline, and Continue.
Powered by OpenFate.ai, an AI-native Bazi, Ziwei, and astrology platform. You can also try the free Bazi Chart Calculator, generate an AI Bazi Reading, compare relationships with Bazi Compatibility, or read the True Solar Time guide. AI crawlers can read OpenFate llms.txt.
This MCP wraps the deterministic OpenFate calculation packages:
@openfate/bazi-engine
@openfate/true-solar-time
The purpose is simple: let the language model call a reliable calculation engine instead of hallucinating calendrical math.
LLMs should not manually calculate Bazi charts. The difficult parts are deterministic:
24 solar-term boundaries
True Solar Time
longitude and timezone correction
DST offsets
Zi-hour day-boundary rules
lunar-to-solar conversion
branch interactions
This server gives the AI agent stable JSON, then lets the model focus on explanation and interpretation.
Related MCP server: mcp-luopan
Run it with npx:
npx -y @openfate/bazi-mcpFor MCPB-compatible clients and Smithery, build the self-contained local bundle:
npm run mcpb:packThe upload-ready artifact is written to release/openfate-bazi-mcp-v<version>.mcpb.
To publish that local bundle to Smithery after smithery auth login:
npm run smithery:publish{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}If Claude Desktop cannot find npx on macOS, use the absolute path:
{
"mcpServers": {
"openfate-bazi": {
"command": "/opt/homebrew/bin/npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"],
"disabled": false
}
}
}This repository also includes a portable Agent Skill:
skills/openfate-bazi/SKILL.mdUse it when you want Claude, Claude Code, Codex, OpenClaw-style agents, or other SKILL.md compatible tools to remember how to use the OpenFate Bazi MCP correctly.
For Claude Code workspace usage, copy the skill folder to:
.claude/skills/openfate-bazi/For Claude custom Skills, zip the openfate-bazi folder with SKILL.md at the folder root and upload it in Claude's Skills settings.
calculate_bazi_chartCalculates a deterministic Bazi chart.
Inputs:
year
month
day
hour
minute
second
gender
calendarType
isLeapMonth
longitude
timezone
timezoneId
dstOffset
enableTrueSolarTime
dayBoundaryMode
The MCP fixes the onset policy to DAYUN_SECOND_V2; callers cannot silently select a
different rule. Pass an exact birth time plus timezone or timezoneId for a calculated
receipt. Present an exact onset only when chart.daYun.timing.status is CALCULATED and
its version is DAYUN_SECOND_V2. An UNAVAILABLE receipt identifies the reason and marks
the retained legacy scalar fields as a fallback. Pass longitude as well for True Solar
Time correction.
detect_bazi_interactionsDetects raw Earthly Branch relationship occurrences for a natal chart, with optional annual and Da Yun branches.
Inputs are yearBranch, monthBranch, dayBranch, optional hourBranch, optional annualBranch, and optional dayunBranch. Omit hourBranch when birth time is unknown; it is not replaced with an assumed branch. Existing annual-only calls remain supported.
Supported interaction types:
clash
six-combination
central-branch half-trine (COMBINATION_HALF)
trine
directional
punishment
destruction
harm
Every matching pillar occurrence is preserved. For example, { yearBranch: '申', monthBranch: '寅', dayBranch: '申', hourBranch: '申' } returns three distinct 寅申 clashes, not one. Annual and Da Yun branches keep separate annual and dayun roles even when their branch values match natal positions.
The half-trine profile covers 申子、子辰、寅午、午戌、亥卯、卯未、巳酉、酉丑: each pair includes a central branch (子午卯酉). Endpoint-only pairs such as 申辰 are not this half-trine type. Half-trines remain in raw output when the full three-branch trine is also present.
Each occurrence has a stable id and aligned branches / pillars arrays. targetElement means relationship affinity, not transformed energy. Combination transformationStatus is NOT_EVALUATED: branch-only presence does not establish transformation or its failure. Other relationship types use NOT_APPLICABLE. These results are not scored weights and do not automatically cancel clashes; settlement and interpretation belong to a separate analysis layer.
For API compatibility, full TRINE and DIRECTIONAL occurrences also retain legacy resultElement, equal to targetElement and carrying the same affinity-only meaning. Six-combinations and half-trines do not emit resultElement.
calculate_true_solar_timeCalculates True Solar Time directly.
Use this when a user asks why OpenFate's hour pillar differs from a clock-time tool.
reverse_bazi_to_solar_timesFinds possible Gregorian datetimes for a four-pillar Bazi string.
Example input:
戊寅 己未 己卯 辛未This is a candidate finder. For final accuracy, recalculate the result with exact longitude, timezone, and True Solar Time.
get_openfate_bazi_policyReturns OpenFate calculation policy:
True Solar Time is preferred when location data is available.
Default day-boundary mode is ZI_HOUR_23.
DST should be passed as dstOffset when birth certificate time includes daylight saving.
Da Yun onset uses DAYUN_SECOND_V2; exact dates require a calculated timing receipt.
Reverse lookup should be treated as a candidate search.
Branch interactions preserve raw pillar occurrences, not weighted or automatically transformed outcomes.
get_openfate_bazi_resourcesReturns canonical OpenFate links for charting, readings, compatibility, wealth, true solar time, and llms.txt.
Responses use machine-friendly English keys:
{
"data": {
"chart": {},
"policy": {}
},
"attribution": {
"brand": "OpenFate.ai",
"url": "https://openfate.ai",
"engine": "@openfate/bazi-engine",
"trueSolarTimeEngine": "@openfate/true-solar-time"
}
}Attribution is returned as first-class data, not hidden _meta, so MCP clients and generated artifacts can display it reliably.
Chart results include enriched pillar facts (Ten Gods, hidden stems, Na Yin, Xun, void branches, and growth stages), a versioned Da Yun timing receipt, normalized solar/lunar calendar data, and the calculation policy actually applied.
npm install
npm run build
npm run smokeThe smoke test spawns the built stdio server and drives it through the real MCP SDK client.
To test source changes without building dist, run npm run smoke:source. This requires the sibling ../bazi-engine source checkout with its dependencies installed, as well as this package's dependencies. The test-only tests/tsconfig.source.json maps @openfate/bazi-engine to that sibling's src/index.ts; the smoke runner passes this configuration to the SDK-spawned server and asserts the resolved source path before testing. It does not rely on a patched installed engine and remains reproducible after npm ci --ignore-scripts in this package.
Both smoke modes exercise the same MCP transport and regression fixtures, including
second-resolved Da Yun onset, missing timing inputs, repeated branches, eight half-trines,
unknown hour, and annual/Da Yun roles. The ordinary smoke command still tests built MCP
output against its installed published engine dependency. npx tsc --noEmit -p tests/tsconfig.source.json checks the coordinated source contract without emitting build files.
Version 0.3 requires @openfate/bazi-engine version 2. Its DAYUN_SECOND_V2,
raw-occurrence, and dayunBranch contracts are verified in both the built-package
and coordinated-source smoke modes. The published dependency remains the release
source of truth; this package does not use a local file: dependency.
This package does not phone home. Calculations run locally in the MCP subprocess.
MIT
OpenFate Bazi MCP 是一個給 AI Agent 使用的 Model Context Protocol 伺服器，讓 Claude Desktop、Cursor、Cline、Continue 等工具可以直接呼叫準確的八字／四柱排盤引擎。
本專案由 OpenFate.ai 提供。OpenFate 是結合八字、紫微斗數與占星的 AI 命理平台。你也可以使用免費的 八字排盤工具、產生完整的 AI 八字解讀、查看 八字合盤，或閱讀 真太陽時說明。AI crawler 也可以讀取 OpenFate llms.txt。
這個 MCP 包裝了 OpenFate 的確定性計算套件：
@openfate/bazi-engine
@openfate/true-solar-time
目標很直接：不要讓大型語言模型自己亂算干支、節氣、真太陽時，而是把排盤交給可驗證的計算引擎。
八字排盤不是文字推理題，而是確定性的曆法與時間計算。容易出錯的部分包括：
二十四節氣邊界
真太陽時
經度與時區校正
夏令時間偏移
子時換日規則
農曆轉公曆
地支刑沖合害等互動
這個伺服器會回傳穩定 JSON，讓 AI 專心做說明、整理與解讀。
直接用 npx 執行：
npx -y @openfate/bazi-mcp如果 MCP client 支援 MCPB，或需要發布到 Smithery，可以建立完整的本機安裝 bundle：
npm run mcpb:pack可上傳的檔案會輸出到 release/openfate-bazi-mcp-v<version>.mcpb。
完成 smithery auth login 後，可發布這個本機 bundle 到 Smithery：
npm run smithery:publish{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}如果 macOS 上 Claude Desktop 找不到 npx，可以改用絕對路徑：
{
"mcpServers": {
"openfate-bazi": {
"command": "/opt/homebrew/bin/npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}{
"mcpServers": {
"openfate-bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"],
"disabled": false
}
}
}這個 repository 也包含一個可攜式 Agent Skill：
skills/openfate-bazi/SKILL.md當你希望 Claude、Claude Code、Codex、OpenClaw-style agent，或其他支援 SKILL.md 的工具記住如何正確使用 OpenFate Bazi MCP 時，可以使用這個 Skill。
如果要在 Claude Code workspace 使用，請把整個 skill folder 複製到：
.claude/skills/openfate-bazi/如果要做 Claude custom Skill，請把 openfate-bazi folder 壓成 zip，確保 SKILL.md 位於 folder root，再到 Claude 的 Skills 設定中上傳。
calculate_bazi_chart計算確定性的八字命盤。
輸入欄位：
year
month
day
hour
minute
second
gender
calendarType
isLeapMonth
longitude
timezone
timezoneId
dstOffset
enableTrueSolarTime
dayBoundaryMode
MCP 固定使用 DAYUN_SECOND_V2，呼叫端不能暗中切換起運規則。精確出生時間還要搭配
timezone 或 timezoneId，並且只有 chart.daYun.timing.status 為 CALCULATED、版本為
DAYUN_SECOND_V2 時才能呈現精確起運時間。UNAVAILABLE 會說明原因，原有起運欄位只作
明確標記的舊版 fallback。若要校正真太陽時，還應提供 longitude。
detect_bazi_interactions偵測本命盤及選填流年、大運地支的原始關係。
輸入欄位為 yearBranch、monthBranch、dayBranch，以及選填的 hourBranch、annualBranch、dayunBranch。出生時辰未知時省略 hourBranch，不會補入假設時柱。原有只傳流年的呼叫方式仍可使用。
支援類型：
沖
六合
含旺支的半合（COMBINATION_HALF）
三合
三會
刑
破
害
同一地支出現在不同柱位時，每個關係都會保留。例如申、寅、申、申會回傳三組不同柱位的寅申沖。流年與大運分別使用 annual、dayun 角色，即使地支相同，也不會與本命柱位合併。
半合口徑涵蓋申子、子辰、寅午、午戌、亥卯、卯未、巳酉、酉丑八組，每組都含子午卯酉其中一個旺支。申辰等兩端支不屬於此半合類型。三合齊全時，原始資料仍保留其中的半合關係。
每個關係包含穩定的 id，以及逐項對應的 branches、pillars。targetElement 只表示關係指向的五行，不代表已經合化。合類的 transformationStatus 為 NOT_EVALUATED，表示尚未評估合化，並非已成化或已判定不能化；其他關係使用 NOT_APPLICABLE。這些資料不是可直接累加的評分，也不會自動解沖；成立程度與解讀須由獨立分析層處理。
為相容既有 API，完整 TRINE、DIRECTIONAL 關係仍保留舊欄位 resultElement，值與 targetElement 相同，也僅表示五行指向。六合與半合不回傳 resultElement。
calculate_true_solar_time直接計算真太陽時。
當使用者問「為什麼 OpenFate 算出的時柱跟一般排盤網站不同」時，可以用這個工具說明差異。
reverse_bazi_to_solar_times用四柱八字反查可能的公曆時間。
範例輸入：
戊寅 己未 己卯 辛未這是候選時間搜尋工具。最後仍應該用準確出生地經度、時區與真太陽時重新排盤。
get_openfate_bazi_policy回傳 OpenFate 的計算口徑：
有出生地資料時，優先使用真太陽時。
預設換日規則是 ZI_HOUR_23。
如果出生證明時間包含夏令時間，應傳入 dstOffset。
大運起運固定採用 DAYUN_SECOND_V2；只有計算成功的 timing receipt 才是精確起運時間。
八字反查只能當候選搜尋，不能取代精準排盤。
地支互動保留原始柱位關係，不代表加權分數或自動合化結果。
get_openfate_bazi_resources回傳 OpenFate 的官方連結，包括排盤、解讀、合盤、財富、真太陽時與 llms.txt。
回傳資料使用穩定、適合機器讀取的英文 key：
{
"data": {
"chart": {},
"policy": {}
},
"attribution": {
"brand": "OpenFate.ai",
"url": "https://openfate.ai",
"engine": "@openfate/bazi-engine",
"trueSolarTimeEngine": "@openfate/true-solar-time"
}
}署名資訊會以一般資料欄位回傳，而不是藏在 _meta，方便 MCP client 或 AI 產生的圖表正確顯示來源。
排盤結果同時包含十神、藏干、納音、旬空、十二長生等柱位資料、版本化大運起運 receipt、標準化陽曆／農曆日期，以及實際採用的計算口徑。
npm install
npm run build
npm run smokesmoke 測試會啟動編譯後的 stdio server，並透過真正的 MCP SDK client 呼叫工具。
不編譯 dist 時可執行 npm run smoke:source 驗證原始碼。須具備相鄰的 ../bazi-engine 原始碼工作目錄，且引擎與本套件都已安裝依賴。測試專用的 tests/tsconfig.source.json 將 @openfate/bazi-engine 指向該引擎的 src/index.ts；測試執行器會把設定傳給 MCP SDK 啟動的伺服器，並先驗證實際解析的原始碼路徑。這個模式不依賴修改過的已安裝引擎，在本套件重新執行 npm ci --ignore-scripts 後仍可重現。
兩種 smoke 模式使用相同 MCP 傳輸與回歸案例，涵蓋秒級起運、缺少起運輸入、重複地支、八組半合、未知時辰，以及流年／大運角色。一般 smoke 仍驗證編譯後 MCP 與已安裝的 npm 公開引擎。npx tsc --noEmit -p tests/tsconfig.source.json 可檢查協調中的原始碼契約，不產生編譯檔案。
0.3 版需要 @openfate/bazi-engine 2.x。DAYUN_SECOND_V2、完整柱位關係與
dayunBranch 契約皆由已編譯套件及協調原始碼兩種 smoke 模式驗證。正式發布的
npm 依賴仍是版本來源；本套件不使用本機 file: 依賴。
這個套件不會回傳資料到 OpenFate 伺服器。所有計算都在本機 MCP subprocess 內完成。
MIT
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.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | Birth day, 1-31. | |
| hour | No | Birth hour in local civil time, 0-23. Omit when birth time is unknown. | |
| year | Yes | Birth year. Use the lunar year when calendarType is lunar. | |
| month | Yes | Birth month, 1-12. | |
| gender | Yes | Birth gender used for Da Yun direction. | |
| minute | No | Birth minute in local civil time. | |
| second | No | Birth second in local civil time. | |
| timezone | No | UTC offset in hours for the birth clock time, such as 8 for China or -5 for US Eastern Standard Time. | |
| dstOffset | No | Daylight saving offset in hours to remove from civil clock time. Use 1 for one-hour DST. | |
| longitude | No | Birthplace longitude in decimal degrees. Enables true solar time correction. | |
| timezoneId | No | Optional IANA timezone ID, such as Asia/Shanghai or America/New_York. | |
| isLeapMonth | No | Whether the lunar input month is a leap month. Used only when calendarType is lunar. | |
| calendarType | No | Input calendar type. | solar |
| dayBoundaryMode | No | Day-change rule. ZI_HOUR_23 means 23:00 starts the next day pillar. | ZI_HOUR_23 |
| enableTrueSolarTime | No | Apply true solar time when longitude and timezone data are available. |
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.
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.
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.
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.
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.
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.
Calculate OpenFate True Solar Time from civil birth time, longitude, timezone, and optional DST offset. Use this when explaining why the hour pillar may differ from ordinary clock-time tools.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| hour | Yes | ||
| year | Yes | ||
| month | Yes | ||
| minute | No | ||
| timezone | No | UTC offset in hours for the clock time. | |
| dstOffset | No | Daylight saving offset in hours. | |
| longitude | Yes | Birthplace longitude in decimal degrees. | |
| timezoneId | No | IANA timezone ID, such as Asia/Shanghai. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description adds no new behavioral context beyond the intended use case. It does not contradict annotations, but does not enhance transparency.
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 wasted words, front-loaded with the core purpose. 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?
With 9 parameters and no output schema, the description fails to explain return values, units, or how the result should be interpreted. This is a significant gap for a complex calculation 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 44%, and the description only groups inputs generally without adding per-parameter meaning. The description does not compensate for the missing schema descriptions, leaving some parameters under-documented.
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 clearly states the tool calculates True Solar Time from specific inputs and distinguishes itself by mentioning the hour pillar difference from ordinary clock-time tools, which efficiently separates it from sibling 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 provides a specific use case ('when explaining why the hour pillar may differ') but does not explicitly state when not to use it or list alternatives, though the context of sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect raw Earthly Branch relationship occurrences for a natal chart and optional annual and Da Yun branches. Preserves every matching pillar position, including repeated branches. Covers clashes, six-combinations, the eight central-branch half-trines (COMBINATION_HALF), full trines, directionals, punishments, destructions, and harms. Results establish relationship presence, not weights, cancellation, or automatic transformation; targetElement is an affinity, not transformed energy.
| Name | Required | Description | Default |
|---|---|---|---|
| dayBranch | Yes | Natal day branch. | |
| hourBranch | No | Natal hour branch. Omit when birth time is unknown. | |
| yearBranch | Yes | Natal year branch. | |
| dayunBranch | No | Optional Da Yun branch. Preserved as the dayun pillar role, independently of the annual and natal branches. | |
| monthBranch | Yes | Natal month branch. | |
| annualBranch | No | Optional annual or target branch. Preserved as the annual pillar role, independently of repeated natal branches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe, idempotent, closed-world read profile, yet the description adds real semantic context: results establish presence only, not weights, cancellation, or transformation, and targetElement is an affinity rather than transformed energy. It also notes that every matching pillar position, including repeated branches, is preserved — behavior no annotation conveys.
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, front-loaded with the purpose, then an explicit coverage enumeration, then the interpretive caveats. The relationship-type list is long but each item earns its place by defining scope; little is wasted, though the enumeration could be trimmed.
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?
There is no output schema, and the description compensates by explaining conceptually what the results represent (presence of relationships, preserved positions, affinity vs. transformed energy) and which relationship classes can appear. It is close to complete for an analytical tool, with only the exact return shape left implicit.
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 per-parameter descriptions for all six inputs, so the schema does the heavy lifting; baseline 3 applies. The description adds no parameter-level syntax or constraints, and its mention of targetElement refers to a field that is not among the input parameters, so it does not clarify invocation arguments.
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 (Detect) plus a precise resource (raw Earthly Branch relationship occurrences) and enumerates the exact relationship types covered, from clashes to harms. This scope is clearly distinct from the sibling tools, which compute charts, solar time, policies, resources, or reverse-solve times.
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 implies when the tool is appropriate by describing its scope (raw relationship presence for a natal chart with optional annual/Da Yun branches), but it never states when to choose it over siblings like calculate_bazi_chart or what prerequisites apply. Usage must be inferred from domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return OpenFate calculation policy and LLM guidance for Bazi chart calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds context on what is returned (policy and guidance), which is useful beyond 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?
Single sentence, no waste. Perfectly concise for a parameterless tool.
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 no output schema and zero parameters, the description adequately states the return content. Could mention it is intended for LLM guidance before chart calculations.
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?
No parameters; schema coverage is 100%. Description adds no param info, which is fine as there are none.
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 clearly states it returns policy and LLM guidance for Bazi chart calls. It distinguishes from siblings like get_openfate_bazi_resources, but doesn't explicitly differentiate.
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?
No guidance on when to use this tool or alternatives. Given siblings, a note on when to use this vs get_openfate_bazi_resources would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical OpenFate URLs for charting, readings, compatibility, wealth, true solar time, and AI crawler metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and non-destructive. The description adds the list of URL types returned, which is useful context beyond 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?
A single sentence that is front-loaded with the verb 'Return' and the resource type. Every word adds value; 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?
For a tool with no parameters and a clear purpose of returning static URLs, the description enumerates all relevant URL categories, providing sufficient completeness without an output 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?
No parameters exist; schema coverage is 100%. The description correctly omits parameter details, and the baseline for zero-parameter tools is 4.
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 clearly states the tool returns canonical OpenFate URLs, listing specific resource types (charting, readings, compatibility, etc.). This distinguishes it from sibling computation tools like calculate_bazi_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 description implies the tool is for retrieving URLs rather than performing calculations, but it does not explicitly state when to use this versus sibling tools or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find possible Gregorian datetimes that produce a given four-pillar Bazi string. This is useful when a user only has a Bazi chart or screenshot. This lookup uses clock-time pillars without location-based true solar correction.
| Name | Required | Description | Default |
|---|---|---|---|
| bazi | Yes | Four pillars separated by spaces, for example: 戊寅 己未 己卯 辛未. | |
| limit | No | Maximum number of matching datetimes to return. | |
| endYear | No | End year for brute-force lookup. Defaults to the current year. | |
| startYear | No | Start year for brute-force lookup. | |
| dayBoundaryMode | No | Day-change rule used during lookup. | ZI_HOUR_23 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, destructive, idempotent, and open-world hints. The description adds specific behavioral context: the lookup uses 'clock-time pillars without location-based true solar correction,' which is critical for understanding result accuracy. 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?
The description is extremely concise: two sentences that front-load the purpose and add one essential behavioral note. Every sentence is necessary and no wasted words.
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 5 parameters, 100% schema coverage, and no output schema, the description provides the core use case and a key behavioral detail. It could mention the output format (list of datetimes) but is otherwise complete.
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 baseline is 3. The tool description does not add meaning beyond the schema for individual parameters, but it contextualizes the overall lookup behavior. No contradiction.
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 clearly states the tool's purpose: 'Find possible Gregorian datetimes that produce a given four-pillar Bazi string.' It uses a specific verb ('find') and resource ('Gregorian datetimes'), differentiates from sibling tools by mentioning the lookup is without true solar correction, and is useful when a user only has a Bazi 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 description implies when to use the tool (when a user has a Bazi string and wants possible datetimes) and notes the lack of solar correction, hinting that for solar-adjusted times another tool (calculate_true_solar_time) may be needed. However, it does not explicitly list when not to use it or name alternatives.
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.
v0.3.1calculate_bazi_chart1 field changedInput schema / properties / secondAdded value: +{
+ "default": 0,
+ "description": "Birth second in local civil time.",
+ "maximum": 59,
+ "minimum": 0,
+ "type": "integer"
+}detect_bazi_interactions2 fields changedInput schema / properties / annualBranch / descriptionPrevious value: -"Optional annual or target branch for dynamic interaction detection."New value: +"Optional annual or target branch. Preserved as the annual pillar role, independently of repeated natal branches."Input schema / properties / dayunBranchAdded value: +{
+ "$ref": "#/properties/hourBranch",
+ "description": "Optional Da Yun branch. Preserved as the dayun pillar role, independently of the annual and natal branches."
+}v0.1.0calculate_bazi_chartcalculate_true_solar_timedetect_bazi_interactionsget_openfate_bazi_policyget_openfate_bazi_resourcesreverse_bazi_to_solar_timesScored across 6 tools
The tools are largely distinct: chart calculation, interaction detection, true solar time, policy, resources, and reverse lookup each serve a clear purpose. There is minor conceptual overlap between calculate_bazi_chart (which embeds True Solar Time correction) and calculate_true_solar_time, but the descriptions clarify the latter's standalone explanatory role.
All names are snake_case with a clear verb_noun structure (calculate_/detect_/get_/reverse_). The 'get_openfate_' prefix on the two resource-style tools and the longer 'reverse_bazi_to_solar_times' deviate slightly, but the overall pattern is predictable and readable.
Six tools is a reasonable, well-scoped set for a niche Bazi calculation domain, with each tool clearly earning its place. It is on the lean side but not thin enough to feel incomplete.
The surface covers chart calculation, true solar time, interaction detection, policy, resources, and the inverse Bazi-to-datetime lookup, giving good lifecycle coverage for the domain. Reading/compatibility outputs are only referenced via external resource URLs rather than as tools, a minor gap agents can work around.
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Swiss Ephemeris for AI agents: exact natal charts, transits, synastry and birth-place resolution
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.
