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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered and the description's main added value is the caveat that the chart date is the dwelling's factual date (built/moved-in/renovated) rather than the subject's birth time — a real misuse trap it defuses. It does not describe the returned chart, but an output schema exists, so that gap is largely covered elsewhere.

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?

Three short sentences: what it does, when to use it and what to use instead, then the date caveat. Nothing is repeated and the routing alternative is front-loaded before the caveat.

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 3-required-parameter charting tool with annotations and an output schema, the description supplies the only things structure cannot: which date to supply, that the date is not a birth time, and where the annual variant lives. Nothing needed to call it correctly is missing.

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, and the description earns above that by telling the agent which real-world date standard_time encodes (建成/入住/改宅) and by excluding birth time, which the schema text alone does not say. It leaves the 0–23 index mapping for zuo_shan/xiang_shan to the schema, which is acceptable given full coverage.

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 opening clause names a specific technique and resource (玄空飞星起盘 / 九宫飞星盘) and states the two inputs that drive it: the house's factual date and the 24-mountain orientation. It goes on to name the sibling it is not (xuankong_liunian), so an agent can separate it from the annual-flying-star tool without opening any 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 second sentence states the trigger condition ('评估阳宅固定风水格局时调用') and explicitly routes the adjacent case ('流年飞星变化改用 xuankong_liunian'). That is both a when-to-use and a when-to-use-something-else, plus a warning about what the date is not.

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