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

With no annotations, the description carries the full burden. It discloses that results are deterministic, that timezone conversion to Beijing time occurs, that lunar input ignores timezone, and that the tool does not perform interpretation. It doesn't explicitly state read-only nature or absence of side effects, but for a排盤 calculation this is largely inferable from the description's scope.

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 front-loaded with purpose and organized with bullet points for outputs, timezone, positioning, and alternatives. It is appropriately detailed for a complex deterministic tool, though the output list is somewhat lengthy; every section still serves a clear 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?

No output schema exists, so the description must explain return values, which it does comprehensively (pillars, ten gods, etc.). It also covers timezone handling and scope boundaries. It is nearly complete for a 10-parameter tool, lacking only minor details like error behavior or input validation.

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%, so the schema already documents all parameters. The description adds guidance that overseas users should provide timezone and that longitude enables true solar time correction, but this largely echoes the schema descriptions rather than adding new meaning beyond the structured fields.

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 states a specific verb and resource: 計算八字四柱（基礎排盤）. It clearly distinguishes this tool from siblings by stating that 大運/流年/流月/流日 use separate list tools, and that interpretation-layer analysis is not its job. An agent can identify it as the deterministic charting tool.

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?

Explicit when-to-use is given: input birth time to get deterministic results. It names alternatives for 大運/流年 etc. and explicitly excludes interpretation (五行強弱, 格局, 用神, 神煞), telling the agent to handle those itself. This fully covers when and when-not to use.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It describes the returned fields (a form of output transparency) but does not state that the operation is read-only, non-destructive, or mention any other behavioral traits like authentication or rate limits. This is a significant gap for a tool with zero 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 concise and front-loaded: it starts with the tool name, then lists the returned fields, and ends with a usage sentence. The only minor redundancy is the first sentence restating the title, but otherwise every sentence earns its place.

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 absence of an output schema, the description usefully lists the return fields (大運干支, 起止虛歲, etc.), which is essential. It also provides a usage context. However, it omits any behavioral safety information, which would be expected without annotations, leaving a small gap.

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%, so all parameters are well documented in the input schema. The description adds no additional parameter meaning beyond what the schema provides, which is the baseline expectation when schema coverage is high.

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 states a specific verb and resource: it returns the DaYun cycles (十年一運) with listed fields. It is clear that this tool is for the major ten-year luck periods, distinguishing it implicitly from siblings like bazi_liunian (annual) or bazi_basic (basic chart), though no sibling is named explicitly.

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 an implied usage context: '用於了解人生各階段的運勢大框架' (used to understand the overall framework of fortune in each life stage). However, it does not explicitly state when to use this tool versus alternatives like bazi_basic or bazi_liunian, leaving comparisons to inference.

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

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.

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.

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.

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.

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.

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.

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

未提供 annotations，描述披露會回傳大運、流年、流月、公曆日期與干支日等內容，對讀取型工具而言提供部分透明度；但未說明是否為唯讀、是否需要完整出生資料、有無副作用或限制。

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?

開頭先點明工具用途，接著用條列列出回傳上下文，最後補一句使用情境；沒有冗餘鋪陳，結構前重後輕。

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?

工具參數多（12 個、7 個必填）且無 output schema，描述雖列出部分回傳欄位，但未交代必填出生資料與 ganzhiYear/ganzhiMonth 查詢月份之間的整體輸入邏輯；靠 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?

schema 描述覆蓋率 100%，參數意義已由 schema 完整承載；描述僅提到「指定月份」，未對 12 個參數（尤其出生資料 vs 查詢月份）增加額外語意。

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?

描述以具體動詞「返回」與資源「每日運勢」界定工具，並說明以指定月份為範圍；與 bazi_liunian/bazi_liuyue 的年度/月度粒度有別。但未點名任何兄弟工具，故未達 5。

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?

「用於精細的日期選擇」給出明確使用情境，但沒有說明何時不該用、或與 bazi_liuyue/calendar_convert 等替代工具的取捨。

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

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

With no annotations, the description carries the full burden and does add real domain behavior: solar-term months, exact boundaries (立春/寅月), and that 丑月 crosses the Gregorian year line. However it says nothing about whether natal birth data is required, permissions, rate limits, or result size, so transparency is partial.

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?

Front-loaded with the important 節氣月 caveat, then the return shape, then use case – a sound ordering. It repeats the title phrase '八字流月列表' at the start, which is minor waste, but overall it is tight.

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?

