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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavior: sidereal (Lahiri) computation from the birth moment, degradation of results when birth time is unknown, and an explicit privacy guarantee that details are used for this answer only and never stored.

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?

Front-loaded with purpose, then parameter formats, then the privacy note; every sentence carries content. The parenthetical clauses make the middle section denser than ideal, but there is no filler.

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 values need no explanation, and the description covers the actionable gaps: input formats, the optional-time degradation case, and data handling. The only omission is routing against the sibling tools, which for a 3-param natal-chart tool is a minor gap.

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 0%, so the description must carry all parameter meaning — and it does: YYYY-MM-DD for birth_date, city+country with the example "Pune, India" for birth_place, HH:MM 24-hour local-at-birth-place for birth_time, plus what happens when the optional one is omitted.

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?

States a specific verb and resource — compute a Vedic birth star (janma nakshatra/pada), Moon sign, and ascendant — and names the exact inputs it derives them from. The natal-chart scope is inherently separable from the daily-almanac and forecast siblings, so an agent needs no further cue to pick it.

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?

Gives clear conditional context: supply birth_time when known, omit it if unknown, and it explains the consequence of omitting it (no ascendant; Moon may be one of two signs/stars). It does not, however, compare itself to alternatives or state exclusions relative to a different tool.

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