Skip to main content
Glama

紫微斗数运限盘

ziwei_transits
Read-onlyIdempotent

在本命盘基础上计算 6 层运限: 大限 (10 年运, 含全部 13 段列表) / 小限 (1 年) / 流年 / 流月 / 流日 / 流时。每层返回该层命宫地支 + 四化 (化禄/化权/化科/化忌) + 双轨干支 (真实干支 vs 宫位编号)。不传 target* 则默认: 当前农历年月日 + 出生时辰。⚠️ 双轨干支铁律: 对外讲「X 日签约 / X 月运势」必用「真实干支」, 严禁用「宫位编号」当日子说。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayYes出生日 (1-31)
hourYes出生小时 0-23 (24 小时制, 非时辰地支)
yearYes出生年 (阳历; calendarType=lunar 时填农历年)
monthYes出生月 (1-12)
genderYes性别
minuteNo出生分钟 (默认 0; 配合 longitude 做真太阳时精修)
longitudeNo出生地经度 (东经正/西经负). 传了即启用真太阳时修正
targetDayNo流日目标农历日 (默认当前农历日)
targetHourNo流时目标小时 0-23 (默认出生时辰)
targetYearNo流年目标年 (默认当前农历年)
isLeapMonthNo是否闰月 (仅 calendarType=lunar 有效)
targetMonthNo流月目标农历月 (默认当前农历月)
calendarTypeNo历法: solar=公历(默认) / lunar=农历solar
timezoneOffsetNo时区偏移 (UTC+8=8, UTC-5=-5). 需配合 longitude

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
小限Yes
流年Yes
流日Yes
流时Yes
流月Yes
serviceYes
大限列表Yes
流运目标Yes
双轨干支提示Yes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / targetDay / description
      Previous value: -"流日目标农历日 (默认本命农历日)"New value: +"流日目标农历日 (默认当前农历日)"
    • changedInput schema / properties / targetMonth / description
      Previous value: -"流月目标农历月 (默认本命农历月)"New value: +"流月目标农历月 (默认当前农历月)"
    • changedInput schema / properties / targetYear / description
      Previous value: -"流年目标公历年 (默认当年)"New value: +"流年目标年 (默认当前农历年)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "service": {
      +      "type": "string"
      +    },
      +    "双轨干支提示": {
      +      "type": "string"
      +    },
      +    "大限列表": {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "小限": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "流年": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "流日": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "流时": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "流月": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "流运目标": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "service",
      +    "流运目标",
      +    "大限列表",
      +    "小限",
      +    "流年",
      +    "流月",
      +    "流日",
      +    "流时",
      +    "双轨干支提示"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds critical behavioral details: each layer returns 命宫地支, 四化, and dual-track gan-zhi, plus the iron rule to use 真实干支 instead of 宫位编号 for external communication. This is valuable context beyond 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 two dense sentences plus a warning, all front-loaded with the core purpose. Every clause adds information—no padding or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool (6 layers, 14 params, output schema exists), the description covers the computation basis, output contents, default behavior, and a critical usage rule. It implies the requirement of a natal chart with '本命盘基础上' but does not explicitly mention needing to call ziwei_chart first; otherwise complete.

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?

Schema coverage is 100%, giving a baseline of 3. The description adds meaning by explaining the target* default behavior (defaults to current lunar date and birth hour), clarifying the parameter family's purpose. The dual-track warning also aids interpretation of parameter-related outputs.

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 tool computes 6 layers of transits (大限/小限/流年/流月/流日/流时) based on the natal chart. It distinguishes itself from siblings ziwei_chart and ziwei_reading by focusing on luck-period calculations, using the specific verb '计算' and resource '运限'.

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 implies usage for transit/luck-period analysis and explains default target behavior (current lunar date + birth hour). However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.