11 parameters (6 required) and no output schema, so the description's enumeration of return fields is genuinely helpful. But it leaves the critical ambiguity between year/ganzhiYear and the required birth-data inputs unresolved, which an agent needs in order to call it correctly.

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%, so the baseline is 3. The description mentions '指定年份' but does not disambiguate the two year inputs (year vs ganzhiYear) or explain how a query year relates to the required birth date fields, adding little beyond the schema.

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?

States a specific verb+resource: returns the 12 monthly fortunes for a given year, enumerating the returned fields (干支月, 節氣起止, 公曆日期範圍). It is largely distinguishable from bazi_liunian/bazi_liuri by the '12 months' scope, though it never names those siblings directly.

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?

'用於規劃年度活動時機' gives an implied use context (annual planning), but there is no explicit when-not or routing to siblings such as bazi_liunian for yearly or bazi_liuri for daily granularity. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that leap-month allocation is astronomically determined and that outputs are authoritative, which is genuinely useful, but says nothing about error handling for out-of-range dates, return shape, or performance. Adequate but incomplete for a zero-annotation tool.

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?

Front-loads the purpose, then the rationale, then the two directions as a compact bulleted list. Every sentence earns its place with no 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?

With no output schema and no annotations, the description needs to stand alone, and it does cover both directions, leap-month input marking, and the returned components (lunar date, ganzhi, zodiac). It omits error/range behavior for invalid combos, keeping it just short of fully self-contained.

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%, so the baseline is 3. The description reinforces that direction selects the input interpretation and that isLeapMonth marks a leap month only on the lunar→solar path, adding modest meaning, but introduces no new format or constraint detail beyond the schema.

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?

States a specific verb+resource ('農曆與公曆日期互轉') and enumerates scope beyond the name: 閏月處理, 干支年月日, 生肖. An agent can distinguish this from siblings like jieqi_query or the bazi_* family without opening the schema.

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?

Gives a clear reason to use it (AI commonly mis-guesses leap-month assignment, this returns authoritative data) and spells out the two supported directions. It does not explicitly name which sibling to prefer when, so it stops short of 5, but the usage context is well established.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this is a pure computation/chart-casting tool with no interpretation ('只負責排盤') and specifies the output is Markdown for AI consumption. It does not mention permissions or error behavior, but for a side-effect-free calculation that gap is minor.

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?

Headings and bullet lists front-load the recommended usage, and every section maps to something actionable. It is somewhat long, and the brief 三式 background sentence is ornamental, but the size is defensible for an 11-parameter tool with two input modes and no output schema.

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?

With no output schema and no annotations, the description compensates by enumerating the returned chart components and the Markdown format, which is exactly what the agent needs to plan interpretation. The absence of any tool-selection guidance relative to its many siblings is the one remaining gap.

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 coverage is 100%, so the baseline is 3, but the description adds real value by grouping the 11 flat parameters into two coherent modes (recommended Gregorian year/month/day/hour vs expert jieqi/dayGanZhi/hourGanZhi) and noting simpl./trad. character acceptance for jieqi, semantics the schema alone does not convey.

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 states a specific verb+resource (排盤 for 大六壬) and explicitly bounds scope: '本工具只負責排盤，斷課解讀交給 Agent'. It also situates the tool within the 三式 tradition and enumerates exactly what the chart contains (天地盤、四課、三傳、十二天將、格局、神煞), so an agent can distinguish it from qimen/bazi/ziwei siblings.

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?

It clearly separates a 推薦用法 (input Gregorian time, system derives the rest) from a 專家模式 (explicit calendar quantities, '一般無需使用'), which tells the agent which parameters to reach for. What it does not do is explain when to choose this tool over the other 17 divination siblings for a given question, leaving tool-selection to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source ('權威曆表'), the precision, and the return structure. The read-only nature is implied by '查詢' rather than stated, and there is no explicit note on permissions or limits, keeping it short of a 5.

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?

Front-loaded with purpose, then rationale, then output and use cases; the concrete 立春 example earns its place by justifying why the tool is needed. Slightly verbose in the rationale line but no real waste.

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 single-parameter read tool with no output schema, the description supplies the output shape (sorted 24 terms with name, precise time, Gregorian date), which compensates for the missing schema. Behavior and return content are adequately covered, with only minor gaps like error handling for out-of-range years.

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% and the single 'year' parameter is fully documented with its 1900-2100 range in the schema. The description only restates '指定年份' and adds no format or edge-case detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('查詢...二十四節氣的精確時刻') with explicit scope (per-year, second precision, Beijing time). It is clearly distinguishable from abstract siblings like calendar_convert. An agent can tell what this does without opening the schema.

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?

