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., "@tyme-bazi-mcp Get four pillars for 1990-05-15T14:30:00"
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.
tyme-bazi-mcp is a Windows-local stdio MCP server for Chinese calendar and Four Pillars calculations, powered by Tyme4py.
It provides deterministic calendar and Four Pillars calculations through the official Python MCP SDK's FastMCP. The server uses the stdio transport and does not implement HTTP.
This project calculates calendar and Four Pillars data only. It does not provide fortune-telling interpretations, life predictions, date-selection recommendations, auspiciousness explanations, or diary writing.
Related MCP server: Lunar Calendar MCP Server
Python >=3.10
An MCP client that supports stdio servers
The project dependencies are pinned by uv.lock:
tyme4py==1.5.0
mcp==1.26.0
Clone the repository and synchronize the environment with uv:
git clone https://github.com/Zojekin/tyme-bazi-mcp.git
cd tyme-bazi-mcp
uv syncuv sync creates or updates the project environment according to pyproject.toml and uv.lock.
Start the stdio MCP server with:
uv run python server.pyThe process communicates through standard input and standard output. Do not treat its stdout as a human-readable command-line interface; an MCP client should manage the protocol connection.
Configure your MCP client as a local stdio server. The exact configuration format depends on the client, but the command and arguments are:
Command: uv
Arguments: run --directory <absolute-path-to-repository> python server.py
For example, the equivalent command is:
uv run --directory C:\path\to\tyme-bazi-mcp python server.pyIf the client requires separate fields, place uv in the command field and each item in run, --directory, the repository path, python, and server.py in the arguments list. Follow the configuration syntax documented by your MCP client; this README intentionally does not assume a client-specific schema.
The server exposes four MCP tools:
get_day_pillarsReturns the date-level year, month, and day pillars. This is a three-pillar result and does not generate a time pillar.
get_four_pillarsCalculates the year, month, day, and time pillars, as well as the complete Four Pillars result, from an exact local civil time. It also returns contextual information around the relevant solar-term boundary.
get_calendar_contextReturns date-level calendar context, including:
Solar terms
The previous, current, and next solar terms
Solar-term times
Solar-term day sequence information
is_jie and is_qi
Jianchu Twelve Officers (建除十二值神)
This tool does not provide date-selection recommendations, auspiciousness judgments, or explanations of what is suitable or unsuitable for a date.
get_natural_calendar_contextReturns natural-calendar context including:
The 72 pentads
Moon phases
The Three Fu periods
The Nine Nine period
Items that do not apply to the requested date return a structured inactive status rather than being silently omitted.
The server currently applies these fixed rules:
Only timezone=Asia/Shanghai is accepted.
Only time_mode=civil is accepted.
True solar time is not used.
The day pillar changes at 23:00:00, with times from 23:00:00 treated according to the next day for day-pillar calculation.
A date-level solar-term label must not be used as a substitute for precise-time Four Pillars boundary evaluation.
Date input uses YYYY-MM-DD.
Local date-time input uses YYYY-MM-DDTHH:mm:ss.
Invalid input is not silently corrected.
The server does not automatically add a missing time or seconds.
Results include engine-version, rule, and semantic-layer information so that consumers can distinguish date-level context from precise-time Four Pillars calculations.
Run the test suite with:
uv run pytestRun the stdio smoke test with:
uv run python tests/stdio_smoke.pyIf you want to use the included Windows PowerShell publishing script, run:
powershell -ExecutionPolicy Bypass -File .\publish.ps1The script runs pre-release and post-release tests together with the stdio smoke test. If a publishing step fails, it rolls back the changes made by the script.
This project is limited to deterministic Chinese calendar and Four Pillars calculations. It does not perform:
Fortune-telling interpretations
Life or personality predictions
Date-selection recommendations
Auspiciousness explanations or judgments
Diary or note writing
This project depends on Tyme4py, an independent MIT-licensed project by 6tail:
Repository: https://github.com/6tail/tyme4py
License: MIT
This project uses Tyme4py as a dependency and does not copy its source code.
This project is licensed under the MIT License. See LICENSE.
Copyright (c) 2026 Zojekin
tyme-bazi-mcp 是一個運行於 Windows 本機的 stdio MCP 服務，用於執行中國曆法和四柱計算，底層由 Tyme4py 提供支援。
項目使用官方 Python MCP SDK 的 FastMCP 實現 MCP 服務，通過 stdio 傳輸與客戶端通信，不實現 HTTP 服務。
本項目只進行曆法和四柱的確定性計算，不提供命理斷語、人生預測、擇日宜忌、吉凶解釋或日記寫入功能。
Python >=3.10
支援 stdio 服務的 MCP 客戶端
項目依賴由 uv.lock 鎖定：
tyme4py==1.5.0
mcp==1.26.0
克隆倉庫，並使用 uv 同步項目環境：
git clone https://github.com/Zojekin/tyme-bazi-mcp.git
cd tyme-bazi-mcp
uv syncuv sync 會根據 pyproject.toml 和 uv.lock 創建或更新項目環境。
使用以下命令啟動 stdio MCP 服務：
uv run python server.py進程通過標準輸入和標準輸出進行 MCP 協議通信。不要把 stdout 當作面向使用者的命令行界面；應由 MCP 客戶端管理協議連接。
請將本項目配置為本地 stdio 服務。具體配置格式取決於客戶端，但命令和參數如下：
命令：uv
參數：run --directory <倉庫絕對路徑> python server.py
對應的命令示例：
uv run --directory C:\path\to\tyme-bazi-mcp python server.py如果客戶端要求分別填寫 command 和 args 欄位，請將 uv 填入 command，並按順序將 run、--directory、倉庫路徑、python 和 server.py 填入參數列表。請遵循所用 MCP 客戶端的配置語法；本文檔不假定某個客戶端的專用配置格式。
服務提供以下四個 MCP 工具：
get_day_pillars返回日期級的年柱、月柱和日柱。這是三柱結果，不生成時柱。
get_four_pillars根據精確的本地民用時間計算年柱、月柱、日柱、時柱和完整八字，並返回相關節氣邊界的上下文信息。
get_calendar_context返回日期級曆法上下文，包括：
節氣
前一個、當前和後一個節氣
節氣時間
節氣日序信息
is_jie 和 is_qi
建除十二值神
該工具不提供擇日建議、吉凶判斷，也不解釋某個日期宜做或不宜做什麼。
get_natural_calendar_context返回自然曆法上下文，包括：
七十二候
月相
三伏天
數九
對於不適用於請求日期的項目，結果會返回結構化的 inactive 狀態，而不是靜默省略該項目。
服務目前採用以下固定規則：
只接受 timezone=Asia/Shanghai。
只接受 time_mode=civil。
不使用真太陽時。
日柱在 23:00:00 起切換；進行日柱計算時，23:00:00 及之後的時間按下一天處理。
日期級節氣標籤不能替代精確時刻的四柱邊界判斷。
日期輸入格式為 YYYY-MM-DD。
本地日期時間輸入格式為 YYYY-MM-DDTHH:mm:ss。
不會靜默修正非法輸入。
不會自動補充缺失的時間或秒數。
結果會包含引擎版本、計算規則和語義層級信息，便於調用方區分日期級上下文與精確時刻四柱計算。
運行測試套件：
uv run pytest運行 stdio smoke test：
uv run python tests/stdio_smoke.py如需使用隨附的 Windows PowerShell 發布腳本，請運行：
powershell -ExecutionPolicy Bypass -File .\publish.ps1該腳本會執行發布前測試、發布後測試以及 stdio smoke test。若發布步驟失敗，腳本會回滾其所作的更改。
本項目僅用於中國曆法和四柱的確定性計算，不執行以下工作：
命理斷語或其他命理解釋
人生或性格預測
擇日宜忌建議
吉凶解釋或判斷
日記或筆記寫入
本項目依賴由 6tail 獨立開發的 MIT 許可證項目 Tyme4py：
許可證：MIT
本項目將 Tyme4py 作為依賴使用，不複製其源代碼。
本項目採用 MIT 許可證，詳見 LICENSE。
Copyright (c) 2026 Zojekin
Return solar-term and Twelve Duty calendar facts.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| timezone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'Return... facts,' implying a read operation, but fails to mention any edge cases, parameter behavior, or output format. There is no context about what happens if date/timezone are omitted.
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 a single, focused sentence with no wasted words. It starts with the action verb and immediately states the core output, making it optimally concise.
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?
The tool is a simple read with two parameters and no output schema, so the description must explain the parameters and what the return value looks like. It does neither, leaving the agent without enough context to correctly invoke the tool or interpret results.
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?
The schema has 0% description coverage and the description does not mention the 'date' or 'timezone' parameters at all. While their names hint at their purpose, the description adds no additional meaning about format, defaults, or how they affect the returned facts, which is insufficient given the low coverage.
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 uses a clear verb 'Return' and names specific resources: 'solar-term and Twelve Duty calendar facts.' This distinguishes it from sibling tools like get_day_pillars and get_four_pillars, though terms like 'Twelve Duty' are unexplained jargon.
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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what it returns, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return date-level year, month and day pillars (never an hour pillar).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| timezone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It does disclose that only year, month, and day pillars are returned (and never an hour pillar), which is a meaningful constraint. However, it says nothing about side effects, return format, or error behavior, though for a simple query tool this may be sufficient.
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 a single, informative sentence that front-loads the main purpose. Every word earns its place, and there is zero redundancy or 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?
Given the tool's simplicity (2 params, no output schema), the description provides a clear statement of what is returned. However, the complete lack of parameter semantics makes it less than fully self-sufficient. It is adequate but with a clear gap in parameter documentation.
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?
The input schema has two parameters (date, timezone) with no descriptions, and schema description coverage is 0%. The description does not compensate by explaining what these parameters mean, their format, or how timezone affects the result. This leaves the agent without any guidance on how to fill the parameters.
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 a specific verb ('Return') and resource ('date-level year, month and day pillars'), explicitly excluding hour pillars. This distinguishes it from sibling tools like get_four_pillars, which likely includes the hour pillar.
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 implied usage is that this tool is for retrieving date-level pillars, but there is no explicit guidance on when to use it versus alternatives or when not to use it. The 'never an hour pillar' clause hints at a distinction but does not name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return exact civil-time four pillars using the fixed late-zi rule.
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | ||
| local_datetime | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'fixed late-zi rule' but does not explain what that entails, nor does it address timezone handling, edge cases, or return format. The phrase 'exact civil-time' hints at precision but omits critical behavioral details needed for safe usage.
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 a single, front-loaded sentence that directly states the tool's purpose and rule. It contains no redundant words and earns its place, though it is brief. The structure is efficient and easy to parse.
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?
This tool has a moderate complexity (four-pillar calculation), but the description does not explain what 'four pillars' are, how the fixed late-zi rule is applied, or what the output looks like. With no output schema and no annotations, the agent is left without enough context to confidently invoke the tool correctly. The description is too minimal for the task.
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?
The input schema has 0% description coverage, and the description does not compensate by explaining the parameters 'timezone' and 'local_datetime'. While the parameter names are self-explanatory to some degree, the description adds no information about their relationship or the 'fixed late-zi rule' in context, failing to help the agent understand required inputs.
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 identifies the tool's function: returning exact civil-time four pillars using a specific rule ('fixed late-zi rule'). The verb 'return' and resource 'four pillars' are explicit and distinguish it from siblings like 'get_day_pillars' or 'get_calendar_context' by specifying a unique calculation method.
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 usage for exact civil-time calculations with a particular rule, but it does not explicitly state when to use this tool versus alternatives such as 'get_day_pillars'. There are no exclusions or mention of alternative tools, leaving the agent to infer context from the rule mention alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return structured phenology, moon phase, summer-dog and shu-jiu facts.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| timezone | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it returns structured facts, implying a read-only operation, but provides no details about call behavior, return format beyond 'structured', potential costs, or side effects. This is insufficient for a complex multi-fact tool.
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 a single sentence with no filler or redundant information. It is efficiently front-loaded with the action ('Return') and the key resource types. There is zero waste, which is ideal for conciseness.
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?
The tool has no annotations, no output schema, and minimal description. It returns diverse types of information (phenology, moon phase, summer-dog, shu-jiu) but provides no explanation of what these are, how they are computed, or how the parameters influence them. The description is not complete enough for an agent to understand the tool's full behavior or outputs.
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?
The input schema has 0% description coverage, and the description does not compensate. The two parameters, 'date' and 'timezone', are not explained in the description; it does not state how they affect the output, what formats are expected, or whether they are required. With no parameter semantics conveyed, the agent cannot confidently construct valid calls.
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 specific types of natural calendar information (phenology, moon phase, summer-dog, shu-jiu facts) with a specific verb 'Return'. It is understandable and distinct from siblings like get_day_pillars and get_four_pillars, though it does not explicitly differentiate from get_calendar_context.
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 is provided on when to use this tool versus alternatives. Sibling tools like get_calendar_context and get_day_pillars exist, but the description gives no context on selection criteria or prerequisites, leaving the agent to guess when this tool is appropriate.
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.1.0get_calendar_contextget_day_pillarsget_four_pillarsget_natural_calendar_contextScored across 4 tools
The tools are mostly distinct: get_day_pillars explicitly excludes the hour pillar while get_four_pillars includes it, and the two calendar tools cover different fact types (solar terms vs. phenology). However, get_day_pillars and get_four_pillars overlap on year/month/day pillars, and the calendar vs. natural calendar distinction could still cause some initial confusion.
All tool names follow a consistent 'get_' + noun phrase pattern, using snake_case throughout. The naming clearly indicates the resource being retrieved: pillars, four pillars, calendar context, and natural calendar context.
With only 4 tools, this server is tightly scoped for the niche BaZi/calendar domain. Each tool provides a distinct, meaningful piece of information without redundancy or unnecessary bloat.
The set covers the essential BaZi queries: date-level pillars, full four pillars, solar terms, and natural calendar facts. Minor gaps exist, such as a dedicated hour-pillar retrieval (though this is included in get_four_pillars) or lunar date queries, but the core workflow is well-supported.
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.
Read-only Bazi, True Solar Time, and Chinese almanac tools in English and Traditional Chinese.
BaZi (八字) MCP gateway + 玄学社区. 12 tools (4 fortune + 5 forum + 3 meta). x-api-key required.
Generate BaZi charts from birth details. Explore Four Pillars, solar terms, and Luck Pillars for d…
