Liu Yao Preview

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

readOnlyHint=true already declares the safety profile, and '不保存记录' is consistent with that rather than contradictory. The description adds genuinely useful behavior beyond the annotation: the output includes precise solar-term/day-moon relations and interpretation context, and the tool deliberately abstains from 用神 selection. However, it says nothing about how casting_mode alters the required input shape or what the joint-bazi branch does.

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?

It is a single dense semicolon-joined clause with no filler sentences, and the input-to-output flow is roughly front-loaded. Readability suffers from cramming four distinct ideas (mode, input capture, computed output, exclusions) into one run-on line, which makes the key mode branch hard to locate.

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 nested conditional allOf branches and no output schema, this is under-specified: an agent cannot learn from the description that digital_altar/quick_record require `changes` while three_coin/manual_line_values require `value`, or that bazi_joint mandates subject. Those are exactly the facts the description needed to supply.

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 only 20% across 10 parameters with nested conditionals, so the description must carry the load. It explains the six-line value set (6/7/8/9) and the yarrow three-change shape, which helps, but bazi_mode, include_subject, subject, focus_area, notes, and locale go entirely unmentioned, including the conditional rule that bazi_joint forces a subject.

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 concrete verb-and-resource pair: it records a real-time casting time plus six line values (yarrow three-changes or 6/7/8/9), then produces a Jing Fang Na Jia hexagram, precise solar-term sun/moon relations, and interpretation context. It also draws two explicit scope boundaries (no automatic 用神 selection, no persistence). It does not differentiate itself from the many other divination.preview_* siblings, but the resource is unambiguous.

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?

There is no statement of when to pick this over divination.preview_meihua, divination.preview_daliuren, or the other preview tools, nor when to choose between the four casting_mode values. The only routing-like signal is the negative scoping (does not pick 用神, does not save), which tells an agent what will not happen rather than when to call it.

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