Which integrations are available for this server?

Serves as the runtime environment for the MCP server, handling astrological calculations and responding to requests Displays status badges for the project including license, Node.js version, and iztro library version information

How do I use 紫微斗数 MCP 服务器 (MCPIztro)?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@紫微斗数 MCP 服务器 (MCPIztro) 帮我排一个1990年8月16日下午2点出生的女性的紫微斗数星盘" 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.

紫微斗数 MCP 服务器 (MCPIztro)

by wuunicorn

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

紫微斗数 MCP 服务器

License: MIT Node.js Version iztro

一个基于 Model Context Protocol (MCP) 的紫微斗数计算服务器，使用强大的 iztro 库提供精确的紫微斗数排盘和运限分析功能。

✨ 功能特性

🌟 完整的紫微斗数排盘 - 支持阳历和农历生日计算
📅 精确的时间处理 - 获取当前系统时间和详细信息
🔮 运限分析 - 大限、流年等运势分析
🌐 多语言支持 - 简体中文、繁体中文、英文、日文、韩文、越南文
🔄 MCP 协议兼容 - 可与支持 MCP 的 AI 助手无缝集成
⚡ 轻量高效 - 基于 Node.js，响应快速
📊 结构化数据 - 返回完整的 JSON 格式星盘数据

Related MCP server: Star MCP

🛠️ 技术栈

Node.js (≥18.0.0) - 运行环境
iztro (v2.5.3) - 紫微斗数核心计算库
MCP Protocol (2024-11-05) - 模型上下文协议

📦 安装

前置要求

Node.js 18.0.0 或更高版本
npm 包管理器

克隆仓库

git clone https://github.com/wuunicorn/MCPIztro.git
cd MCPIztro

安装依赖

npm install

⚙️ 配置

1. 创建配置文件

将 ziwei_mcp_config.json 中的路径修改为您的实际项目路径：

{
  "mcpServers": {
    "ziwei": {
      "command": "node",
      "args": ["/path/to/your/project/ziwei_mcp_server.js"],
      "env": {
        "NODE_PATH": "/path/to/your/project/node_modules"
      }
    }
  }
}

2. 在 MCP 客户端中配置

将配置文件内容添加到您的 MCP 客户端配置中（如 Claude Desktop、Cursor 等）。

🚀 使用方法

直接启动服务器

npm start
# 或
node ziwei_mcp_server.js

运行测试

npm test
# 或
node test_ziwei.js

📖 API 文档

服务器提供以下三个主要工具：

1. get_current_time

获取当前系统时间的详细信息。

参数： 无

返回：

{
  "success": true,
  "data": {
    "year": 2024,
    "month": 8,
    "day": 1,
    "hour": 15,
    "minute": 30,
    "second": 45,
    "datetime_str": "2024-08-01 15:30:45",
    "weekday": "Thursday",
    "weekday_cn": "星期四",
    "timestamp": 1722513045
  }
}

2. calculate_ziwei

计算指定生辰的紫微斗数星盘。

参数：

birthday (必需): 生日，格式 YYYY-MM-DD
hour (可选): 出生时辰 (0-23)，默认 0
gender (可选): 性别 ("男"/"女")，默认 "男"
type (可选): 日期类型 ("solar"/"lunar")，默认 "solar"
isLeapMonth (可选): 是否闰月，默认 false
language (可选): 语言设置，默认 "zh-CN"

示例请求：

{
  "birthday": "1990-08-16",
  "hour": 14,
  "gender": "女",
  "type": "solar",
  "language": "zh-CN"
}

返回： 完整的星盘数据，包含十二宫信息、星耀分布、亮度等。

3. get_horoscope

获取指定生辰在特定时间的运限信息。

参数：

birthday (必需): 生日，格式 YYYY-MM-DD
hour (可选): 出生时辰 (0-23)，默认 0
gender (可选): 性别 ("男"/"女")，默认 "男"
type (可选): 日期类型 ("solar"/"lunar")，默认 "solar"
isLeapMonth (可选): 是否闰月，默认 false
targetDate (可选): 目标日期，格式 YYYY-MM-DD，默认当前日期
language (可选): 语言设置，默认 "zh-CN"