It gives clear usage context by explaining that solar-term times cannot be reliably computed by the model and must come from this authoritative table, and names use cases (排盤驗證, 擇時分析, 曆法考證). However, it never explicitly routes to or away from siblings such as calendar_convert, so the when-not guidance is implicit rather than stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the default Beijing time, timezone conversion behavior, lunar/gregorian handling, and that output is Markdown. It omits any permission/rate/error behavior, but for a pure computation tool the defaults and output format are the material traits.

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?

Front-loads the purpose, then uses structured bullets for the return contents and a clear '爻值說明' block for the input encoding. Efficient overall, though the long enumerated return list is more than strictly needed for argument selection.

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?

With no output schema, the description usefully enumerates the returned chart components (本卦/變卦, 納甲, 六親, 六神, 世應, 動爻, 日干支/月建/旬空) and covers time defaults, making it sufficient for correct invocation of a complex 8-parameter tool.

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%, so all 8 parameters are already documented, including the yaoValues enumeration and timezone/lunar semantics. The description restates the 6/7/8/9 meanings and input order rather than adding new meaning, so baseline 3 applies.

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?

States a specific verb+resource (六爻排盤 基礎排盤) and the divination method itself cleanly distinguishes it from the sibling divination tools (meihua_basic, daliuren_basic, qimen_basic, bazi_basic). An agent can tell exactly which system produces the chart without opening the schema.

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 explains the mechanics of the input (yao value meanings, bottom-to-top order, time defaults) but offers no guidance on when to choose this tool over the other divination siblings. Usage is implied by the method name only, not stated.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the complete return contents (本卦/變卦/互卦, 體用分析, 動爻) and the output format (Markdown). It omits error/validation behavior and timezone-default nuances, keeping it below 5.

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?

Front-loaded summary followed by tightly bulleted modes and return fields; the embedded 農曆 algorithm formulas are arguably load-bearing since they explain the resulting 卦. Slightly long, but every section contributes.

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 10-parameter tool with no annotations and no output schema, the description compensates by enumerating return values, mode selection and output format. Remaining gaps are minor edge-case behaviors rather than core task information.

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%, so the baseline is 3. The description reinforces the method enum and the lunar/time-based casting logic, but adds little syntax beyond what the schema already documents for each parameter.

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?

States a specific verb+resource (梅花易數排盤/起卦) and enumerates its two casting modes and full output structure. An agent can tell what the tool does without opening the schema, though it never names how it differs from sibling systems like qimen_basic or liuyao_basic.

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?

It explains the conditions for the two modes (time vs number), which is implied guidance for choosing method. However, there is no explicit when-to-use/when-not or routing versus the many sibling divination tools, so usage is only partially addressed.

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

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

With no annotations provided, the description carries the full burden. It thoroughly describes the output contents (e.g., 陰陽遁, 九宮, 八門, 九星, 八神) and the output format (Markdown with ASCII 九宮格), which helps set expectations. It does not explicitly state that the operation is read-only or mention side effects, but for a pure calculation tool this is largely implied and the output disclosure is strong.

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 well-structured with a clear introduction, bullet-pointed output details, and parameter options. It is front-loaded with the core purpose. The background sentence about Qimen being one of the three styles is somewhat extraneous for an agent, and the description is lengthy, but the length is justified by the tool's complexity.

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 complexity (10 parameters, 3 enums, no output schema) and the absence of annotations, the description is complete enough. It details the output format and contents, explains parameter options, and covers special cases like timezone handling and lunar input. An agent has sufficient information to invoke the tool correctly and understand what it will receive.

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%, so the schema already documents all 10 parameters. However, the description adds meaningful context beyond the schema for several parameters: it explains what each pan type is used for (e.g., 時盤 for immediate prediction) and clarifies the difference between 轉盤 and 飛盤. It does not elaborate on parameters like isLunar or timezone beyond what the schema provides, so it improves semantics without being exhaustive.

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 states a specific verb and resource: '奇門遁甲排盤（基礎排盤）' – it constructs a basic Qimen Dunjia chart. The parenthetical '基礎' distinguishes it from the sibling tool qimen_yongshen, which likely handles specialized applications. An agent can immediately tell what this tool does and how it differs from related tools.

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 by stating '輸入時間信息，返回完整的奇門盤面', but it offers no explicit guidance on when to choose this tool over alternatives like qimen_yongshen or other divination tools. The detailed explanations of pan types and styles describe parameter choices rather than tool selection, leaving the when-to-use decision to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully delimits scope by declaring analysis is "僅確定性事實" and explicitly declining to judge auspiciousness (leaving that to the AI), and it states the output is structured Markdown — meaningful behavioral disclosure for a pure-computation tool.

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?

