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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds the conceptual nature of the value ('unconscious imprinting point') and the cost/tier, but does not explain that it internally computes a chart, what precision/fields/compact mode do, or any deterministic-computation caveats. With annotations carrying safety, 3 is appropriate.

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 core sentence is front-loaded and economical, defining the value in one clause. The bracketed group/cost lines add metadata that is relevant for an agent but slightly dilutes the pure definitional sentence. No wasted words otherwise.

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?

The tool has an output schema, so return values needn't be described, and annotations cover safety. Still, for a 15-param tool with only 33% schema coverage, the description offers no pointer to the shared chart parameters (house system, zodiac, ayanamsa) or defaults, which an agent using this among 26 siblings would benefit from.

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 33%, but the description itself does not explain any of the 15 parameters; the fields that carry descriptions (timezone, timezoneOffset, fields, precision, ayanamsa) have extensive schema docs, while required date/time/lat/long are self-evident. The description adds no parameter guidance, so it neither compensates for the gap nor leverages the docs.

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?

It states a specific verb (find) and resource (Design date) plus a precise definition: 'the moment 88° of solar arc before birth'. That definition uniquely distinguishes it among the HD siblings (hologenetic, incarnation_cross, etc.). It stops short of naming a sibling to route against, which keeps it from 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 implied by the concept's definition – an agent doing HD work knows to call this for the Design point. However, it gives no explicit when-to-use vs the sibling astroway_hd_human_design or hologenetic chart tools, and no exclusions or prerequisites.

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