你这个思路挺完整了；真要把它“落地成 MCP + iztro”，关键不在再加一堆玄学词条，而在把 iztro 产出的结构化盘面数据，稳定、可验证地喂给你的“天策谋士”。所以工具设计要偏“计算/查询/归一化”，别让工具去“写报告”（报告交给你的 System Prompt）。

下面是我调研 iztro 后，建议你做 MCP 时应当准备的工具清单（分层：必备 / 推荐 / 进阶），以及为什么需要它们。

0）先对齐两个现实差异（你不处理就会卡住）

1. 宫位命名差异 iztro 的 PalaceName 里是 兄弟/迁移/仆役/官禄...，而你提示词里写的是 兄弟宫/交友宫/迁移宫...；其中交友宫在 iztro 体系通常对应“仆役”（名称层面）。类型定义里能看到 仆役 这一项。(紫微研习社) ➡️ 所以你需要一个“别名映射/标准化”层（做成工具最方便）。

2. 四化字段值差异 iztro 的 Mutagen 值是 禄/权/科/忌，而你提示词用的是 化禄/化权/化科/化忌；宫位方法 hasMutagen("禄") 也是这么用的。(紫微研习社) ➡️ 归一化时要把 禄→化禄 这种做一遍，免得模型误判“缺数据”。

1）MCP 工具怎么取舍：少而硬，别“工具膨胀”

MCP 的 Tools 本质是“模型可调用的函数”，需要清晰的 inputSchema，还支持可选的 outputSchema（强烈建议你用），这样客户端/模型更不容易瞎用。(Model Context Protocol) 另外官方规范也明确强调工具调用应有人类可控的授权/确认环节。(Model Context Protocol)

所以我建议：核心 3–5 个工具就能跑通；查询类工具按需加。

2）必备工具（MVP：跑通“输入→盘面→CI 报告”）

Tool A：zwds.chart.generate

用途：用出生信息直接生成盘（最核心）。 底层：astro.bySolar(...)（官方推荐，astrolabeBySolarDate 已废弃）。(紫微研习社)

• bySolar 的参数定义包含 solarDateStr / timeIndex(0~12) / gender / fixLeap / language。(紫微研习社)

为什么必备：你不可能让 LLM 手算排盘；工具必须做“确定性计算”。

Tool B：zwds.chart.normalize_ci

用途：把 iztro 的 FunctionalAstrolabe 大对象压缩成你系统提示词吃得最顺的结构（并做别名/四化转换/过滤）。 建议输出（例）：

• 只保留你关心的宫：命宫/官禄/迁移/财帛/父母/仆役(=交友)/田宅/子女
• 每宫只保留：主星(14主星+天马禄存等你允许的)、四化、你允许的吉/煞（擎羊陀罗火铃空劫等）
• 把 禄权科忌 → 化禄化权化科化忌
• 把 仆役 → 交友宫、迁移 → 迁移宫 等统一成你 Prompt 的命名

为什么必备：

• 大幅减少上下文 token（盘面原始结构很长）
• 把“命名差异/枚举差异”一次性解决
• 强化你 Prompt 的“NO FABRICATION”：工具输出即白名单化数据源

Tool C：zwds.horoscope.get

用途：生成运限/时间切片数据，给你报告里“30/90/6-12个月的领先指标”提供结构化依据。 底层：astrolabe.horoscope(date?, timeIndex?)。(紫微研习社) 它对 date 的处理规则（不传/只传日期/传小时/传 timeIndex）也写得很清楚。(紫微研习社)

为什么必备：你模板里强制要“未来 30/90 天信号”，不接时间维度会变成空话。

3）推荐工具（让 Agent 更“可查询、可解释、可复核”）

Tool D：zwds.palace.get

用途：按宫位名/索引取宫位对象。底层 astrolabe.palace(indexOrName)。(紫微研习社) 适合做“追问/局部解释”：模型不必每次重读整盘。

Tool E：zwds.palace.surrounded

用途：取“三方四正”。底层 astrolabe.surroundedPalaces(indexOrName)。(紫微研习社) 这对你 Prompt 里强调的“官禄轴 vs 迁移轴”与三方四正分析很关键。

Tool F：zwds.star.get_context

用途：给一个星曜名，返回它的：所在宫、对宫、三方四正。 底层：astrolabe.star(name) + star.palace()/oppositePalace()/surroundedPalaces()。(紫微研习社) 这能让你的“推理依据摘要”更短更硬（引用结构化定位，而不是一段玄学散文）。

4）进阶工具（工程化/鲁棒性/可测试性）

Tool G：zwds.palace.test

把 has / hasOneOf / notHave / hasMutagen / fliesTo / selfMutaged... 这类“判定函数”封成一个工具。 iztro 的 IFunctionalPalace 接口里这些方法是明确列出的。(紫微研习社) 用途：让模型做“是/否判断”而不是自己在文本里数星曜（减少低级错误）。

Tool H：zwds.config.set

允许切换四化表/亮度表等配置（如果你要支持不同流派或校准）。iztro 支持 astro.config({...})。(紫微研习社) 用途：让同一 MCP Server 支持多套配置，而不是你手改代码重启。

Tool I：zwds.metadata.lists

把 PalaceName / StarName / Mutagen / GenderName 等枚举吐出来做前端校验或“未识别即忽略”的 guardrail。类型定义页能看到这些类型枚举。(紫微研习社)

5）我建议你最终的 MCP 工具包长这样（精简版）

最小可用（3个）：

1. zwds.chart.generate
2. zwds.chart.normalize_ci
3. zwds.horoscope.get

增强可用（+3个）： 4. zwds.palace.get 5. zwds.palace.surrounded 6. zwds.star.get_context

工程加强（+3个）： 7. zwds.palace.test 8. zwds.config.set 9. zwds.metadata.lists

工具数量控制在 6–9 个，基本不会“工具选择困难症”，也更符合 MCP 工具设计的可发现与可控原则。(Model Context Protocol)

6）顺手给你一句“Prompt 侧”的小补丁（和 iztro 对齐）

你现在的系统提示词已经很硬了，但建议加两条非常实用的工程约束：

• 宫位别名规则：交友宫≈仆役、兄弟宫≈兄弟、迁移宫≈迁移 等（由 normalize 工具保证，Prompt 里声明“以 normalize 输出为准”）。(紫微研习社)
• 四化值规则：工具输出统一为 化禄/化权/化科/化忌；若模型看到 禄/权/科/忌，必须先转换再推理（避免漏判）。(紫微研习社)

如果你下一步要我“更落地一点”，我可以直接把这 6–9 个工具各自的 inputSchema/outputSchema（JSON Schema）草案按 MCP 2025-06-18 的写法列出来（带枚举、必填项、错误码规范），这样你可以直接开写 server。(Model Context Protocol)