A calculation-first MCP server for Four Pillars, True Solar Time, and auditable chart data
Large language models are good at explaining ideas in natural language. They are much less reliable when a task depends on exact calendar conversion, timezone rules, solar-time correction, or repeated symbolic lookups.
Bazi, also called the Four Pillars of Destiny, contains all of those requirements. A chart depends on a recorded birth date and time, the correct timezone and daylight-saving rule, the calendar convention being used, and sometimes a True Solar Time correction based on location. If an AI assistant tries to recreate that arithmetic from memory, a polished explanation can begin with the wrong pillars.
That is why we built the open-source OpenFate Bazi MCP server. It gives compatible AI clients deterministic chart tools while leaving conversation and interpretation to the client.
Separate calculation from explanation
The architecture has a simple boundary:
- A calculation engine validates the input and produces the chart data.
- The MCP server exposes that data through structured tools.
- The connected AI client explains the returned result without recalculating it.
This does not make a metaphysical interpretation scientifically proven. It solves a narrower engineering problem: the explanation can be tied to a specific, reproducible calculation instead of arithmetic improvised by a language model.
The public MCP server runs locally over standard input and output. It wraps the public calculation engine and does not need to send a birth record to an OpenFate web endpoint.
Install and run it
The package is available from npm and can be started with:
npx -y @openfate/bazi-mcp
A typical MCP client configuration follows this shape:
{
"mcpServers": {
"openfate_bazi": {
"command": "npx",
"args": ["-y", "@openfate/bazi-mcp"]
}
}
}
Restart the client after changing its MCP configuration. The exact settings screen and configuration file vary by client.
What the server exposes
The server currently provides tools for:
- calculating a Bazi chart;
- detecting Earthly Branch interactions;
- calculating True Solar Time;
- finding possible solar times from a known Bazi chart;
- reading the calculation policy; and
- retrieving supporting OpenFate Bazi resources.
A calculated chart can include normalized solar and lunar datetimes, the applied calculation policy, True Solar Time details, enriched Four Pillars data, hidden stems, Ten Gods, Na Yin, void branches, growth stages, and Da Yun timing.
Returning this data as structured fields is useful for more than display. An AI client can cite the exact pillar or interaction behind an explanation, ask for missing location data before applying solar-time correction, and avoid silently switching calculation conventions halfway through a conversation.
A safer agent workflow
Consider a user who asks:
Calculate my Bazi chart and explain the strongest relationship patterns.
A calculation-first agent should not immediately invent four pillars. It should first collect the birth date, recorded time, location, timezone, daylight-saving context, and any other input required by the selected policy. It can then call the MCP chart tool, retain the returned policy metadata, and base its explanation on those results.
If location data is available, the agent can use the True Solar Time tool rather than estimating the correction in prose. If the user later asks why the result differs from another calculator, the stored input and policy metadata provide a concrete starting point for comparison.
The same boundary also helps with uncertainty. The server supplies calendrical and chart data. The AI client remains responsible for the quality, tone, and limits of its interpretation. A responsible explanation should distinguish calculated fields from subjective meaning and should avoid guaranteed predictions, medical claims, or financial instructions.
Why MCP is a useful fit
MCP lets a general-purpose assistant call a specialized tool without pretending that the language model itself contains a reliable calendar engine. The pattern applies beyond Bazi: use deterministic software for exact domain calculations, then use language models for explanation, follow-up questions, and presentation.
For developers, this creates clearer ownership. Calculation bugs belong in the engine and can be covered by deterministic tests. Transport behavior belongs in the MCP server. Conversation behavior belongs in the client. Each layer can change without hiding the boundary between fact generation and narrative generation.
The OpenFate Bazi MCP server is MIT licensed. You can inspect the source, report issues, and contribute on GitHub. The package is available as @openfate/bazi-mcp, and the developer overview explains the public integration.
Top comments (1)
The separation of calculation from explanation in your MCP architecture is a smart approach, especially given the complexities involved in Bazi charting. By ensuring that the AI client only interprets deterministic outputs, you significantly reduce the risk of errors that could mislead users. It might be beneficial to consider adding a caching mechanism for frequently requested calculations, which could improve performance, especially for high-traffic scenarios. If you're looking for further development support or enhancements in this area, I’d be happy to discuss a paid collaboration. How do you foresee scaling this solution as user demand grows?