Day Master

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

Annotations already declare a safe, idempotent read, so the bar is lower; the description adds the cost (10 credits, Tier 1), the endpoint, and the required parameter, which are genuinely useful. However it omits the behaviorally significant fact that dayBoundary (23:00 vs midnight) and trueSolarTime can change which day stem is returned, and it says nothing about time/timezone requirements in practice.

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 sentences of substance plus a compact metadata block, front-loaded with what is returned. The bracket metadata is boilerplate but short and high-value (cost, required param, endpoint), so little is wasted.

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 prose. But for an 8-parameter tool where day boundary, true solar time and timezone materially determine the answer, the description is silent on how those interact — an agent could easily call with only a date and get a different day master than intended.

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 only 25% across 8 parameters, so the description is expected to compensate, but it contributes only 'Required: date'. The most consequential knobs — dayBoundary enum, trueSolarTime, longitude, time, language — are undocumented here and only partly in the schema, and the description never explains that the day pillar depends on boundary/solar-time settings.

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 a concrete output (day stem element, yin/yang polarity, archetype text) and explains the concept as the 'self' character in BaZi, so an agent knows exactly what it produces. It does not explicitly distinguish itself from the many BaZi siblings (year/month/hour pillar, four_pillars, chart), which leaves the routing decision to inference.

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 when-to-use / when-not guidance and no named alternative among the ~20 bazi_* siblings. The line 'the self character from which all other pillars are interpreted' implies a primacy, but nothing tells an agent whether to call this alone, or after astroway_bazi_four_pillars / astroway_bazi_chart.

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