Western Astrology Chart

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

readOnlyHint=true already tells the agent this is a safe, non-mutating computation, lowering the bar. The description adds genuine value beyond that — '低精度' precision warning, the 1800-2100 supported range, and the note that transit planets are overlaid onto natal houses rather than recomputed. It still says nothing about error behavior for out-of-range or inconsistent inputs (e.g. a lunar date missing full Y/M/D/H/M) or about what the returned chart contains.

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 core purpose is front-loaded in the first clause and the optional modes follow after a semicolon, so the paragraph has a usable shape. The trailing clause '可选独立问事时空起盘预览、合盘、显式地点太阳返照及带独立时区坐标的非传统候选相对排序' is a heavily stacked noun run that takes effort to parse and could be split into discrete sentences.

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?

With 32 parameters, a nested partner object, and a dense allOf/anyOf conditional schema, this is one of the more complex tools in the sibling set, and the description gives only the capability envelope. There is no output schema, so the description could have described the return (natal placements, house cusps, transit overlay) but does not, and it never states the conditional-requirement logic that dominates the schema.

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 13% across 32 parameters, so the description must carry most of the semantic load, and it only partially does so: it names the parameter families (birth calendar, civil time, timezone, coordinates, house system, transit moment) but adds no detail on the conditional requirements — that lunar dates must use the year/month/day/hour/minute fields, that horary needs its own timezone plus coordinates, or that solar_return_longitude and solar_return_latitude are mutually dependent. It names the groups without resolving their constraints.

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 first clause states a specific verb and resource — '计算 1800-2100 年低精度西方占星本命盘' — with an explicit era bound and precision qualifier. The label '西方占星' is the discriminator that separates it from the sibling calculate_chart tools for Vedic, bazi, ziwei and qizheng traditions. An agent can identify this tool without opening the 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 tradition label ('西方占星') gives a clear implicit routing rule against the four sibling chart calculators, and the enumerated optional modes (horary preview, synastry, solar return, electional ranking) tell the agent which capabilities this tool covers. However, there is no explicit 'use X instead when…' statement, and no guidance on prerequisites such as supplying a birth time for a reliable house cusp placement.

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