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

With no annotations, the description carries the full burden and does well: it enumerates the return fields, explains is_cusp and cusp_neighbour, pins the convention ("standard calendar dates"), and discloses that impossible dates like 02-30 produce a validation error. It does not state whether the tool is a pure read with no side effects or note any limits on input elsewhere, which keeps it off a 5.

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 purpose comes first, then the payload, then the error case, then an example — a sensible front-loaded order with no filler sentences. The middle return-field list is dense but earns its place because no output schema exists.

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?

Given three simple parameters and no output schema, the description covers everything an agent needs: how to call it, what fields come back, how cusp days behave, and how invalid dates fail. The only wrinkle is the stray "year" reference, which does not undermine the overall sufficiency.

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 baseline is 3: month, day and the lang enum are already fully documented in the schema and the description adds only the example usage. The mention of "year optional, ignored" refers to a parameter that does not exist in the schema, which mildly muddies rather than clarifies the parameter surface.

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?

Opens with a specific resource and derivation rule ("Western sun sign from a date of birth"), and the described return payload (element, modality, ruler, cusp) confirms exactly what kind of sign data this is. It is trivially distinguishable from the only sibling, check_compatibility, which compares people rather than deriving a sign.

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?

Clear context for use: a birth month/day produces one sun sign, year is explicitly optional and ignored, and a worked example input is supplied. It stops short of stating exclusions (e.g. what to do for dates the caller is unsure about, or that this is not for compatibility), so it falls just under the top score.

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