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

Annotations already declare this a safe, idempotent, read-only, closed-world call, so safety need not be repeated. The description adds real domain behavior beyond that: the equal-share subdivision rule (parent_years / 12), the ordering convention (parent's next sign first, parent sign last, attributed to K.N. Rao), the default target date, and the credit cost.

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 identity of the tool is front-loaded in the first clause, followed by the arithmetic rule and the ordering rule, each earning its place. The bracketed Group/Endpoint/Cost block is boilerplate but short and useful for routing and cost awareness.

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 an output schema present, return values need not be explained, and the description covers computation method, ordering, timing default and cost. Minor gaps remain: it does not state which sign the parent mahadasha sequence starts from, nor that the parent Chara mahadasha must be resolved first.

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 body fields are already documented and the baseline is 3. The description adds one genuinely new parameter fact: `targetDate` defaults to today UTC, which the schema does not state. It adds nothing further about targetTime or targetTzOffset, which the schema leaves thin.

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 specific dasha level and resource ('Chara Antardasha: 12 sub-periods of the running Mahadasha'), so the agent knows exactly what is being computed. It does not, however, distinguish this level from the sibling levels chara_pratyantar, chara_prana and chara_sookshma, leaving the agent to rely on the tool name to know which sub-division depth it gets.

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 by the level named (fetch antardashas for a Chara mahadasha) and by the `targetDate` framing, but there is no explicit when-to-use statement and no mention of the alternative dasha-level tools or the sibling dasha systems. Nothing tells the agent when antar is the right depth versus pratyantar or sookshma.

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