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

Annotations only declare the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false); the description adds real behavioral constraints the annotations don't carry: end-exclusive range capped at 1096 days, a 90-day default when only from_date is given, depth bounded 1-20, and a place-disambiguation protocol. It does not say what happens when the range or depth limits are exceeded, which keeps it below a 5.

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 what is computed, then constraints, then input-hygiene rules, with no filler sentences. Some of the input-hygiene text ('Use city, region and country for a place', 'never guess coordinates') restates what the schema's property descriptions already say, which is mild redundancy.

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 computation, the bounded date-range behavior, depth limits, and the place/coordinate resolution rules an agent must follow. For a 5-parameter calculation tool this leaves only trivial gaps (language, depth default meaning).

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?

Reported schema coverage is 0%, so the description must carry parameter meaning, and it largely does: from_date/to_date format (YYYY-MM-DD), overlap semantics, the 1096-day cap and 90-day default, the 1-20 depth bound, and the city/region/country versus verified lat/long distinction. The 'language' parameter and the meaning of depth's default of 9 are left unexplained.

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 ('Calculate the current Vimshottari mahadasha and a bounded timeline of planetary periods from supplied birth data') and adds the sub-period depth (antardasha, pratyantardasha). This clearly separates it from sibling timing tools like get_my_timing or find_auspicious_time.

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?

Frames the tool as 'the starting point for career and relationship timing questions,' which tells the agent when to reach for it, and gives explicit operating rules for ambiguous places ('ask the user to clarify it before trying another tool with the same place'). It stops short of naming which sibling to use for follow-up work (e.g. find_auspicious_time), so no explicit alternative routing.

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