This server provides deterministic Bazi (Four Pillars of Destiny) calculations for AI agents, replacing error-prone LLM calendrical math with a reliable calculation engine.
calculate_bazi_chart: Generate a complete natal chart given birth date, time, gender, and optional location data. Supports solar/lunar calendar input, True Solar Time correction, DST offsets, and day-boundary rules. Returns enriched data including Day Master, Ten Gods, hidden stems, Na Yin, void branches, growth stages, and Da Yun (major cycle) timing.
detect_bazi_interactions: Analyze Earthly Branch interactions (clashes, six-combinations, trines, directional combinations, punishments, destructions, and harms) for natal charts, annual triggers, or synastry comparisons.
calculate_true_solar_time: Convert civil clock time to True Solar Time using longitude, UTC offset, and optional DST offset — useful for explaining why an hour pillar may differ from ordinary clock-time tools.
reverse_bazi_to_solar_times: Given a four-pillar Bazi string (e.g., 戊寅 己未 己卯 辛未), find all possible matching Gregorian birth datetimes within a specified year range.
get_openfate_bazi_policy: Retrieve OpenFate's canonical calculation rules — including True Solar Time preference, default day-boundary mode, DST handling, and reverse-lookup caveats.
get_openfate_bazi_resources: Get canonical URLs for the free Bazi chart calculator, AI readings, compatibility tools, True Solar Time guide, and llms.txt for AI crawlers.
Click on "Install 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
gender
calendarType
isLeapMonth
longitude
timezone
timezoneId
dstOffset
enableTrueSolarTime
dayBoundaryMode
Best practice: pass longitude plus timezone or timezoneId for professional True Solar Time accuracy.
detect_bazi_interactionsDetects Earthly Branch interactions for a natal chart, annual trigger, or simple synastry target.
Supported interaction types:
clash
six-combination
trine
directional
punishment
destruction
harm
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.
Reverse lookup should be treated as a candidate search.
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), exact Da Yun timing, 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.
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
gender
calendarType
isLeapMonth
longitude
timezone
timezoneId
dstOffset
enableTrueSolarTime
dayBoundaryMode
建議提供 longitude 加上 timezone 或 timezoneId，才能做專業級真太陽時校正。
detect_bazi_interactions偵測地支互動，適合用於本命盤、流年觸發，或簡單合盤比較。
支援類型：
沖
六合
三合
三會
刑
破
害
calculate_true_solar_time直接計算真太陽時。
當使用者問「為什麼 OpenFate 算出的時柱跟一般排盤網站不同」時，可以用這個工具說明差異。
reverse_bazi_to_solar_times用四柱八字反查可能的公曆時間。
範例輸入：
戊寅 己未 己卯 辛未這是候選時間搜尋工具。最後仍應該用準確出生地經度、時區與真太陽時重新排盤。
get_openfate_bazi_policy回傳 OpenFate 的計算口徑：
有出生地資料時，優先使用真太陽時。
預設換日規則是 ZI_HOUR_23。
如果出生證明時間包含夏令時間，應傳入 dstOffset。
八字反查只能當候選搜尋，不能取代精準排盤。
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 產生的圖表正確顯示來源。
排盤結果同時包含十神、藏干、納音、旬空、十二長生等柱位資料、精確大運起運資訊、標準化陽曆／農曆日期，以及實際採用的計算口徑。
npm install
npm run build
npm run smokesmoke 測試會啟動編譯後的 stdio server，並透過真正的 MCP SDK client 呼叫工具。
這個套件不會回傳資料到 OpenFate 伺服器。所有計算都在本機 MCP subprocess 內完成。
MIT
Calculate a deterministic OpenFate Bazi/Four Pillars chart with True Solar Time correction, Day Master, Da Yun cycles, and branch interactions. For best accuracy, pass longitude plus timezone or timezoneId.
| 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. | |
| 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?
Annotations already indicate read-only, non-destructive, idempotent. The description adds that the calculation is deterministic and uses true solar time correction, providing extra context beyond annotations. No contradictions.
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: first states purpose, second gives guidance. No wasted words, highly efficient.
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?
While the tool is complex with 14 parameters, the description covers purpose and key features. However, it does not describe the output format or list expected return fields, which is a gap given the absence of 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?
Schema description coverage is 100%, so the schema already documents parameters. The description adds a tip about accuracy but does not further explain parameter meanings or relationships, so it adds minimal value.
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 a Bazi/Four Pillars chart with specific features (true solar time, Day Master, Da Yun cycles, branch interactions). It does not explicitly distinguish from sibling tools, but the purpose is sufficiently clear.
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 advises passing longitude and timezone/timezoneId for best accuracy, providing some guidance. However, it lacks explicit when-to-use vs alternatives or conditions under which this tool should be preferred over siblings.
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 deterministic Earthly Branch interactions for natal charts, synastry checks, annual triggers, or target-branch comparison. Covers clashes, combinations, trines, directionals, punishments, destructions, and harms.
| 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. | |
| monthBranch | Yes | Natal month branch. | |
| annualBranch | No | Optional annual or target branch for dynamic interaction detection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, destructiveHint false, idempotentHint true; description confirms deterministic nature, no contradictions.
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, front-loaded with purpose and scope, 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 simplicity and full schema coverage, description adequately covers usage and return types (list of interaction types). No output schema needed.
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 has 100% coverage with descriptions. Description adds minimal extra meaning (e.g., hourBranch can be omitted, annualBranch for dynamic detection), but baseline 3 applies.
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?
Description states specific verb 'detect' and resource 'Earthly Branch interactions', and lists categories (clashes, combinations, etc.). Distinguishes from siblings 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?
Explicitly mentions use cases: natal charts, synastry, annual triggers, target-branch comparison. Provides clear context but does not explicitly exclude alternatives.
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. Dates show when Glama detected each change.
v0.1.0calculate_bazi_chartcalculate_true_solar_timedetect_bazi_interactionsget_openfate_bazi_policyget_openfate_bazi_resourcesreverse_bazi_to_solar_timesEach tool targets a distinct operation: chart calculation, solar time correction, interaction detection, policy retrieval, resource listing, and reverse lookup. No overlapping functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., calculate_bazi_chart, detect_bazi_interactions), making the naming predictable and clear.
With 6 tools, the server is well-scoped for a specialized Bazi domain. Each tool serves a distinct purpose without redundancy or unnecessary complexity.
The tool set covers the full lifecycle for Bazi chart calculations: time adjustment, chart generation, interaction analysis, reverse lookup, and supporting resources/policy. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
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.
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/openfate-ai/openfate-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
