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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context not in the annotations: the city is resolved from an in-memory lookup and is not persisted, which tells the agent about privacy/state behavior. It stops short of describing the returned chart payload or any limits.

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 compact paragraph, front-loaded with the primary triggers and followed by the exclusions, with no filler sentences. The dense trigger enumeration is slightly run-on but every clause serves routing or exclusion.

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 no output schema, the description compensates reasonably by naming the outputs an agent should expect (lagna, rashi, nakshatra, planetary placements). Annotations cover the safety profile, so the main residual gap is that it never states what the response looks like or that time is optional, which leaves a small mismatch with the required-parameter list.

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 all three parameters (date, time, placeName) are already documented in the schema, including that placeName is city text geocoded in memory. The description repeats the city-text rule rather than adding format guidance for date/time, so the baseline of 3 applies. It also implies time is always supplied even though time is not in the required list.

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 concrete operation (compute a Vedic birth chart / kundli from birth details) and enumerates the specific artifacts produced: lagna/rising sign, rashi/moon sign, nakshatra and planetary placements. It is clearly separable from siblings like naksha_compatibility, naksha_daily, naksha_mangal_dosha and naksha_sade_sati, which cover different astrology products.

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?

Explicit when-to-use triggers are listed in the user's own vocabulary ("kundli", "janam kundli", "kundli banao", "what is my rashi"), plus explicit when-not-to-use cases: Western sun-sign horoscopes, deriving a rashi from a name alone, and medical/legal/financial decisions. It also states the required input precondition (birth date, time and city).

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