返回： 运限信息，包含大限、流年、年龄等数据。

🌐 支持的语言

语言代码	语言名称
zh-CN	简体中文
zh-TW	繁体中文
en-US	英语
ja-JP	日语
ko-KR	韩语
vi-VN	越南语

📝 使用示例

在 MCP 客户端中使用

配置完成后，您可以在支持 MCP 的客户端中直接使用自然语言查询：

请帮我排一个1990年8月16日下午2点出生的女性的紫微斗数星盘

我想看看这个人在2024年的运势如何

直接 API 调用

# 获取当前时间
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "get_current_time", "arguments": {}}}' | node ziwei_mcp_server.js

# 计算星盘
echo '{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "calculate_ziwei", "arguments": {"birthday": "1990-08-16", "hour": 14, "gender": "女"}}}' | node ziwei_mcp_server.js

🏗️ 项目结构

MCPIztro/
├── README.md                 # 项目介绍文档
├── package.json             # 项目配置和依赖
├── package-lock.json        # 依赖锁定文件
├── ziwei_mcp_server.js      # MCP 服务器主程序
├── ziwei_mcp_config.json    # MCP 配置文件模板
├── test_ziwei.js           # 测试脚本
└── node_modules/           # 依赖包目录

🔧 开发

测试服务器功能

node test_ziwei.js

检查语法

node -c ziwei_mcp_server.js

验证依赖

node -e "import { astro } from 'iztro'; console.log('依赖加载成功');"

🤝 贡献

欢迎提交 Issue 和 Pull Request！

Fork 本仓库
创建您的特性分支 (git checkout -b feature/AmazingFeature)
提交您的修改 (git commit -m 'Add some AmazingFeature')
推送到分支 (git push origin feature/AmazingFeature)
打开一个 Pull Request

📄 许可证

本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。

🙏 致谢

iztro - 提供强大的紫微斗数计算能力
Model Context Protocol - 提供标准化的协议支持

📞 联系

如果您有任何问题或建议，请通过以下方式联系：

提交 Issue
发送邮件到：wuunicorn@gmail.com

注意： 紫微斗数仅供参考和娱乐，请理性对待运势分析结果。

Available Tools

3 tools

calculate_ziweiA

计算指定生辰的紫微斗数星盘，返回完整的星盘数据（包含十二宫、星耀、亮度等）。支持经纬度参数，将时间转换为真太阳时进行更精确的计算

ParametersJSON Schema

Name	Required	Description	Default
`birthday`	Yes	生日，格式: YYYY-MM-DD
`hour`	No	出生时辰（0-23）
`gender`	No	性别	男
`type`	No	日期类型	solar
`isLeapMonth`	No	是否闰月（仅农历有效）
`language`	No	语言设置	zh-CN
`longitude`	No	出生地经度（-180 到 180），用于真太阳时转换
`latitude`	No	出生地纬度（-90 到 90），用于真太阳时转换

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that this is a calculation tool (not a read-only query) and mentions precision enhancements through true solar time conversion. However, it doesn't disclose important behavioral traits like whether this is a computationally intensive operation, potential rate limits, authentication requirements, or error conditions. The description adds some context but 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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality and output, while the second adds important precision capabilities. There's zero wasted language, and the information is front-loaded with the primary purpose stated immediately.

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's complexity (8 parameters, astrological calculation), lack of annotations, and no output schema, the description is moderately complete. It covers the core purpose and precision features but doesn't address computational behavior, error handling, or output format details. For a calculation tool with this many parameters and no structured output documentation, more context would be helpful.

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 input schema has 100% description coverage with detailed parameter documentation, so the baseline is 3. The description adds value by explaining the purpose of longitude/latitude parameters ('用于真太阳时转换' - for true solar time conversion) and mentioning that the tool supports these parameters for more precise calculations. This provides context beyond the schema's technical specifications, though it doesn't add detailed semantics for all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('计算' - calculate), the resource ('紫微斗数星盘' - Zi Wei Dou Shu astrological chart), and the output ('完整的星盘数据' - complete chart data including twelve houses, stars, brightness). It distinguishes itself from sibling tools like get_current_time and get_horoscope by focusing on detailed astrological calculation rather than time retrieval or general horoscopes.

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 context by mentioning support for longitude/latitude parameters and true solar time conversion for more precise calculations, suggesting this tool should be used when geographic precision matters. However, it doesn't explicitly state when to use this versus alternatives (like the sibling get_horoscope tool) or provide exclusion criteria for simpler cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_timeB

