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

Beyond the annotations, the description discloses substantial behavior: historical time zone and DST handling, longitude and equation of time, local true solar time expressed in Beijing time, the 23:00 day change, repeated and nonexistent local times, and the Gregorian date range. It also states that the tool returns chart facts without interpretation rules and describes language-dependent output behavior. The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, and the description is consistent with them.

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 description is front-loaded with purpose and then proceeds through parameters, time handling, and output behavior in a logical order. Most sentences carry necessary domain or invocation information, but the date range is repeated in both English and Chinese, and the single dense paragraph could be more scannable. The verbosity is largely justified by the tool's complexity, but there is minor redundancy.

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 complex chart-calculation tool with no output schema, the description covers the input constraints, time-zone and DST semantics, dependency requirements, date range, and what the return contains: nine-palace chart facts and optional birth-year stem locations without interpretation rules. It also explains language effects on chart text and glossary fields. Nothing essential for correct invocation appears 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 already high at 83%, but the description adds important meaning: date/time are local Gregorian wall-clock values at placeId, placeId omission has a specific default, daylightSaving is only needed for ambiguous repeated times, and birthYearPillar must be a full sexagenary pillar from bazi_chart rather than a numeric year or single stem. It also explains that language=en adds English conventions and a field glossary. These details go well beyond the schema field descriptions.

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 specific verb and resource: calculate an hour-based Qimen chart using the chai bu method and rotating plate only. It also distinguishes related dependencies by naming search_birth_place for placeId and bazi_chart for birthYearPillar, and notes that year/month pillars can differ from Bazi. This lets an agent identify the 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 description gives clear operational guidance: placeId comes from search_birth_place, omitting it uses the configured reference place, and birthYearPillar must be obtained from bazi_chart first. It also states that repeated wall-clock times require an explicit daylightSaving choice and nonexistent times are not calculated. It does not explicitly contrast this tool with true_solar_time or bazi_chart as alternatives for the same user intent, so it falls short of full when/when-not guidance.

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