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

Beyond the annotations, the description discloses a concrete rate limit (3 answers per chart per 6 hours) shared across life_area and current_chapter, and a privacy/data-handling statement (birth details used only for calculation, a one-way code retained 6 hours for fair-use enforcement). This explains the non-idempotent hint in practical terms. What it does not cover is failure behavior, e.g. what happens when the quota is exhausted or the birthplace token expires.

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?

Two sentences, front-loaded with the answer contents before the quota and privacy caveats, so the agent gets the payload description first. The first sentence is dense with parenthetical notation (True Chitrapaksha ayanamsa, month and year) that adds precision but makes it slightly heavy to scan.

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?

For a three-parameter read-only tool with no output schema, the description fully specifies what the answer contains, the units of the timing output (month and year), the quota cost, the shared quota scope, and the data-retention behavior. An agent can decide to call it and predict the response shape without further information.

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 the schema already documents format and ranges for birth_date, birth_time and place_token. The description adds the prerequisite framing ('place_token from find_birthplace' is echoed from the schema) but no extra semantics such as how the recorded local time is interpreted against timezone or what to do if the birth time is uncertain.

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 names a concrete resource (sidereal birth chart, True Chitrapaksha ayanamsa) and enumerates the exact contents returned: rising sign, Moon sign and nakshatra, Sun sign with one-line meanings, plus the running Vimshottari chapter and sub-chapter. An agent can tell this is the compact snapshot tool rather than a deep-dive like life_area.

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 rather than stated: it is framed as a 'short plain-language summary' and the sibling mentions establish that life_area and current_chapter share the same quota, hinting at a snapshot-first relationship. However, there is no explicit when-to-use rule versus current_chapter, even though the overview duplicates the current Vimshottari chapter that sibling appears to provide, nor any stated prerequisite ordering with find_birthplace beyond the place_token pointer in the schema.

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