The Mingli MCP Server provides deterministic Chinese astrology calculations for Zi Wei Dou Shu (Purple Star Astrology) and BaZi (Four Pillars of Destiny), returning structured results from birth data inputs.
Zi Wei Dou Shu (紫微斗数)
Generate a full birth chart with 12 palaces, major/minor stars, and Four Transformations (四化), with optional true solar time correction via longitude/latitude
Query fortune periods: decadal (大限), yearly (流年), monthly (流月), daily (流日), and hourly (流时)
Deep-dive analysis of any specific palace (e.g., 命宫, 财帛宫, 官禄宫)
BaZi (八字)
Generate a Four Pillars chart with Heavenly Stems, Earthly Branches, Ten Gods (十神), hidden stems (地支藏干), five-element scores, and zodiac sign
Query fortune periods: age-based decade periods and annual stem/branch (流年)
Analyze five-element (金木水火土) balance, identify strongest/weakest/missing elements, and receive remediation suggestions
General
List all supported fortune systems (discovery tool)
Supports both solar and lunar calendar input, including leap months
6 languages: Simplified Chinese, Traditional Chinese, English, Japanese, Korean, and Vietnamese
Output in JSON or Markdown format
Available via stdio, HTTP, or WebSocket transports
Allows OpenAI Codex agents to access Chinese astrology tools for Zi Wei Dou Shu and BaZi chart generation, palace analysis, and fortune period queries.
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., "@Mingli MCP Server generate a Ziwei Doushu chart for someone born on 2000-08-16 at 3am, female"
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.
Mingli MCP is a deterministic Chinese astrology server for AI agents and MCP clients. It generates Zi Wei Dou Shu (紫微斗数 / Purple Star Astrology) and Bazi (八字 / Four Pillars of Destiny) charts from structured birth data, including the 12 palaces, stars, Four Pillars, Ten Gods, five elements, fortune periods, and date-based analysis.
中文简介： 一个面向 AI 工具的开源命理 MCP 服务，支持紫微斗数排盘、八字排盘、 宫位与五行分析，以及大限、流年、流月、流日和流时查询。
Example questions for an AI client:
“Generate my Zi Wei Dou Shu birth chart for 1990-01-01, 午时, male.”
“排一个 1992-08-16 辰时出生的女命八字，并分析五行强弱。”
“分析这个紫微命盘的财帛宫，并说明主要星曜配置。”
“Compare the five-element balance of these two Bazi charts.”
This project provides deterministic calendar and chart calculations for cultural, educational, and entertainment use. It is not medical, legal, financial, or other professional advice.
MCP tool | Result |
| Zi Wei Dou Shu birth chart with 12 palaces and stars |
| Decadal, yearly, monthly, daily, and hourly fortune periods |
| Focused analysis of one Zi Wei palace |
| Bazi Four Pillars, Ten Gods, hidden stems, and five elements |
| Simplified 10-year age period plus annual stem/branch |
| Five-element strength, balance, and missing elements |
| Machine-readable discovery of supported systems |
Unlike a generic LLM response, the tools first calculate a structured chart from calendar inputs and then return consistent JSON or Markdown. The same schemas can be used in chat, an automated workflow, or a custom Chinese astrology application.
Related MCP server: mcp-luopan
✅ 多命理系统支持: 采用插件化架构，轻松扩展新的命理系统
✅ 紫微斗数（已实现）
✅ 八字（已实现）⭐ 新增
🔄 西方占星（预留接口）
✅ 多语言支持: 紫微斗数宫位与星曜术语支持6种语言；八字核心标签目前以中文为主
🇨🇳 简体中文 (zh-CN)
🇹🇼 繁体中文 (zh-TW)
🇺🇸 English (en-US)
🇯🇵 日本語 (ja-JP)
🇰🇷 한국어 (ko-KR)
🇻🇳 Tiếng Việt (vi-VN)
✅ 多传输方式: 支持stdio、HTTP、WebSocket等多种传输协议
✅ MCP标准兼容: 完全兼容 MCP 协议规范
✅ 易于扩展: 清晰的抽象层设计，添加新系统只需3步
✅ 完整排盘: 十二宫、主星、辅星、杂耀、四化等
✅ 运势查询: 大限、流年、流月、流日、流时
✅ 宫位分析: 深度分析特定宫位的星曜配置
✅ 多种历法: 支持阳历和农历输入
✅ 格式化输出: JSON和Markdown两种输出格式
⭐ 真太阳时: 支持按出生地经度和精确时间修正 新功能
✅ 四柱排盘: 年月日时四柱、天干地支详细信息
✅ 十神分析: 比肩、劫财、食神、伤官、偏财、正财、七杀、正官、偏印、正印
✅ 五行分析: 金木水火土分数、百分比、平衡度
✅ 地支藏干: 详细的地支藏干信息
✅ 运势查询: 简化十年年龄段标记、流年干支分析
✅ 缺失分析: 自动识别五行缺失并给出建议
✅ 多种历法: 支持阳历和农历输入
⭐ 真太阳时: 支持按出生地经度和精确时间修正 新功能
新用户推荐阅读路径：
快速开始指南 ⭐ - 5分钟快速上手
安装方法（uvx、pip、Docker）
IDE配置示例
第一次排盘体验
用户指南 - 完整功能说明
所有工具详解
参数说明
输出格式对比
使用限制
真太阳时使用指南 ⭐ - 精确时辰修正（新功能）
200+全球城市支持
自动时辰修正
适用于西北地区
API使用示例 - 17个实用代码示例
基础用法
紫微斗数、八字示例
高级模式（批量处理、错误处理）
故障排查指南 - 16个常见问题解决方案
安装问题
配置问题
运行时错误
调试技巧
开发者文档：
获取紫微斗数完整排盘信息
参数:
date (string, 必需): 出生日期 YYYY-MM-DD，如 "2000-08-16"
time_index (integer, 必需): 时辰序号 0-12
0=早子时(23-01), 1=丑时(01-03), 2=寅时(03-05), 3=卯时(05-07)
4=辰时(07-09), 5=巳时(09-11), 6=午时(11-13), 7=未时(13-15)
8=申时(15-17), 9=酉时(17-19), 10=戌时(19-21), 11=亥时(21-23)
12=晚子时(23-01)
gender (string, 必需): 性别 "男" 或 "女"
calendar (string, 可选): 历法 "solar"(阳历) 或 "lunar"(农历), 默认 "solar"
is_leap_month (boolean, 可选): 是否闰月，默认 false
format (string, 可选): 输出格式 "json" 或 "markdown", 默认 "markdown"
language (string, 可选): 输出语言，可选 "zh-CN", "zh-TW", "en-US", "ja-JP", "ko-KR", "vi-VN"，默认 "zh-CN" ⭐ 新增
示例:
{
"date": "2000-08-16",
"time_index": 2,
"gender": "女",
"calendar": "solar"
}获取紫微斗数运势信息
参数:
birth_date (string, 必需): 出生日期
time_index (integer, 必需): 时辰序号
gender (string, 必需): 性别
calendar (string, 可选): 历法类型
query_date (string, 可选): 查询日期，不填则为今天
format (string, 可选): 输出格式
language (string, 可选): 输出语言，默认 "zh-CN" ⭐ 新增
分析紫微斗数特定宫位
参数:
birth_date (string, 必需): 出生日期
time_index (integer, 必需): 时辰序号
gender (string, 必需): 性别
palace_name (string, 必需): 宫位名称，可选值：
命宫、兄弟、夫妻、子女、财帛、疾厄
迁移、仆役、官禄、田宅、福德、父母
calendar (string, 可选): 历法类型
format (string, 可选): 输出格式
language (string, 可选): 输出语言，默认 "zh-CN" ⭐ 新增
列出所有可用的命理系统
获取八字（四柱）排盘信息
参数:
date (string, 必需): 出生日期 YYYY-MM-DD
time_index (integer, 必需): 时辰序号 0-12
gender (string, 必需): 性别 "男" 或 "女"
calendar (string, 可选): 历法 "solar"(阳历) 或 "lunar"(农历), 默认 "solar"
is_leap_month (boolean, 可选): 是否闰月，默认 false
format (string, 可选): 输出格式 "json" 或 "markdown", 默认 "markdown"
示例:
{
"date": "2000-08-16",
"time_index": 2,
"gender": "女"
}输出包含:
四柱八字（年月日时）
天干地支详细信息
十神分析（比肩、劫财等）
五行分数统计
地支藏干信息
生肖、日主等基本信息
获取八字运势信息
参数:
birth_date (string, 必需): 出生日期
time_index (integer, 必需): 时辰序号
gender (string, 必需): 性别
calendar (string, 可选): 历法类型
query_date (string, 可选): 查询日期，不填则为今天
format (string, 可选): 输出格式
输出包含:
当前年龄
简化十年年龄段信息（非完整大运干支推演）
流年信息（年份、干支、生肖）
本命八字
分析八字五行强弱
参数:
birth_date (string, 必需): 出生日期
time_index (integer, 必需): 时辰序号
gender (string, 必需): 性别
calendar (string, 可选): 历法类型
format (string, 可选): 输出格式
输出包含:
日主及其五行属性
五行分数和百分比
最旺/最弱五行
缺失五行
平衡度评价
补救建议
Smithery 部署: https://server.smithery.ai/@spyfree/mingli-mcp/mcp
添加到 Cursor:
添加到 Claude Code: claude mcp add mingli -- uvx mingli-mcp
添加到 OpenAI CodeX: codex mcp add mingli -- uvx mingli-mcp
使用 uvx 是最简单的安装方式，无需手动管理依赖：
在 ~/.cursor/mcp.json 或对应IDE的MCP配置文件中添加：
{
"mcpServers": {
"mingli": {
"command": "uvx",
"args": ["mingli-mcp"],
"env": {
"LOG_LEVEL": "INFO"
}
}
}
}使用 Docker 部署，适合服务器环境或需要隔离的场景：
# 下载配置文件
mkdir -p /opt/mingli-mcp
cd /opt/mingli-mcp
wget https://raw.githubusercontent.com/spyfree/mingli-mcp/main/docker-compose.yml
# 启动服务
docker-compose up -d然后在MCP配置中使用HTTP连接：
{
"mcpServers": {
"mingli": {
"url": "http://localhost:8080/mcp"
}
}
}适合开发者或需要自定义的场景：
Python 3.8+
Cursor IDE 或其他支持MCP的工具
cd /Users/lix18854/Documents/code
# 项目已在 ziwei_mcp 目录中
cd ziwei_mcppython3 -m venv venv
source venv/bin/activate # macOS/Linux
# 或
venv\Scripts\activate # Windowspip install -r requirements.txtpip install -r requirements-http.txt
# 或使用 pip install .[http]注意: stdio模式无需任何额外配置即可使用，推荐日常使用。HTTP模式仅在需要Docker部署或服务器环境时使用。
cp examples/config/.env.example .env
# 编辑 .env 文件根据需要调整配置python -m mingli_mcp编辑或创建 ~/.cursor/mcp.json:
{
"mcpServers": {
"mingli": {
"command": "/Users/lix18854/Documents/code/ziwei_mcp/venv/bin/python",
"args": ["-m", "mingli_mcp"],
"env": {
"LOG_LEVEL": "INFO"
}
}
}
}注意: 请根据实际路径调整
command和args
重启 Cursor IDE 以加载新的 MCP 配置。
ziwei_mcp/
├── pyproject.toml # 项目配置
├── requirements.txt # Python依赖
├── README.md # 项目文档
│
├── mingli_mcp/ # 可安装的Python包（唯一顶层命名空间）
│ ├── __init__.py # 包版本
│ ├── cli.py # 命令行入口（mingli-mcp / python -m mingli_mcp）
│ ├── config.py # 配置管理
│ │
│ ├── mcp_server/ # MCP协议实现
│ │ ├── server.py # 请求路由
│ │ ├── protocol.py # initialize/prompts/resources、协议版本协商
│ │ ├── resources.py # 资源内容
│ │ └── tools/ # 工具定义与handler
│ │
│ ├── core/ # 核心抽象层
│ │ ├── base_system.py # 命理系统抽象基类
│ │ ├── birth_info.py # 生辰信息数据模型
│ │ └── chart_result.py # 排盘结果数据模型
│ │
│ ├── transports/ # 传输层
│ │ ├── stdio_transport.py # stdio传输（默认）
│ │ └── http_transport.py # Streamable HTTP传输（无状态JSON模式）
│ │
│ ├── systems/ # 命理系统实现
│ │ ├── ziwei/ # 紫微斗数（已实现）
│ │ ├── bazi/ # 八字（已实现）
│ │ └── astrology/ # 占星（预留）
│ │
│ ├── utils/ # 工具函数（校验、格式化、限流等）
│ └── prompts/ # 提示词模板（随包发布）
│
├── docs/ # 文档
├── examples/ # 示例配置
├── scripts/ # 脚本工具
└── tests/ # 单元测试本项目采用插件化架构，添加新命理系统只需3步：
在 systems/ 下创建新目录，实现 BaseFortuneSystem 接口：
# systems/bazi/bazi_system.py
from core.base_system import BaseFortuneSystem
class BaziSystem(BaseFortuneSystem):
def get_system_name(self) -> str:
return "八字"
def get_chart(self, birth_info):
# 实现八字排盘逻辑
return {...}
# 实现其他必需方法...在 systems/__init__.py 中注册：
from .bazi import BaziSystem
register_system('bazi', BaziSystem)在 mingli_mcp/mcp_server/tools/definitions.py 中添加工具定义，并在 tools/__init__.py 注册handler。
就这么简单！无需修改核心框架代码。
当前默认使用 stdio 传输（适用于 Cursor）。未来可扩展：
# transports/http_transport.py
class HttpTransport(BaseTransport):
def __init__(self, host, port):
# 实现HTTP服务器
pass# transports/ws_transport.py
class WebSocketTransport(BaseTransport):
def __init__(self, host, port):
# 实现WebSocket服务器
pass与AI助手（如Claude、Cursor等）对话时，可以直接使用自然语言查询：
紫微斗数示例：
"帮我排一个紫微斗数盘：1990年5月20日，午时，男性"
"查询这个人今年的运势如何"
"分析他的财帛宫"
"看看他适合什么行业"
八字示例：
"帮我算八字：1985年3月15日，卯时，女性"
"分析一下她的五行缺什么"
"看看她今年所处的十年年龄段和流年干支"
"什么五行的颜色适合她"
农历支持：
"排盘：农历1995年7月初七，酉时，女性"
"注意指定是农历"
详细查询：
请帮我详细分析：
- 出生日期：2000年8月16日
- 出生时辰：寅时（早上5点）
- 性别：女
- 使用紫微斗数系统
- 重点看事业宫和财帛宫对比分析：
请对比两个人的八字：
人A：1990年5月20日，午时，男
人B：1992年3月15日，辰时，女
看看他们的五行是否相配运势追踪：
请记住这个人的信息：1988年10月1日，未时，男性
然后每个月帮我分析当月运势直接在对话中提问：
获取紫微排盘:
帮我排一个紫微斗数盘：2000年8月16日，寅时，女性查询运势:
查询2000年8月16日寅时出生的女性，今天的紫微运势分析宫位:
分析上面这个人的命宫八字五行分析:
帮我看看这个人的五行：1995年7月10日，申时，男性from systems import get_system
# 获取紫微系统
ziwei = get_system('ziwei')
# 准备生辰信息
birth_info = {
'date': '2000-08-16',
'time_index': 2, # 寅时
'gender': '女',
'calendar': 'solar'
}
# 获取排盘
chart = ziwei.get_chart(birth_info)
print(chart)
# 获取运势
from datetime import datetime
fortune = ziwei.get_fortune(birth_info, datetime.now())
print(fortune)
# 分析宫位
palace = ziwei.analyze_palace(birth_info, '命宫')
print(palace)# 运行测试（待实现）
pytest tests/
# 测试单个系统
python -m systems.ziwei.ziwei_system本服务采用零配置设计，所有配置都是可选的，服务器无需任何配置即可直接运行。
如果需要自定义行为，可通过以下环境变量进行配置：
环境变量 | 描述 | 默认值 | 示例 |
| 日志级别 |
|
|
| 传输协议类型 |
|
|
| HTTP监听地址（仅http模式） |
|
|
| HTTP监听端口（仅http模式） |
|
|
| HTTP API密钥（可选） |
|
|
| 默认输出语言 |
|
|
方法1: 在MCP配置中设置
{
"mcpServers": {
"mingli": {
"command": "uvx",
"args": ["mingli-mcp"],
"env": {
"LOG_LEVEL": "DEBUG",
"DEFAULT_LANGUAGE": "zh-TW"
}
}
}
}方法2: 使用 .env 文件
# 创建 .env 文件
cat > .env << EOF
LOG_LEVEL=INFO
DEFAULT_LANGUAGE=zh-CN
TRANSPORT_TYPE=stdio
EOF方法3: 系统环境变量
export LOG_LEVEL=DEBUG
export DEFAULT_LANGUAGE=zh-CN
python -m mingli_mcpiztro-py: 紫微斗数核心库（纯 Python 实现，性能比 py-iztro 提升 10 倍）
python-dotenv: 环境变量管理
python-dateutil: 日期处理
完善八字系统实现
添加西方占星系统
实现合盘功能
HTTP/WebSocket传输层
命理知识库集成
AI解读功能
更多运势分析维度
欢迎贡献代码、报告问题或提出建议！
MIT License
iztro - 紫微斗数 JavaScript 库（原始算法来源）
iztro-py - 紫微斗数纯 Python 实现
MCP Protocol - Model Context Protocol 规范
🔮 开始你的命理探索之旅！
分析八字五行强弱，包含五行分数、平衡度、缺失五行等
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | 出生日期，格式：YYYY-MM-DD | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | ||
| calendar | No | solar | |
| is_leap_month | No | ||
| format | No | markdown | |
| language | No | zh-CN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the agent knows it's a safe analysis operation. The description adds value by specifying what the analysis includes (五行分数, 平衡度, 缺失五行), but doesn't provide additional behavioral context like rate limits, authentication needs, or output format details beyond the 'format' parameter.
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 - a single Chinese sentence that efficiently states the core functionality. Every word earns its place with no wasted text, and the information is front-loaded with the main purpose.
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?
For a 7-parameter analysis tool with low schema coverage (29%) and no output schema, the description is insufficient. It doesn't explain the complex Bazi analysis domain, doesn't clarify parameter relationships, and provides no information about return values or analysis methodology, leaving significant gaps for an AI agent.
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 only 29% schema description coverage (2 of 7 parameters have descriptions), the description doesn't compensate for the significant documentation gap. It mentions '八字五行' analysis but provides no information about what the 7 parameters mean or how they affect the analysis, leaving most parameters semantically unclear.
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: analyzing the strength of Five Elements in a Bazi chart, including scores, balance, and missing elements. It uses specific verbs ('分析' - analyze) and resources ('八字五行' - Bazi Five Elements), but doesn't explicitly differentiate from sibling tools like 'get_bazi_chart' or 'get_bazi_fortune' which might provide related information.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_bazi_chart' (which might provide the raw chart) or 'get_bazi_fortune' (which might provide fortune analysis), leaving the agent to guess about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析紫微斗数特定宫位的详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | 出生日期，格式：YYYY-MM-DD | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | ||
| palace_name | Yes | 要分析的宫位名称 | |
| calendar | No | solar | |
| is_leap_month | No | ||
| format | No | markdown | |
| language | No | zh-CN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the agent knows it's a safe, repeatable query operation. The description adds value by specifying it provides '详细信息' (detailed information) about specific palaces, which gives context about the depth of analysis. However, it doesn't mention rate limits, authentication needs, or what constitutes 'detailed information' in practice.
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, efficient Chinese sentence that immediately conveys the core purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized for what it communicates, though what it communicates is limited in scope.
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?
For an 8-parameter tool with low schema coverage (38%) and no output schema, the description is inadequate. It doesn't explain what 'detailed information' means in the output, doesn't clarify the relationship between parameters, and provides no context about the Ziwei astrology system for users unfamiliar with it. The annotations help with safety profile, but the description leaves too many gaps for effective tool selection and 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?
With only 38% schema description coverage (3 of 8 parameters have descriptions), the description carries significant burden but adds no parameter information. It mentions analyzing '特定宫位' (specific palaces), which aligns with the 'palace_name' parameter, but doesn't explain the meaning or significance of parameters like 'time_index', 'calendar', 'is_leap_month', or the various format/language options. The description fails to compensate for the low schema 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 '分析紫微斗数特定宫位的详细信息' clearly states the action ('分析' - analyze) and resource ('紫微斗数特定宫位' - specific Ziwei palace), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_ziwei_chart' or 'get_ziwei_fortune', which likely provide different types of Ziwei analysis.
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 no guidance on when to use this tool versus alternatives. With sibling tools like 'get_ziwei_chart' and 'get_ziwei_fortune' available, there's no indication whether this tool provides more detailed palace-specific analysis versus broader chart or fortune analysis. No context about prerequisites or typical use cases is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取八字（四柱）排盘信息，包含年月日时四柱、十神、五行、地支藏干等详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | 出生日期，格式：YYYY-MM-DD | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | ||
| calendar | No | solar | |
| is_leap_month | No | ||
| format | No | markdown | |
| language | No | zh-CN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds minimal behavioral context beyond this—it implies data retrieval but doesn't disclose rate limits, authentication needs, or output format details. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.
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, efficient sentence that front-loads the core purpose and lists included components. It avoids redundancy but could be slightly more structured by separating purpose from details. Every word earns its place, making it appropriately 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?
For a tool with 7 parameters (4 with enums), low schema coverage (29%), and no output schema, the description is insufficient. It doesn't explain parameter meanings, output format, or behavioral nuances, leaving significant gaps in understanding how to use the tool effectively beyond its basic purpose.
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 low (29%), with only 2 of 7 parameters described in the schema. The description doesn't compensate by explaining any parameters—it mentions no parameter details, leaving most semantics undocumented. This is inadequate given the low schema coverage and multiple parameters with enums.
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: '获取八字（四柱）排盘信息' (get Bazi chart information) and specifies the detailed components included: '年月日时四柱、十神、五行、地支藏干等详细信息' (four pillars, ten gods, five elements, hidden stems, etc.). It distinguishes itself from siblings like analyze_bazi_element or get_bazi_fortune by focusing on comprehensive chart generation rather than analysis or fortune-telling.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like analyze_bazi_element (for elemental analysis) or get_bazi_fortune (for fortune predictions), nor does it specify prerequisites or contextual constraints beyond what's implied by the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取八字运势信息，包含大运、流年等详情
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | 出生日期，格式：YYYY-MM-DD | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | ||
| calendar | No | solar | |
| is_leap_month | No | ||
| query_date | No | 查询运势的日期，格式：YYYY-MM-DD | |
| format | No | markdown | |
| language | No | zh-CN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, repeatable read operation. The description adds minimal behavioral context beyond this, mentioning it returns '详情' (details) but not elaborating on format, rate limits, or authentication needs. It doesn't contradict annotations, so a baseline 3 is appropriate given annotations cover core safety.
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, efficient sentence in Chinese that directly states the purpose and scope ('包含大运、流年等详情'). It's front-loaded with no wasted words, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function.
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 complexity (8 parameters, low schema coverage, no output schema) and annotations that only cover safety, the description is insufficient. It doesn't explain the return format, how parameters interact (e.g., 'birth_date' with 'calendar'), or provide examples. For a tool with rich cultural context like Bazi fortune-telling, more guidance is needed to ensure correct usage.
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 low at 38%, with only 3 of 8 parameters having descriptions in the schema. The description doesn't compensate by explaining any parameters, their relationships, or semantics (e.g., what 'time_index' represents, how 'calendar' affects calculations). It adds no value beyond the schema, failing to address the coverage gap.
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: '获取八字运势信息，包含大运、流年等详情' (Get Bazi fortune information, including details like major cycles and yearly fortunes). It specifies the verb ('获取' - get) and resource ('八字运势信息' - Bazi fortune information), but doesn't explicitly differentiate from sibling tools like 'get_bazi_chart' or 'get_ziwei_fortune', which likely provide different types of Bazi/fortune information.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'get_bazi_chart' for chart data, 'get_ziwei_fortune' for Ziwei fortune, 'analyze_bazi_element' for element analysis) or specify contexts where this tool is preferred. Usage is implied by the purpose but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取紫微斗数排盘信息，包含命盘十二宫、主星、辅星、四化等详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | 出生日期，格式：YYYY-MM-DD，例如：2000-08-16 | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | 性别：男 或 女 | |
| calendar | No | 历法类型：solar(阳历) 或 lunar(农历) | solar |
| is_leap_month | No | 是否为闰月（仅当calendar=lunar时有效） | |
| format | No | markdown | |
| language | No | zh-CN | |
| longitude | No | 出生地经度，用于真太阳时修正 | |
| latitude | No | 出生地纬度 | |
| use_solar_time | No | 是否启用真太阳时修正 | |
| birth_hour | No | 精确出生小时（0-23） | |
| birth_minute | No | 精确出生分钟（0-59） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations provide - no information about rate limits, authentication requirements, performance characteristics, or error conditions. However, it doesn't contradict the annotations, so it meets the minimum baseline with annotations present.
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, efficient Chinese sentence that clearly states the tool's purpose and the scope of information returned. Every word earns its place - it specifies what information is obtained and lists the key components included. No wasted words or redundant information.
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?
For a complex tool with 12 parameters (3 required) and no output schema, the description is minimally adequate. The annotations cover safety aspects, and the schema has good documentation coverage. However, the description doesn't explain what format or structure the returned chart information will have, which would be helpful given the complexity of Ziwei charts and the absence of an output schema.
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 83% schema description coverage, the input schema already provides comprehensive documentation for most parameters. The description mentions '排盘信息' (chart arrangement information) which implies the parameters are for birth data input, but adds no specific guidance about parameter interactions, default behaviors, or special considerations beyond what's in the schema descriptions. This meets the baseline for high schema 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 clearly states the tool's purpose: '获取紫微斗数排盘信息' (get Ziwei Dou Shu chart information). It specifies the resource (Ziwei chart) and the scope of information returned (twelve palaces, main stars, auxiliary stars, four transformations). However, it doesn't explicitly differentiate from sibling tools like 'get_ziwei_fortune' or 'analyze_ziwei_palace', which likely provide different aspects of Ziwei analysis.
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 no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to Ziwei and fortune analysis (get_ziwei_fortune, analyze_ziwei_palace, etc.), but the description doesn't indicate whether this is the primary chart generation tool versus more specialized analysis tools. No context about prerequisites or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取紫微斗数运势信息，包含大限、流年、流月、流日、流时的运势详情
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | 出生日期，格式：YYYY-MM-DD | |
| time_index | Yes | 出生时辰序号（0-12） | |
| gender | Yes | 性别：男 或 女 | |
| calendar | No | solar | |
| is_leap_month | No | ||
| query_date | No | 查询运势的日期，格式：YYYY-MM-DD | |
| format | No | markdown | |
| language | No | zh-CN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds valuable context by specifying what fortune information is included (大限, 流年, 流月, 流日, 流时), which goes beyond the annotations. It doesn't mention rate limits, authentication needs, or response format details, but with good annotation coverage, this is acceptable.
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, efficient sentence that clearly states the tool's purpose. Every word earns its place - it specifies what information is retrieved and what time periods are included. There's no wasted verbiage or redundancy.
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?
For a read-only tool with good annotations, the description provides adequate basic purpose information. However, with 8 parameters (some complex like time_index and calendar/is_leap_month interactions) and no output schema, the description should ideally provide more context about what the tool returns and how parameters work together. It's minimally complete but leaves significant gaps.
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 only 50% (4 of 8 parameters have descriptions in the schema). The description provides no additional parameter information beyond what's implied by the tool name. It doesn't explain relationships between parameters (e.g., how birth_date and query_date interact, what time_index represents, or what calendar and is_leap_month control). With low schema coverage, the description should compensate but doesn't.
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: '获取紫微斗数运势信息' (get Ziwei fortune information) with specific details about what it includes (大限, 流年, 流月, 流日, 流时). It distinguishes this from sibling tools like 'get_ziwei_chart' (which likely provides charts rather than fortune details) and 'get_bazi_fortune' (which provides different fortune system information). However, it doesn't explicitly contrast with all siblings like 'analyze_ziwei_palace'.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_ziwei_chart' (for fortune vs. chart) or 'get_bazi_fortune' (for different fortune systems). There's no context about prerequisites or typical use cases beyond the basic function stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出所有可用的命理系统（紫微斗数、八字、占星等）
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | 是否输出更详细信息 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds no behavioral traits beyond this, such as rate limits, authentication needs, or output format details. It doesn't contradict annotations, but adds minimal value given the annotation coverage.
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, efficient sentence in Chinese that directly states the tool's purpose with examples. It is front-loaded with the core action and resource, with no redundant or unnecessary words, making it highly concise and well-structured.
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 (one optional parameter), rich annotations covering safety and idempotency, and no output schema, the description is reasonably complete. It clearly states what the tool does, though it could benefit from more usage guidance or output details. For a simple list tool, this is adequate but not exhaustive.
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 100%, with the parameter 'detailed' fully documented in the schema as a boolean for outputting more information. The description adds no parameter semantics beyond what the schema provides, such as examples of what 'detailed' includes. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 verb '列出' (list) and the resource '所有可用的命理系统' (all available fortune-telling systems), with examples like '紫微斗数、八字、占星等' (Ziwei Doushu, Bazi, astrology, etc.). It distinguishes from siblings by focusing on listing systems rather than analyzing or getting charts/fortune, though it doesn't explicitly name alternatives. This is specific but lacks explicit sibling differentiation.
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 when needing to see available systems, but provides no explicit guidance on when to use this tool versus alternatives like 'analyze_bazi_element' or 'get_ziwei_chart'. It doesn't state prerequisites, exclusions, or named alternatives, leaving usage context inferred rather than clearly defined.
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.
analyze_bazi_elementanalyze_ziwei_palaceget_bazi_chartget_bazi_fortuneget_ziwei_chartget_ziwei_fortunelist_fortune_systemsEach tool has a clearly distinct purpose with no overlap: analyze_bazi_element focuses on element analysis, analyze_ziwei_palace on palace details, get_bazi_chart/get_ziwei_chart on chart generation, get_bazi_fortune/get_ziwei_fortune on fortune readings, and list_fortune_systems on system enumeration. The descriptions clearly differentiate between analysis, chart retrieval, fortune tracking, and system listing functions.
All tools follow a consistent verb_noun pattern with snake_case: analyze_*, get_*, list_*. The naming is highly predictable and readable, with verbs appropriately matched to actions (analyze for detailed examination, get for data retrieval, list for enumeration).
With 7 tools, this server is well-scoped for its Chinese metaphysics/fortune-telling domain. Each tool earns its place by covering distinct aspects: chart generation (2 tools), fortune analysis (2 tools), element/palace analysis (2 tools), and system overview (1 tool). This count avoids bloat while providing comprehensive coverage.
The tool set provides complete coverage for the domain: it supports both Bazi and Ziwei systems with chart generation, fortune tracking, and detailed analysis capabilities. The list_fortune_systems tool provides discoverability, and there are no obvious gaps—users can perform full lifecycle operations from system selection to detailed fortune 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.
Zi Wei Dou Shu for AI agents: free natal charts, six transit levels, and optional readings.
Generate BaZi charts from birth details. Explore Four Pillars, solar terms, and Luck Pillars for d…
BaZi (八字) MCP gateway + 玄学社区. 12 tools (4 fortune + 5 forum + 3 meta). x-api-key required.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/spyfree/mingli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