Front-loaded with the one-line purpose, then organized under bolded sub-headers and a bulleted analysis list. Appropriately sized for a complex 13-parameter tool, though a few lines are near-redundant with the schema enums.

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?

No output schema exists, but the description enumerates the analysis components and describes the return format (structured Markdown), which is what an agent needs here. Given the tool's complexity, this is close to complete, with only the prerequisite on qimen_basic left implicit.

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%, so the schema already documents all 13 parameters including the 14-value shiLei enum. The description restates the matter categories and mentions nianGan-driven 年命落宮, but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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?

States a specific verb+resource: selects the yongshen (用神) by matter category and analyzes it. It also anchors itself as extending qimen_basic ("在基礎排盤基礎上"), so an agent can distinguish it from the sibling without opening the schema.

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?

Implies the usage context clearly: run it after a basic chart, driven by a matter category (14 enumerated). It establishes its relationship to qimen_basic but never names an explicit alternative or states when NOT to use it, so it stops short of a full when/when-not routing.

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

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

With no annotations, the description carries full burden and covers the two behaviors that matter for a computation tool: timezone handling (defaults to Beijing time, overridden by the timezone param) and output form (structured text for AI interpretation). It omits any note about the advanced params (targetYear/includeDecades/includeMutagen) that the schema exposes, so it is strong but not exhaustive.

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?

Purpose is front-loaded, followed by a scannable bulleted output inventory, then the timezone caveat and output format note. Every element earns its place; the only minor cost is the header/consumption note at the end that slightly delays the key timezone rule.

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 14-param tool with no output schema and no annotations, the description compensates by enumerating the return payload (palaces, stars, brightness, life/body palaces, five-element bureau, four transformations) and the timezone rule. The advanced parameters (targetYear, includeDecades, includeMutagen) are left unexplained, which is a modest gap.

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%, so the schema already documents all 14 parameters (including the timezone and gender semantics). The description restates the timezone rule but adds no syntax or meaning beyond what the schema provides; baseline 3 is appropriate.

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?

States a specific verb (計算/calculate) and resource (紫微斗數命盤) with the scope qualifier 基礎排盤, then enumerates the returned chart components. This clearly distinguishes it from the ziwei_daxian/liunian/liuyue siblings by implication of 'basic natal chart', though it never names an alternative explicitly.

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?

Conveys the trigger condition (input birth time to get a natal chart) and one important usage rule – provide timezone for overseas births. However it offers no when-not-to-use guidance and does not route the agent to ziwei_daxian/liunian for advanced or time-based analysis, so usage is only implied.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It lists return fields, implying a read-only query, but it does not state that the tool is side-effect-free, does not mention any authentication or rate-limit behavior, and does not clarify that it merely computes data. Minimum viable but with clear gaps.

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 short, front-loaded, and uses a bullet list to enumerate return fields efficiently. Every sentence earns its place; no redundant or vague filler.

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?

There is no output schema, so the description correctly enumerates the returned fields. It also supplies a usage context. It does not, however, explain how it relates to sibling tools or disclose any behavioral traits, leaving minor gaps for a complex astrology tool with 11 parameters.

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%, and the description adds no meaning for any of the 11 input parameters (year, month, day, hour, gender, etc.). Baseline 3 is appropriate when the schema fully documents parameters and the description does not supplement them.

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 names the specific resource (紫微大限), states it returns decade cycles, and enumerates the returned fields (起止虛歲, 公曆年份, 宮位名稱, 主星配置, 四化). This clearly distinguishes it from siblings like ziwei_liunian or ziwei_xiaoxian, but it never explicitly contrasts those alternatives, so it falls short of a 5.

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?

It provides a clear use context: '用於了解人生各階段的運勢大框架' (to understand the broad framework of life-stage fortunes). However, it gives no explicit when-not conditions or named alternatives for other Zi Wei tools, so it lacks the exclusion guidance needed for a 5.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It implies a read-only list/return operation and lists the output fields, but it does not state permissions, side effects, or determinism. With no annotations, this is only partially complete.

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 short and front-loaded, with the return fields presented as a scannable list. Each part—purpose, output fields, and usage note—earns its place.

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 12 parameters, 100% schema coverage, no annotations, and no output schema, the description helpfully lists the returned fields and usage context. It still omits behavioral guarantees and sibling routing, but is reasonably complete for invocation.

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% and the description adds no parameter-level detail beyond the schema. The schema already documents all 12 inputs, so baseline 3 applies.

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 states it returns 流年 information across a specified year range and enumerates the returned fields (公曆年份, 干支年, 虛歲, etc.). This clearly identifies the annual-scope ziwei tool, though it does not explicitly name sibling alternatives such as ziwei_liuyue or ziwei_liuri.

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?

