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., "@zhiji-bazi 帮排个八字：男，1990年5月15日14:30，北京时间"
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.
输入出生时间，输出四柱、身强弱、格局、用神。
这是知己排盘的计算引擎，从生产环境拆出来开源的部分。它只做计算，不生成解读文案，也不做任何预测。
历法与四柱 — 公历、农历、节气、干支互转。立春换年、节气分月，晚子时的日柱归哪天给了三种规则
真太阳时 — 经度校正加时差方程。时差方程全年在 -14 到 +16 分钟之间波动，足以让时柱错一位，很多排盘实现恰好漏掉它
身强弱 — 按得令、得地、得势三要素打分
格局与用神 — 定格、判成败、取用神，含调候
MCP server — stdio 和 HTTP 双入口，AI agent 一行配置连上排盘
TypeScript — 带类型声明和源码，Node / Bun 直接用，唯一运行时依赖是 lunar-javascript
Related MCP server: shunshi-bazi-mcp
npm install zhiji-bazi # 或者 bun add zhiji-baziimport { computeChart, displayString } from "zhiji-bazi";
const r = computeChart({
birthDate: new Date("2000-01-01T04:00:00Z"), // 北京时间 2000-01-01 12:00
timeZone: "Asia/Shanghai",
isMale: true,
});
console.log(displayString(r.bazi)); // 己卯 丙子 戊午 戊午
console.log(r.strength.level); // strong
console.log(r.pattern.pattern); // zhengCai
console.log(r.yongShen.yongShen); // metal函数 | 干什么 |
| 一次算完：四柱 + 身强弱 + 格局 + 用神 |
| 只排四柱 / 从已知四柱建盘 |
| 真太阳时校正 / 时差方程 |
| 身强弱三要素打分 |
| 定格与成败 |
| 用神与调候 |
| 公历转农历 |
| 四柱文本 / 取日主 |
类型声明齐全，其余导出看 src/index.ts。
第一层，历法与四柱。 有唯一正确答案，可以拿天文数据核对。
第二层，真太阳时。 也有唯一正确答案。
很多排盘实现只做了经度校正，漏掉时差方程，而时柱以两小时为一界，时差方程那十几分钟足以让时柱错一位。
import { correctToTrueSolarTime, equationOfTime } from "zhiji-bazi";
// 乌鲁木齐用北京时间，真太阳时比钟表早两小时以上
const corrected = correctToTrueSolarTime({
date: new Date("2000-01-01T04:00:00Z"),
longitude: 87.6,
tzOffsetMinutesStandard: 480, // 必须是剥离夏令时之后的标准偏移
});
// 校正前时柱戊午，校正后丁巳，差一柱tzOffsetMinutesStandard 必须先剥离夏令时。夏令时只是把钟拨快了，不改变太阳的位置，用带夏令时的偏移会让标准子午线整体算错一个时区。
第三层，身强弱。 这一层开始有立场了。
第四层，格局与用神。 各流派口径差别很大，这里给的是一种算法口径。
包里带一个 MCP server，AI agent 可以直接连上算盘。
Claude Desktop、Cursor 这类启动子进程、走标准输入输出的客户端，配置里这样写：
{
"mcpServers": {
"zhiji-bazi": {
"command": "npx",
"args": ["-y", "zhiji-bazi-mcp"]
}
}
}想要 HTTP 而不是标准输入输出，跑 bun run mcp/server.ts，默认监听 8787，每个 IP 每分钟限 60 次，用 MCP_CALLS_PER_MIN 改。
两个入口都只有一个工具 bazi_compute，输入支持公历、农历、直接给四柱三种方式，给了 longitude 就按真太阳时校正。initialize 返回的 instructions 字段里写了转述结果时该守的边界，客户端会把它放进模型的上下文。
不想自己跑的话，知己排盘有托管的端点，后面是完整引擎：
https://zhijipaipan.com/bazi-api/mcp
https://api.szxishe.cn/mcp格局判定有已知的假阳性。 内部审计发现从格判得偏松，会把一些本该按正格论的盘判成从格。那轮审计找到六个根因，代码里 R1、R2严、R5 几处注释就是修正留下的。现在比审计前收紧了，但不能说已经解决。
身强弱、格局、用神是有争议的判定。 同一张盘，格局派、旺衰派、盲派会给出不同甚至相反的结论。这个仓库实现的是一种口径，不是标准答案。拿它的输出对用户说话时，建议说明这一点。
阈值是调出来的，不是推导出来的。 强弱分档、成格败格的边界都来自实践校准，换一批盘重调，结果会变。
没有跨实现的一致性保证。 跟其他排盘软件对不上是常态，尤其在晚子时、闰月、节气交界这几个地方。这里的选择在代码注释里都写了理由。
神煞、大运流年、关系合盘、纳音、地理五行、AI 解读文案，这些都不在。想要完整结果去 zhijipaipan.com，或者连上面那个托管的 MCP 端点。
八字属于传统文化范畴，不构成任何形式的决策依据。这个仓库提供的是符号系统的计算，不预测事件，不给投资、医疗、法律建议。
出生时间是个人数据。仓库里的测试和示例一律用合成盘或者历法边界日期，不含任何真实个人信息，建议你也这么做。
bun install
bun test # 覆盖历法、立春换年、晚子时、时差方程、端到端
bun run typecheck
bun run build输入出生时间（公历、农历或直接给四柱），返回八字命盘 JSON：四柱、身强弱、格局、用神。只做计算，不含解读文案、不做预测；转述结果时给结构不给吉凶断语，并说明身强弱与格局各流派口径不同。Compute a BaZi (Four Pillars) chart from a birth datetime. Returns structured data only, no predictions or readings.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | ||
| hour | No | ||
| year | No | ||
| month | No | ||
| isMale | No | 男=true，影响大运顺逆 | |
| minute | No | ||
| pillars | No | inputMode=pillar 时用，干支各两字 | |
| timeZone | No | IANA 时区，默认 Asia/Shanghai | |
| inputMode | Yes | solar=公历，lunar=农历，pillar=直接四柱 | |
| longitude | No | 出生地经度。给了就按真太阳时校正 | |
| zishiRule | No | 晚子时日柱归属，默认 sameDay | |
| isLeapMonth | No | 农历闰月，inputMode=lunar 时用 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose that the tool is purely computational with no readings or predictions, and that output conventions for 身强弱/格局 are school-dependent — a genuinely useful caveat for downstream relaying. It does not cover auth, rate limits, or error behavior, but for a deterministic compute tool those are lower-stakes. This is meaningful added context beyond the schema.
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?
Front-loaded with purpose (input forms, then output payload), and the behavioral constraints follow. The bilingual duplication means the Chinese prohibition on interpretation and the English "no predictions or readings" say the same thing twice, which is the only real slack in otherwise efficient text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly enumerates the return payload (四柱、身强弱、格局、用神), which is the key completeness requirement. It also covers the non-obvious school-convention caveat. What it omits is guidance on calendar-boundary edge cases for a 12-parameter, nested-object input, which keeps it short of a 5.
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?
With 12 parameters and only 58% schema description coverage, the description must add some parameter meaning, and it does explain the three input modes (公历/农历/直接四柱) that drive inputMode, pillars, and isLeapMonth. However, it adds nothing for year/month/day/hour/minute semantics (e.g. whether the year boundary follows solar terms or true solar time interplay), leaving several parameters undocumented in both schema and description. Baseline-adjacent 3.
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 names a specific verb and resource ("Compute a BaZi (Four Pillars) chart from a birth datetime") and enumerates the returned artifacts (四柱、身强弱、格局、用神), so an agent knows exactly what is produced. It explicitly frames the tool as computation-only, which distinguishes its purpose from any interpretation-oriented tool. No siblings exist, so no differentiation is required.
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 clear usage boundaries: "只做计算，不含解读文案、不做预测" with the instruction to relay structure rather than auspicious/inauspicious verdicts ("转述结果时给结构不给吉凶断语"), plus a caveat that 身强弱 and 格局 definitions vary by school. There are no alternative tools to route between, so only the alternative *framing* (interpretation) is excluded rather than a sibling tool — hence a 4 rather than 5.
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.2.1bazi_computeScored across 1 tool
With only one tool, there is no possibility of overlap or misselection; its purpose (computing a BaZi chart) is unambiguous.
A single tool named bazi_compute uses a clear, readable snake_case convention with no competing styles to create inconsistency.
One tool is slightly thin relative to the typical 3-15 range, but it is well-scoped for a deliberately narrow, compute-only server that does not offer interpretation or prediction.
For its stated purpose of chart computation, the surface is complete: it accepts multiple input formats (solar, lunar, or raw pillars) and returns the core structured outputs (four pillars, strength, structure, useful god).
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…
BaZi four pillars, Chinese zodiac, lunisolar calendar and almanac days for AI agents.
Official Divine API MCP for Western Astrology: Natal, Synastry, Transit, Composite, Progressions.
