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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. Beyond that, the description discloses a non-obvious behavioral trait: the result is multi-valued on a Sun-sign changeover day and collapses to a single exact sign only when place (and optionally time) is supplied. That is real added value not present in the annotations; the only shortfall is that it does not mention the timeZone escape hatch.

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 tight sentences, front-loaded with the core purpose and followed by the single most important edge case. No filler, no restatement of the name or title, and every clause carries information.

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 an output schema present, the description needn't explain return values, and annotations cover safety, so the remaining burden is small and largely met by explaining the ambiguous-day result. The one meaningful gap is that timeZone is an alternate way to disambiguate and the description never acknowledges the place-vs-timeZone choice, leaving an agent to infer precedence from the schema alone.

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 100%, so the schema already explains place, timeZone, birthDate format/range, and that birthTime resolves changeover days — the baseline is a 3. The description reinforces the place/birthTime semantics but adds no format, precedence, or conflict-resolution detail (e.g., what happens if both place and timeZone are passed, or whether timeZone alone can resolve a cusp), and it never mentions timeZone at all.

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 sentence states a specific verb and resource — 'Returns the tropical Sun sign for a birth date' — which is unambiguous and clearly distinct from siblings that deal with Moon, rising, or Venus signs. It does not explicitly name or contrast with any sibling, so it stops short of the top mark, but the resource specificity does the differentiating work on its own.

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: the input is a birth date, so the reader infers this is for natal Sun-sign lookup. There is no statement of when to prefer this over find_rising_sign or get_birth_chart, and no prerequisites are given. The cusp-day explanation is genuinely helpful context but is behavioral rather than true when-to-use guidance.

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