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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description is not required to carry it. The description adds only a catalogue of computed outputs and says nothing about computation cost, determinism of results, or data prerequisites, which is a modest contribution given a rich annotation set.

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?

A single dense sentence, front-loaded with the 'SPECIAL POINTS' label, and every item in the list corresponds to a distinct computed quantity rather than filler. It is long but the length is load-bearing for enumerating the output domain.

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-value explanation is not required, and the annotations cover the safety profile. What is missing is any usage framing or input prerequisite for a tool whose inputs (place or coordinate triple plus date/time) are non-obvious, leaving the definition adequate but 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?

The description says nothing about the 8 parameters; it is purely a list of computed points. Schema coverage is 75%, near the threshold where the schema does the heavy lifting, so a baseline 3 is appropriate — the date/time/place vs latitude/longitude/timezone alternative is documented in the schema, not the description.

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 enumerates exactly what is computed — Upagrahas (Dhuma group, Gulika/Mandi/Kala/Mrityu/Ardhaprahara/Yamaghantaka), Bhrigu Bindu, Yogi/Avayogi, Jagradadi avasthas, Pushkara, Gandanta, Vargottama, and nakshatra attributes — so the resource is unambiguous. However it never states a verb or draws a line against siblings that also cover nakshatra attributes (analyze_nakshatra_profile) or sensitive degrees/strength (calculate_strength_profile, analyze_varga).

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 statement of when to reach for this tool versus the many overlapping analyzers in the sibling list, nor any prerequisite (e.g. that a birth date/time and place or explicit coordinates are required). The agent must infer usage from the output enumeration alone.

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