It says it is used for analyzing multi-year fortune trends (用於分析多年運勢趨勢), giving clear context for when to use it. However, it does not state when not to use it or name alternative sibling tools.

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

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

No annotations exist, so the description carries the full burden; it discloses in detail what the return contains (multi-layer context and the complete 四化 system) and explains the negative-number leap-month convention. It does not state read-only nature or failure/edge behavior, but for a deterministic fortune calculation it is fairly transparent.

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?

Front-loaded with the tool name, followed by a clean bulleted output inventory and a short note on leap months and use case. Well organized with little waste, though the summary line is slightly under-informative.

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?

With 12 parameters, no output schema, and no annotations, the description does the necessary work by enumerating the returned fields and the leap-month encoding. Minor ambiguity remains about whether a specific 'day' input is required to scope the month's list, but overall an agent has enough to invoke it.

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 coverage is 100% and all 12 parameters are documented, so the baseline is 3. The description's note that leap months use negative numbers (e.g. -6) restates what lunarMonth already documents in the schema, adding no new semantics.

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 states a specific verb and resource ('紫微流日列表', returns 每日運勢 within a lunar month) and enumerates exactly what it computes (大限/流年/流月 context, lunar↔Gregorian mapping, 干支日及宮位, full 四化 system). This clearly separates it from ziwei_liunian/liuyue/daxian siblings by its daily granularity, though no sibling is named explicitly.

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?

'用於精細的日期選擇' gives only a one-line intent with no explicit when-not-to-use or alternative tool (e.g. ziwei_liuri vs bazi_liuri). Usage is implied but left to inference.

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

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

No annotations are provided, so the description bears the full burden. It discloses a critical behavioral rule about using lunar months (not solar terms) with detailed boundary logic, and enumerates the returned data. However, it does not state whether the operation is read-only or mention any side effects, leaving some behavioral gaps.

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 well-structured with front-loaded purpose, a prominent important note, and clear bullet points. Every sentence contributes useful information without 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?

With no output schema, the description sufficiently explains the return contents (context info, lunar months, palaces, four transformations). It covers the essential complexity for an 11-parameter tool, though it omits details like return format or error handling.

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%, so the schema fully documents all parameters. The description only adds that the year specifies the query target ('指定年份'), which is marginal beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 it returns monthly fortune for a specified year, with a specific verb-resource combination ('返回指定年份的流月運勢'). It distinguishes itself from siblings by emphasizing '流月' (monthly) and detailing output content, though it does not explicitly name alternatives like ziwei_liunian.

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?

It provides a when-to-use hint ('用於規劃年度活動時機') but lacks explicit guidance on when to choose this over monthly or annual alternatives, and no exclusions are stated. The usage context is implied rather than fully specified.

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

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

With no annotations, the description carries the behavioral burden and discloses returned fields (虛歲, 公曆年份, 宮位, 主星, 大限, 四化) and calculation rules (出生年支起宮, 男順女逆). It omits side-effect/safety statements, but for a calculation tool this is largely inferable.

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 front-loaded, uses bullet points for returned fields, and separates the 小限 vs 流年 comparison and hierarchy clearly. Each section earns its place for a complex 12-parameter tool.

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 no output schema, the description usefully lists the fields returned and the conceptual level of 小限. It could more explicitly state the return structure and how startAge/endAge bound the output, but it is otherwise complete for this domain calculator.

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%, so the schema already documents all 12 parameters. The description adds conceptual context about 小限 but no additional parameter-specific semantics or input format details.

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 names the resource (紫微小限列表) and explains what 小限 is, including returned fields. It also distinguishes conceptually from 流年 via a comparison and hierarchy. However, it lacks an explicit action verb and does not name sibling tool IDs like ziwei_liunian.

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?

It provides clear context for when the concept applies, contrasting 小限 with 流年 and stating the hierarchy 大限 > 小限 > 流年 > 流月 > 流日. It does not give explicit when-not guidance or name alternative sibling tools directly.

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