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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the computational model (lagna-derived, what each school withholds and how it orders results), which is useful domain context, but it says nothing about failure modes, permissions or output shape beyond what the schema already carries.

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 purpose is front-loaded in the first sentence, followed by school detail; there is little wasted phrasing. The text is truncated mid-sentence, so full structure cannot be judged, but what is present is tight.

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 a rich input schema and an output schema present, the description need not document return values, and it covers the purpose, the derivation basis and both schools. It is nearly complete for the tool's complexity, missing only sibling disambiguation.

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 coverage is 100%, so the baseline is 3. The description nonetheless earns a point by explaining what the `school` enum values actually mean (trikona lords vs. functional benefics led by the yogakaraka) and by emphasizing that latitude/longitude drive the whole answer, which the schema only states as a 400 constraint.

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 states a specific verb and resource — choosing which of the nine gems (ratna) to wear — and grounds it in a concrete calculation basis (the sidereal lagna). It is clear what the tool produces, but it never distinguishes itself from the close sibling astroway_vedic_gemstones_navaratna, 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?

The two schools are explained with defaults, which implicitly tells the agent which parameter value to pick, but there is no explicit when-to-use-this-tool statement, no exclusions, and no routing away from the navaratna sibling or astroway_reports_gemstone. Usage is inferred rather than stated.

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