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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context - the endpoint, the required input, and the 10-credit Tier 1 cost - but says nothing about accuracy caveats (e.g. how dayBoundary or trueSolarTime affect the derived day master), which matters for a BaZi computation.

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?

Two front-loaded sentences that state the returned content first, followed by a compact metadata block. Little waste; the structure is efficient for scanning.

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?

An output schema exists, so return values need no elaboration, and the description adequately frames the payload. However, for a 10-parameter astrological computation it leaves key gaps: no guidance on sibling selection and no explanation of the parameters that alter the day master calculation.

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 40%, and the description contributes nothing beyond restating that 'date' is required. Parameters that materially change a BaZi day master - dayBoundary, trueSolarTime, timezone, and the undocumented 'time' and 'language' - get no explanation here, so the description fails to compensate for the coverage gap.

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 the concrete output (day stem element, yin/yang polarity, canonical archetype) and frames it as 'the self character in BaZi from which all other pillars are interpreted,' which lets an agent distinguish it from broader outputs like bazi_four_pillars. It lacks an explicit action verb, but the resource and returned payload are 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?

Beyond the metadata line '[Required: date]', there is no guidance on when this tool is preferable to siblings such as bazi_four_pillars, bazi_chart, or bazi_strength. The 'self character' framing implies a use case but names no alternatives or exclusion conditions.

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