Day-master strength

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

Annotations already cover safety (readOnly, idempotent, closed-world), so the description is free to spend its words on substance — and it does, disclosing two real methodological limits (the month is weighted like any other branch; the cut points are this API's convention) plus a costing signal (10 credits, Tier 1). That is genuine context an agent needs to interpret the output. It stops short of 5 because it says nothing about whether time/gender change the result or what happens on insufficient input.

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 plus a metadata block, with the core computation front-loaded, so there is little padding. However the prose is jargon-dense ('support-and-suppress', 'weighted hidden-stem count') and the second sentence is written as meta-commentary about the output's caveat field ('The caveat names both limits') rather than telling the agent anything actionable.

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 not be explained, but the tool has twelve inputs at 17% description coverage and the description leaves every one of them untouched — an agent cannot tell why it should supply time, gender, or the school/boundary switches. For a 12-parameter, 10-credit computation this is materially incomplete.

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 17% — just the timezone and timezoneOffset fields are documented. The description adds nothing about any of the twelve inputs: not date vs time, not gender, not dayBoundary, stageSchool, trueSolarTime, includeLuck, includeFullTable, or language. With coverage this low the description was obliged to compensate and it does not.

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 specific computation: a support-and-suppress strength reading derived from a weighted hidden-stem count, plus season/root/allies criteria and favourable elements. That is far more specific than the bare title 'Day-master strength' and implicitly separates it from siblings like bazi_hidden_stems or bazi_chart. It never states the verb (compute/evaluate) nor explicitly names bazi_day_master or bazi_element_balance as the alternatives, so it falls short of a 5.

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?

Usage is only implied: an agent can infer this is the tool for assessing how strong a day master is, and the caveat sentence hints at when its output must be qualified. There is no statement of when to prefer it over bazi_day_master or bazi_element_balance, no prerequisites, and no exclusions.

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