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., "@timemap-mcp What's the day quality for today?"
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.
Chinese metaphysics calculations for AI agents — BaZi, Tong Shu, Feng Shui, and more.
An MCP (Model Context Protocol) server that gives AI agents access to accurate Chinese metaphysics calculations. Built on a verified engine with 740+ tests checked against Joey Yap reference data.
I discovered BaZi in 2017 and approached it with healthy skepticism — it wasn't the first system of correspondences I'd studied. But this one stayed with me.
Over the years I've studied under Master Joey Yap through courses, seminars, his Telegram community, and many books. As a developer, I naturally started building tools — small "clocks" that map the cyclic energy movements described in Chinese metaphysics.
timemap-mcp is born from those years of study and building. I wanted to make these calculations accessible to everyone through AI, with the accuracy that practitioners expect. A full interactive app (TimeMap) is on the way — this MCP server is the engine that powers it, now available for any AI agent to use.
Related MCP server: mcp-luopan
Add to your claude_desktop_config.json:
{
"mcpServers": {
"timemap": {
"command": "uvx",
"args": ["timemap-mcp"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"timemap": {
"command": "uvx",
"args": ["timemap-mcp"]
}
}
}That's it. No API keys, no config needed.
Note: The first run downloads the DE421 ephemeris file (~31 MB) for precise solar term calculations. This is a one-time download cached in
~/.skyfield/.
Tool | Description | Natal needed? |
| Complete BaZi chart — Four Pillars, Luck Pillars, Life Gua, 10 Gods, auxiliary stars | Yes |
| Year, Month, Day pillars for any date | No |
| Tong Shu indicators — Day Officer, 28 Constellation, Flying Star | No |
| Check natal clashes, combinations, and breakers for a date | Yes |
| 12 two-hour energy blocks for any day | No |
| 10-year Luck Pillar timeline (decades of fortune) | Yes |
| Xuan Kong Da Gua hexagram by stem-branch pair | No |
| Exact date of any of the 24 solar terms | No |
Try asking your AI agent:
"Calculate my BaZi chart. I was born January 26, 1994 at 7:11 AM, male."
"What's the day quality for today?"
"Show me the hourly pillars for tomorrow."
"What are my luck pillars? Born March 15, 1985 at 10:30 AM, female."
"Look up the hexagram for Ren Zi."
"When is Lichun (Start of Spring) in 2026?"
"Check if today has any clashes with my natal chart."
Dates: ISO 8601 — 1994-01-26
Times: 24-hour local time — 07:11
Gender: male or female
Stems: Chinese (壬), pinyin (Ren), or index (8)
Branches: Chinese (子), pinyin (Zi), animal (Rat), or index (0)
Timezone (optional): IANA format — Asia/Kuala_Lumpur, Europe/Bucharest
The calculation engine behind this server is not a toy:
740+ automated tests covering every module
Verified against Joey Yap's Power Planner — pillar characters, Day Officers, 10 Gods mappings
Solar term boundaries computed via NASA JPL DE421 ephemeris (not table approximations)
Month boundaries follow Jie Qi (solar terms), not Gregorian dates — February pillar may start Feb 3 or 4 depending on the year
The free tier covers the fundamentals. Coming in v2 (premium):
10 Gods Strength — proprietary percentage algorithm (reverse-engineered, MSE=0.5)
Daily Score (0-100) — composite score with transparent 6-factor breakdown
Qi Men Dun Jia — destiny palace, annual chart, hourly interpretation
Monthly Energy — 10 Gods deltas, life area radar, emotional profiling
Daily Briefing — complete orchestrated daily digest
git clone https://github.com/cnick26/timemap-mcp.git
cd timemap-mcp
python -m venv .venv
.venv/Scripts/pip install -e ".[dev]" # Windows
# or: .venv/bin/pip install -e ".[dev]" # Linux/macOS
pytest -q # 740+ testspython scripts/sync_engine.py --source ../TimeMap/backend/app/engine
pytest -q # Verify everything still passesIf this project helps you, consider:
Starring the repo
Built with care, verified with rigor, shared with humility.
Check natal chart clashes and combinations for a specific date.
Args: date: ISO 8601 date to check, e.g. '2026-04-10' birth_date: Your birth date, e.g. '1994-01-26' birth_time: Your birth time as 'HH:MM', e.g. '07:11' timezone: IANA timezone (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| birth_date | Yes | ||
| birth_time | Yes | ||
| timezone | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'check,' which implies a non-destructive read operation. However, it does not disclose if there are side effects, auth requirements, or limitations. The description carries the full burden but offers minimal behavioral context.
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 short and front-loaded with the purpose, then lists arguments with examples. Every sentence is necessary and adds value, achieving high 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?
Given the output schema exists (so return values need not be explained) and 3 required parameters, the description adequately covers the tool's purpose and most parameters. It is complete enough for an agent to understand when and how to use it, though more detail on the type of interactions could help.
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, but the description compensates with clear examples for each parameter (e.g., ISO 8601 date, 'HH:MM' format, IANA timezone). This adds significant meaning beyond the schema's bare property names.
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 checks 'natal chart clashes and combinations for a specific date,' using a specific verb and resource. This distinguishes it from sibling tools like get_daily_pillars or get_day_quality.
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 clear context for using the tool with a date and birth info, but does not explicitly mention when not to use it or alternative tools. However, the examples and sibling names imply the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Year, Month, and Day pillars for any date.
Args: date: ISO 8601 date, e.g. '2026-04-10'
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only indicates a read operation via 'Get', but does not mention any other behavioral traits (e.g., authentication needs, performance, error conditions). This is minimal.
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 with two sentences, immediately stating the purpose and parameter format. Every sentence is necessary and front-loaded.
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 (one parameter, output schema exists), the description is mostly complete. It explains the input format but does not describe output structure or potential date range limitations, though the output schema likely covers the return values.
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 single parameter 'date' has 0% schema coverage, but the description adds format specification (ISO 8601) and an example. This meaningfully assists the agent beyond the raw schema, though it does not cover edge cases.
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 explicitly states the tool gets Year, Month, and Day pillars for any date, with a specific verb ('Get') and resource ('pillars'). It clearly distinguishes from siblings like get_hourly_pillars by specifying the temporal scope.
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 any date and provides an example format, but it lacks explicit guidance on when to use this tool versus siblings or any exclusions. The 'any date' phrasing is broad but functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Tong Shu day quality indicators — Day Officer, 28 Constellation, and Flying Star. No natal chart needed. Instant calculation.
Args: date: ISO 8601 date, e.g. '2026-04-10'
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Instant calculation' which implies speed, but does not disclose any limitations, side effects, or auth requirements. For a simple read tool, this is adequate but lacks depth.
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 very concise: two brief lines explaining purpose and constraints, followed by a structured Args section. Every sentence adds value and is front-loaded.
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 has only one parameter and an output schema exists (context signal), the description adequately explains what the tool returns (day quality indicators) and the input format. It is sufficiently complete for a simple lookup 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?
The description includes an Args section with the date parameter described as 'ISO 8601 date, e.g. '2026-04-10''. The schema has one required date string property with no format info, so the description adds meaningful format and example guidance.
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 that it gets Tong Shu day quality indicators, naming specific indicators (Day Officer, 28 Constellation, Flying Star). This is a specific verb+resource and distinguishes from siblings like get_daily_pillars or get_daily_interactions.
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 says 'No natal chart needed. Instant calculation.' which guides the user that this tool is appropriate for quick day quality queries without additional context. While it doesn't explicitly state when not to use, it provides useful context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the 12 two-hour pillar blocks for any date (23:00-22:59).
Args: date: ISO 8601 date, e.g. '2026-04-10'
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action (get) and input format, omitting whether the operation is read-only, idempotent, or has side effects. The term 'Get' implies reading but is not explicit.
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 and a parameters line. The purpose is front-loaded, and every word 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?
Given the single parameter and existence of an output schema, the description is adequate but minimal. It does not explain what 'pillar blocks' are or how they are returned, which may be insufficient for agents lacking domain knowledge.
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, so the description must compensate. It provides an ISO 8601 format example ('2026-04-10'), which adds clarity. However, it does not specify timezone or other nuances, so slightly below perfect.
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 retrieves '12 two-hour pillar blocks for any date', with a specific time range. The name 'get_hourly_pillars' aligns with the action, and it distinguishes from siblings like 'get_daily_pillars' by focusing on hourly blocks.
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 versus siblings. The description does not mention alternatives or conditions for use, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the 10-year Luck Pillar timeline (decades of fortune).
Args: birth_date: ISO 8601 date, e.g. '1994-01-26' birth_time: Local time as 'HH:MM', e.g. '07:11' gender: 'male' or 'female' timezone: IANA timezone (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | ||
| birth_time | Yes | ||
| gender | Yes | ||
| timezone | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions calculation but lacks disclosure on computational demands, data source, or any side effects. The output schema exists but description adds no behavioral context beyond the name.
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?
Concise one-line purpose followed by structured args with examples. Front-loaded and efficient, though could be slightly 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?
Output schema exists, so return values need not be explained. However, with 4 params and no annotations, description omits conceptual background on luck pillars and fails to fully differentiate from peers. Adequate but not 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 0%, so description must compensate. It provides format examples (ISO 8601, HH:MM, 'male'/'female', IANA timezone) but does not explain what the parameters mean or how they influence the calculation. Partial improvement over bare schema.
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 the 10-year Luck Pillar timeline with a specific verb and resource. It distinguishes from sibling tools like get_daily_pillars and get_natal_chart by focusing on decades of fortune.
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 vs. alternatives. The description lists sibling tools but provides no comparative context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate a complete BaZi natal chart with Four Pillars, Luck Pillars, Life Gua, and stars.
Args: birth_date: ISO 8601 date, e.g. '1994-01-26' birth_time: Local time as 'HH:MM', e.g. '07:11' gender: 'male' or 'female' timezone: IANA timezone, e.g. 'Asia/Kuala_Lumpur' (optional, improves accuracy near solar term boundaries)
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | ||
| birth_time | Yes | ||
| gender | Yes | ||
| timezone | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'calculate', implying read-only, but lacks details on auth, rate limits, or side effects. Mentions timezone improves accuracy, but overall minimal behavioral disclosure.
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: one for purpose, then a bulleted Args list with inline examples. No redundant information. Front-loaded with key action and output components.
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?
Output schema exists, so description does not need to detail return values. Input parameters are fully covered with examples and notes. Could briefly mention that chart includes all listed components, but 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?
Input schema has 0% description coverage. Description adds meaning with examples (e.g., '1994-01-26' for birth_date, '07:11' for birth_time) and clarifies format for timezone.
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?
Clearly states 'Calculate a complete BaZi natal chart with Four Pillars, Luck Pillars, Life Gua, and stars.' Differentiates from siblings like get_daily_pillars or get_luck_pillars which are subcomponents.
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?
Provides parameter descriptions with examples but no explicit when-to-use or when-not-to-use guidance. Context signals indicate siblings are sub-tools, but description does not compare.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the exact date of a solar term (Jie Qi) for any year.
There are 24 solar terms per year. Term 1 = Lichun (Start of Spring, ~Feb 4).
Args: year: Year to query, e.g. 2026 term_number: Solar term number 1-24 (1=Lichun, 2=Yushui, ..., 24=Dahan)
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| term_number | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the tool retrieves an exact date and gives an example (Lichun ~Feb 4). While it does not specify output format or error handling, the simplicity of the tool and presence of an output schema mitigate concerns.
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 brief and well-structured: a clear purpose sentence, an explanatory note about 24 terms, and concise parameter descriptions. Every sentence is informative and no words are wasted.
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 low complexity, the presence of an output schema (which covers return values), and distinct siblings, the description provides sufficient context. It answers what, how, and the range of inputs without missing essential details.
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 0% schema description coverage, the description compensates fully by explaining both parameters: year is a year like 2026, term_number is the solar term index 1-24 with examples. This adds significant meaning beyond the raw integer types.
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 retrieves the exact date of a solar term for any year, using specific verbs and resource. It is distinct from siblings like get_daily_pillars or get_natal_chart, which cover different concepts.
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 explains the tool's scope (any year, term numbers 1-24) but does not explicitly state when to use it over alternatives. However, the sibling context makes the usage obvious, as other tools serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the Xuan Kong Da Gua hexagram for a stem-branch pillar.
Args: stem: Heavenly Stem — Chinese ('壬'), pinyin ('Ren'), or index (0-9) branch: Earthly Branch — Chinese ('子'), pinyin ('Zi'), animal ('Rat'), or index (0-11)
| Name | Required | Description | Default |
|---|---|---|---|
| stem | Yes | ||
| branch | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a read-only lookup operation, but does not disclose any additional behavioral traits such as data sources, performance, or error conditions. It is adequate but not comprehensive.
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 very concise with a clear header and bullet-like parameter list. Every sentence serves a purpose, and there is no redundant or unnecessary 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?
The tool is simple, with only two required parameters and an output schema likely covering return values. The description fully explains the input parameters and the purpose, making it complete for effective use.
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, but the tool's description provides detailed semantics for both parameters: stem accepts Chinese, pinyin, or index; branch accepts Chinese, pinyin, animal, or index. This adds significant value beyond the schema's empty definitions.
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: looking up a Xuan Kong Da Gua hexagram for a stem-branch pillar. It specifies the exact resource (hexagram) and action (look up), and it is easily distinguishable from sibling tools like get_daily_pillars or get_natal_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 does not provide any guidance on when to use this tool versus alternatives. It lacks information about prerequisites, preferred scenarios, or when not to use it. The sibling tools are listed but no comparisons or exclusions are given.
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.3.0get_daily_interactionsget_daily_pillarsget_day_qualityget_hourly_pillarsget_luck_pillarsget_natal_chartget_solar_termlookup_hexagramEach tool targets a distinct aspect of Chinese astrology: daily interactions, pillars, quality, hourly pillars, luck pillars, natal chart, solar terms, and hexagrams. There is no overlap in purpose.
All tools follow a verb_noun pattern in snake_case, with most using 'get_' and one using 'lookup_'. This minor deviation is still consistent and predictable.
8 tools cover a comprehensive range of BaZi functionalities without being excessive. Each tool serves a clear purpose and contributes to the server's domain.
The tool set covers core BaZi operations: chart creation, pillar calculations, daily quality, solar terms, and hexagrams. A minor gap is the lack of a compatibility or relationship analysis tool, but the set is largely complete for individual chart analysis.
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.
Zi Wei Dou Shu for AI agents: free natal charts, six transit levels, and optional readings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cnick26/timemap-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
