命盘 Mingpan

八字流年列表

bazi_liunian

Calculates annual BaZi fortune (liunian) across a specified year range from birth data, returning Gregorian and stem-branch years, virtual age, and governing luck cycles to analyze multi-year trends.

Instructions

八字流年列表。

返回指定年份範圍內的流年信息：

公曆年份
干支年
虛歲
所屬大運

用於分析多年運勢趨勢。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>",
      "month": "<month>",
      "day": "<day>",
      "hour": "<hour>",
      "gender": "<gender>",
      "startYear": "<startYear>",
      "endYear": "<endYear>"
    },
    "name": "bazi_liunian"
  }
}

Input Schema

Name	Required	Description
`day`	Yes	日 1-31
`hour`	Yes	時 0-23
`name`	No	命主姓名（可選）
`year`	Yes	公曆年 1900-2100
`month`	Yes	月 1-12
`gender`	Yes	性別（影響大運順逆）
`minute`	No	分 0-59，默認 0
`endYear`	Yes	End year for the range
`isLunar`	No	輸入日期是否為農曆，默認公曆
`timezone`	No	IANA 時區名（如 America/New_York）。默認北京時間；設置後輸入時間按此時區換算為北京時間排盤。農曆輸入時忽略
`longitude`	No	出生地經度（真太陽時校正，可選）
`startYear`	Yes	Start year for the range

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.1.8Sep 30, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / day / description

Previous value: -"Birth day (1-31)"New value: +"日 1-31"

changedInput schema / properties / gender / description

Previous value: -"Gender for fortune direction calculation"New value: +"性別（影響大運順逆）"

changedInput schema / properties / hour / description

Previous value: -"Birth hour in 24-hour format (0-23)"New value: +"時 0-23"

changedInput schema / properties / isLunar / description

Previous value: -"Whether the input date is in lunar calendar (農曆). If true, will be converted to solar calendar internally."New value: +"輸入日期是否為農曆，默認公曆"

changedInput schema / properties / longitude / description

Previous value: -"Birth location longitude for true solar time adjustment"New value: +"出生地經度（真太陽時校正，可選）"

changedInput schema / properties / minute / description

Previous value: -"Birth minute (0-59)"New value: +"分 0-59，默認 0"

changedInput schema / properties / month / description

Previous value: -"Birth month (1-12)"New value: +"月 1-12"

changedInput schema / properties / name / description

Previous value: -"Subject name (optional)"New value: +"命主姓名（可選）"

addedInput schema / properties / timezone

Added value: +{
+  "description": "IANA 時區名（如 America/New_York）。默認北京時間；設置後輸入時間按此時區換算為北京時間排盤。農曆輸入時忽略",
+  "type": "string"
+}

changedInput schema / properties / year / description

Previous value: -"Birth year (e.g., 1990)"New value: +"公曆年 1900-2100"

First observedv0.1.3Jun 11, 2026

TDQS

B3.4/5.0

Behavior3/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 does disclose the main output fields (公曆年份, 干支年, 虛歲, 所屬大運), which is useful given there is no output schema, but it says nothing about side effects, authentication, statelessness, or error behavior.

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 short, front-loaded, and uses a bulleted list for the returned fields followed by a usage statement. The opening line lightly repeats the title, but the overall structure is efficient and readable.

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?

For a 12-parameter tool with no output schema and no annotations, the description gives a useful summary of returned fields and purpose. However, it does not explain how optional parameters like timezone, isLunar, or longitude interact, nor does it clarify relationships to sibling tools, leaving some contextual gaps.

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 all 12 parameters are already documented in the input schema. The description only alludes to the year range via 指定年份範圍 and adds no meaningful parameter semantics beyond what the schema provides.

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?

States a specific resource (八字流年) and scope (指定年份範圍), and enumerates the returned fields. It is clear this is a yearly fortune-list tool, though it does not explicitly differentiate itself from bazi_dayun, bazi_liuyue, or bazi_liuri beyond the name and returned fields.

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 closing line gives an implied use case: analyzing multi-year fortune trends. However, it does not state when to choose this over sibling tools such as bazi_liuyue or bazi_liuri, nor does it mention any exclusions or prerequisites.

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

Deploy Server