FateStar Ziwei

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

Annotations already mark the operation as read-only and idempotent, so the description focuses on additional behavioral context: it uses the FateStar engine with 102 stars, San He faction transformations, true solar time correction, and no third-party libraries. It also flags a special Geng-stem rule (化科=天同 / 化忌=太阴), which is a valuable caveat for correctness. No contradiction with 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?

The description is front-loaded with purpose, then uses a colon-list to enumerate return fields, followed by engine context and a warning. Every sentence contributes unique information; the length is justified by the tool's complexity and avoids redundant or promotional wording.

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 high complexity (10 parameters, rich output schema), the description is remarkably complete: it covers input calendar types, all major output categories, engine provenance, faction-specific rules, and a correctness caveat. The output schema existing means return-value detail is not required in the description, yet the description still names the main outputs.

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?

The input schema already provides 100% parameter coverage, with descriptions for all 10 parameters including enums, ranges, defaults, and dependencies (e.g., longitude enables true solar time). The description reinforces the solar/lunar and true solar time concepts but does not add meaningful per-parameter syntax or format details 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?

The description opens with a specific verb-object pair: '生成紫微斗数...完整本命盘' (generate complete natal chart), clearly identifying the tool's resource and output. It enumerates the chart components (十二宫, 四化, 格局, etc.), distinguishing it from sibling tools like ziwei_reading and ziwei_transits.

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 establishes when to use the tool: when the user provides birth date/time and wants a complete natal chart, including optional lunar calendar input. However, it does not explicitly exclude transits or reading use cases or name sibling tools, so it lacks a clear when-not-to-use statement.

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?

Beyond annotations, the description discloses paid nature, credit consumption based on question length/mode, requirement for FSFSKey, fallback behavior on 402, and that interpretation merges knowledge engine with ancient texts while chart facts are deterministic. No contradictions with 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?

The description is longer than average but well-structured with clear sections: core purpose, call condition, payment/key warning, no-key guidance, and 402 fallback. Every sentence provides operational value, though it could be tightened slightly (e.g., key setup duplicated in multiple places).

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 (paid, key-dependent, fallback behavior, sibling tools), the description is comprehensive. It covers when to use, payment mechanics, key acquisition, error handling, and relationship to ziwei_chart. The presence of an output schema means return-value details are not required.

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 baseline is 3. The description adds meaningful context beyond the schema: explains the apiKey can come from environment variable, ties credit cost to question length (short questions free), and clarifies the hour is 24-hour, not earthly-branch. This adds value over the schema alone.

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 explicitly states the tool calls FateStar's Zheng Daqian AI astrologer to interpret natal charts and answer life questions (love/career/wealth/health). It clearly distinguishes itself from deterministic chart tools (ziwei_chart, ziwei_transits) by noting it provides AI-powered interpretation while chart facts come from deterministic 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 gives explicit conditional usage: only call when the user explicitly opts into hosted interpretation and confirms possible point deduction. It also states that ordinary questions should default to free chart data, and provides a clear fallback to ziwei_chart + own interpretation when no key is available or when points run out (402).

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 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.

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.

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.

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.

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.

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.