bazi_compute

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

With no annotations, the description must carry the behavioral burden, and it does disclose that the tool is purely computational with no readings or predictions, and that output conventions for 身强弱/格局 are school-dependent — a genuinely useful caveat for downstream relaying. It does not cover auth, rate limits, or error behavior, but for a deterministic compute tool those are lower-stakes. This is meaningful added context beyond the schema.

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 (input forms, then output payload), and the behavioral constraints follow. The bilingual duplication means the Chinese prohibition on interpretation and the English "no predictions or readings" say the same thing twice, which is the only real slack in otherwise efficient text.

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 return payload (四柱、身强弱、格局、用神), which is the key completeness requirement. It also covers the non-obvious school-convention caveat. What it omits is guidance on calendar-boundary edge cases for a 12-parameter, nested-object input, which keeps it short of a 5.

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?

With 12 parameters and only 58% schema description coverage, the description must add some parameter meaning, and it does explain the three input modes (公历/农历/直接四柱) that drive inputMode, pillars, and isLeapMonth. However, it adds nothing for year/month/day/hour/minute semantics (e.g. whether the year boundary follows solar terms or true solar time interplay), leaving several parameters undocumented in both schema and description. Baseline-adjacent 3.

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 a specific verb and resource ("Compute a BaZi (Four Pillars) chart from a birth datetime") and enumerates the returned artifacts (四柱、身强弱、格局、用神), so an agent knows exactly what is produced. It explicitly frames the tool as computation-only, which distinguishes its purpose from any interpretation-oriented tool. No siblings exist, so no differentiation is required.

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 boundaries: "只做计算，不含解读文案、不做预测" with the instruction to relay structure rather than auspicious/inauspicious verdicts ("转述结果时给结构不给吉凶断语"), plus a caveat that 身强弱 and 格局 definitions vary by school. There are no alternative tools to route between, so only the alternative *framing* (interpretation) is excluded rather than a sibling tool — hence a 4 rather than 5.

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