获取当前系统时间，返回详细的时间信息

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

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. It mentions returning '详细的时间信息' (detailed time information), which gives some behavioral context about the output. However, it doesn't disclose other important traits like whether it's read-only, has side effects, requires permissions, or has rate limits—critical for a tool that might be time-sensitive or system-dependent.

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 sentence that directly states the purpose and output. It's front-loaded with the core function ('获取当前系统时间') and adds just enough detail about the return value. There's zero wasted text, making it highly efficient.

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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output type but lacks details on format, timezone handling, or error conditions. For a tool that returns system time, more context on precision or reliability would be helpful, though the low complexity keeps it from being severely incomplete.

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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics since there are none. A baseline score of 4 is appropriate as it doesn't mislead about parameters and aligns with the 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 current system time) with the verb '获取' and resource '系统时间'. It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like 'calculate_ziwei' or 'get_horoscope', which appear to be unrelated time/astrology tools.

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 any context, prerequisites, or exclusions. While the siblings seem unrelated (astrology calculations), the description doesn't clarify this distinction or provide any usage rules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_horoscopeC

获取指定生辰在特定时间的运限信息（大限、流年等）。支持经纬度参数，将时间转换为真太阳时进行更精确的计算

ParametersJSON Schema

Name	Required	Description	Default
`birthday`	Yes	生日，格式: YYYY-MM-DD
`hour`	No	出生时辰（0-23）
`gender`	No	性别	男
`type`	No	日期类型	solar
`isLeapMonth`	No	是否闰月（仅农历有效）
`targetDate`	No	目标日期，格式: YYYY-MM-DD，不指定则使用当前日期
`language`	No	语言设置	zh-CN
`longitude`	No	出生地经度（-180 到 180），用于真太阳时转换
`latitude`	No	出生地纬度（-90 到 90），用于真太阳时转换

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions that longitude/latitude parameters enable true solar time conversion for more precise calculations, it doesn't describe what type of data is returned (format, structure), whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a 9-parameter tool with no annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise - two sentences that convey the core functionality and a key feature (true solar time conversion). It's front-loaded with the main purpose. However, the second sentence could be more tightly integrated with the first for better flow.

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?

For a complex tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what '运限信息（大限、流年等）' actually returns, the format of results, or how to interpret the output. The description should provide more context about the fortune/luck information being retrieved and what users can expect from the tool's response.

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 9 parameters thoroughly. The description adds minimal value beyond the schema - it mentions that longitude/latitude parameters are used for true solar time conversion, which is already indicated in the schema descriptions. No additional parameter context, constraints, or relationships are provided in the description.

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: '获取指定生辰在特定时间的运限信息（大限、流年等）' - it retrieves fortune/luck information for a specified birth time at a target date. It specifies the resource (birth information) and action (retrieve fortune data). However, it doesn't explicitly differentiate from sibling tools like 'calculate_ziwei' which might be related to Chinese astrology calculations.

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 mentions supporting longitude/latitude parameters for true solar time conversion, but doesn't indicate when this tool should be chosen over 'calculate_ziwei' or other potential alternatives. There's no mention of prerequisites, use cases, or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv1.0.0Jan 3, 2026

Changedcalculate_ziwei2 fields changed

addedInput schema / properties / latitude

