Bazi MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping purposes that could cause confusion. buildBaziFromLunarDatetime, buildBaziFromSolarDatetime, and getBaziDetail all appear to generate bazi (eight characters) information from datetime inputs, with getBaziDetail explicitly stating it accepts both solar and lunar inputs. This creates ambiguity about which tool to use for bazi generation, though getBaziDetail's description clarifies parameter requirements.
Naming Consistency3/5
The naming follows a mixed convention with some consistency issues. Four tools use verb_noun patterns (buildBaziFrom..., getBaziDetail, getChineseCalendar, getSolarTimes), but buildBaziFrom... uses camelCase while get... tools use lowercase. The verbs are reasonably descriptive but the casing inconsistency reduces predictability.
Tool Count5/5
Five tools is well-scoped and appropriate for a bazi/Chinese calendar server. Each tool appears to serve a distinct function within the domain, and the count is neither too sparse nor overwhelming for the apparent scope of Chinese astrology and calendar operations.
Completeness4/5
The tool set covers core bazi generation from both calendar systems, detailed bazi analysis, Chinese calendar information, and solar time conversion from bazi. Minor gaps might include more advanced bazi analysis features or additional calendar functions, but the surface supports basic workflows without obvious dead ends.
Average 3.1/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool '获取八字信息' (gets eight-character information), which implies a read-only operation, but doesn't clarify if it requires authentication, has rate limits, or what the output format looks like (especially since there's no output schema). The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '根据农历时间、性别来获取八字信息。' (Get eight-character information based on lunar datetime and gender). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral details (e.g., output format, error handling), usage guidelines compared to siblings, and doesn't compensate for the absence of annotations or output schema. The high schema coverage helps, but the description alone is insufficient for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'eightCharProviderSect' explains the configuration for midnight hour, 'gender' specifies 0 for female and 1 for male, 'lunarDatetime' gives an example format). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据农历时间、性别来获取八字信息' (Get eight-character information based on lunar datetime and gender). It specifies the verb '获取' (get) and the resource '八字信息' (eight-character information), which is distinct from sibling tools like 'buildBaziFromSolarDatetime' (which uses solar datetime) or 'getBaziDetail' (which likely provides detailed analysis). However, it doesn't explicitly differentiate from all siblings (e.g., 'getChineseCalendar' might overlap in lunar context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'buildBaziFromSolarDatetime' (for solar datetime input) or 'getBaziDetail' (for detailed analysis), nor does it specify prerequisites or exclusions. Usage is implied by the parameters (lunar datetime and gender), but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what the tool does (get bazi information), it doesn't describe important behavioral aspects: what format the output returns (since there's no output schema), whether this is a read-only operation, potential error conditions, or any performance characteristics. The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Chinese sentence that directly states the tool's purpose. There's zero waste or unnecessary elaboration. It's appropriately sized for what it communicates, though it could benefit from more contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description is insufficiently complete. For a tool that calculates bazi (a complex Chinese metaphysical system), the description doesn't explain what 'bazi information' includes, doesn't mention the optional 'eightCharProviderSect' parameter that affects calculations, and provides no context about the tool's behavior or output format. The description leaves too many questions unanswered for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters thoroughly. The description mentions '阳历时间' (solar calendar time) and '性别' (gender), which map to two of the parameters, but doesn't mention the 'eightCharProviderSect' parameter at all. Since the schema does the heavy lifting, the baseline score of 3 is appropriate - the description adds minimal value beyond what's already in the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据阳历时间、性别来获取八字信息' (Get eight characters/bazi information based on solar calendar time and gender). It specifies the verb ('获取' - get/obtain) and the resource ('八字信息' - eight characters/bazi information). However, it doesn't explicitly differentiate from its sibling tools like 'buildBaziFromLunarDatetime' or 'getBaziDetail', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'buildBaziFromLunarDatetime' (which uses lunar datetime) or 'getBaziDetail' (which might provide more detailed bazi information). There's no context about prerequisites, limitations, or appropriate scenarios for this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the default behavior (today if no datetime provided), which is useful. However, it doesn't disclose other behavioral traits like what specific information is returned (e.g., auspicious activities, taboos), whether there are rate limits, error conditions, or cultural/regional considerations. For a tool with no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that front-loads the core purpose ('获取...黄历信息') and includes the key detail about default behavior. There is zero waste or redundancy, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what '黄历信息' entails (e.g., structure, fields like lucky directions or activities), potential errors, or cultural context. For a tool that likely returns rich cultural data, this lack of detail makes it inadequate for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'solarDatetime' well-documented in the schema (ISO format, example). The description adds marginal value by clarifying the default (today) and that it's Gregorian time, but doesn't provide additional semantic context beyond what the schema already covers. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '黄历信息' (Chinese calendar/almanac information), specifying it's for a given Gregorian date. It distinguishes from siblings like getBaziDetail (which provides detailed Bazi analysis) and getSolarTimes (which provides solar terms). However, it doesn't explicitly differentiate from buildBaziFromSolarDatetime, which also uses solar datetime input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it retrieves Chinese calendar information for a specified Gregorian date (defaulting to today). It doesn't provide explicit when-not-to-use guidance or name alternatives, though the sibling tools suggest different purposes (Bazi calculation vs. calendar info). The default behavior (today if unspecified) is helpful but not comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format ('YYYY-MM-DD hh:mm:ss') with an example, which is helpful. However, it lacks critical details such as whether the tool is read-only or has side effects, error handling, rate limits, or authentication needs. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences: the first states the purpose and output format, and the second provides a concrete example. Every sentence adds essential information without redundancy, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with full schema coverage and no output schema, the description is moderately complete. It explains the purpose and output format but lacks behavioral details (e.g., error cases, side effects) and usage context. For a simple conversion tool, this is adequate but has clear gaps in transparency and guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't explicitly discuss parameters, but the input schema has 100% coverage with a clear description for the single parameter 'bazi'. Since schema coverage is high, the baseline is 3. The description adds value by providing an example output format, which indirectly clarifies the parameter's purpose (converting Bazi to times), justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据八字获取公历时间列表' (Get Gregorian calendar time list based on Bazi). It specifies the verb ('获取' - get) and resource ('公历时间列表' - Gregorian calendar time list), making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'getBaziDetail', which might provide detailed Bazi analysis rather than time conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools such as 'buildBaziFromLunarDatetime' or 'buildBaziFromSolarDatetime', which might be used for different conversion directions (e.g., from dates to Bazi). There's no context on prerequisites or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('获取八字信息') and parameter constraints. It doesn't disclose important behavioral traits like: what format the BaZi information is returned in, whether this is a read-only operation, potential rate limits, error conditions, or authentication requirements. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The first sentence states the purpose, and the second sentence provides critical usage guidance about parameter exclusivity. Every sentence earns its place with no wasted words. The information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's no output schema and no annotations, the description is incomplete. It doesn't explain what '八字信息' (BaZi information) actually contains or what format it's returned in. For a tool that presumably returns complex astrological data, this is a significant gap. The description adequately covers input constraints but fails to address the output, which is crucial for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all 4 parameters thoroughly. The description adds some value by clarifying the mutual exclusivity rule for solarDatetime and lunarDatetime ('必须传且只传其中一个'), which isn't captured in the schema. However, it doesn't add meaningful semantic context beyond what the schema already provides for the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据时间（公历或农历）、性别来获取八字信息' (Get BaZi information based on time (solar or lunar) and gender). It specifies the verb ('获取' - get) and resource ('八字信息' - BaZi information). However, it doesn't explicitly differentiate from siblings like 'buildBaziFromLunarDatetime' or 'buildBaziFromSolarDatetime', which appear to serve similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'solarDatetime和lunarDatetime必须传且只传其中一个' (solarDatetime and lunarDatetime must be passed and only one of them). This tells the agent when to use which parameter. However, it doesn't explain when to choose this tool over the sibling tools like 'buildBaziFromLunarDatetime' or 'buildBaziFromSolarDatetime', which appear to be alternatives for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bazi-mcp MCP server](https://glama.ai/mcp/servers/cantian-ai/bazi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cantian-ai/bazi-mcp)

Score Badge

Copy to your README.md:

[![bazi-mcp MCP server](https://glama.ai/mcp/servers/cantian-ai/bazi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cantian-ai/bazi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cantian-ai/bazi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server