Four Pillars (full)

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

Annotations already establish the safe, idempotent, deterministic read profile, and the description goes beyond them with substantive computation semantics: the 60-jiazi anchor (1990-01-01 = Bing-Yin), 23:00 local rollover for day/hour, and exact Lichun and 節 instants for year/month. These boundary rules are exactly the kind of detail an agent needs and cannot get from 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?

Two front-loaded sentences carry the substance, followed by a compact metadata block (group, endpoint, required, cost). Every line is informative, though the endpoint and group lines are largely boilerplate for an agent that already has the tool name.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies the ambiguous edge cases (hour pillar optionality, day/hour vs year/month rollover instants, jiazi anchoring), leaving nothing critical for a correct call beyond the undocumented `language` parameter.

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 only 40%, and the description compensates partially by explaining the role of `time` and implying local-clock semantics for timezone. However, `language` and `date` have no description anywhere, and `timezoneOffset` is only defined by the schema, so the low-coverage gap is not fully closed.

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 it returns all four pillars (year, month, day, hour), which is a specific resource and clearly the 'full set' counterpart to the single-pillar siblings like astroway_bazi_year_pillar and astroway_bazi_hour_pillar. It never explicitly names those alternatives, so the differentiation only works by implication from 'All four pillars'.

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 one real usage instruction is 'Pass `time` to compute the hour pillar', which tells the agent when the hour pillar becomes available. There is no statement of when to choose this tool over astroway_bazi_chart or the individual pillar tools, so routing is left to inference.

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