Added value: +{
+  "default": 39.9042,
+  "description": "出生地纬度（-90 到 90），用于真太阳时转换",
+  "examples": [
+    39.9042,
+    40.7128,
+    35.6762
+  ],
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / longitude

Added value: +{
+  "default": 116.4074,
+  "description": "出生地经度（-180 到 180），用于真太阳时转换",
+  "examples": [
+    116.4074,
+    -74.006,
+    139.6917
+  ],
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

Changedget_horoscope2 fields changed

addedInput schema / properties / latitude

Added value: +{
+  "default": 39.9042,
+  "description": "出生地纬度（-90 到 90），用于真太阳时转换",
+  "examples": [
+    39.9042,
+    40.7128,
+    35.6762
+  ],
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / longitude

Added value: +{
+  "default": 116.4074,
+  "description": "出生地经度（-180 到 180），用于真太阳时转换",
+  "examples": [
+    116.4074,
+    -74.006,
+    139.6917
+  ],
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

3 tool updatesAug 15, 2025
- First observedcalculate_ziwei
- First observedget_current_time
- First observedget_horoscope

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-18 09:10 across 3 tools

Disambiguation4/5

The tools have mostly distinct purposes: calculate_ziwei for natal charts, get_horoscope for time-based horoscopes, and get_current_time for system time. However, get_current_time might be confused as a helper for the other tools rather than a standalone feature, creating minor ambiguity in the set's scope.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (calculate_ziwei, get_current_time, get_horoscope). The verbs 'calculate' and 'get' are clear and appropriate for their functions, making the naming highly predictable.

Tool Count3/5

With only 3 tools, the set feels thin for a Zi Wei Dou Shu server, as it lacks operations like updating charts, comparing charts, or accessing historical data. While the core functions are present, the low count may limit agent workflows in this domain.

Completeness3/5

The server covers basic natal chart calculation and horoscope retrieval, but there are notable gaps: no update or delete operations for saved charts, no chart comparison tools, and no methods for interpreting or analyzing results beyond raw data. This could lead to dead ends in complex agent tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

FateStar Ziwei A
io.github.LouisLin0723
Zi Wei Dou Shu for AI agents: free natal charts, six transit levels, and optional readings.
Entertainment & Media
31
VedaVisor Vedic Astrology MCP A
io.github.dchhill
Professional Vedic astrology tools for AI agents via MCP.
Entertainment & Media
3
Asterwise AOAuth
com.asterwise
Vedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Software Architecture
1031
BaZi Fortune Hub
io.github.tchen6500
BaZi (八字) MCP gateway + 玄学社区. 12 tools (4 fortune + 5 forum + 3 meta). x-api-key required.
Art & Culture
2

Related MCP Servers

Horoscope MCP Server
Search
GBcui
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides daily horoscope readings and fortune telling for all 12 zodiac signs across multiple time ranges (today, tomorrow, week, month).
Updated a year ago (2025-09-22 03:33 UTC)
557 npm
6
MIT
Star MCP
Entertainment & Media Search
jlankellii
A
license
B
quality
D
maintenance
A comprehensive Model Context Protocol service providing zodiac information queries, horoscope analysis, and compatibility testing between star signs.
Updated 6 months ago (2026-03-03 10:04 UTC)
7
5 npm
3
MIT
Bazi MCP
Art & Culture
shuangzixing1976
A
license
Not graded
quality
D
maintenance
MCP server for accurate Bazi calculations, enabling personality analysis, destiny forecasting, and Chinese calendar queries via AI agents.
Updated 4 months ago (2026-05-26 10:52 UTC)
125 npm
ISC
AstroStellar MCP Server
AI & Machine Learning Knowledge & Memory
zhaopeng309
F
license
Not graded
quality
C
maintenance
An MCP server for Zi Wei Dou Shu (Purple Star Astrology) that enables users to construct and interpret natal charts through natural language conversation, integrating a knowledge base of classical texts.
Updated 2 months ago (2026-07-30 02:26 UTC)
1
-

紫微斗数 MCP 服务器

✨ 功能特性

🛠️ 技术栈

📦 安装

前置要求

克隆仓库

安装依赖

⚙️ 配置

1. 创建配置文件

2. 在 MCP 客户端中配置

🚀 使用方法

直接启动服务器

运行测试

📖 API 文档

1. get_current_time

2. calculate_ziwei

3. get_horoscope

🌐 支持的语言

📝 使用示例

在 MCP 客户端中使用

直接 API 调用

🏗️ 项目结构

🔧 开发

测试服务器功能

检查语法

验证依赖

🤝 贡献

📄 许可证

🙏 致谢

📞 联系

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches