divine_get_pratyantar_dasha_analysis

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

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description adds real value by disclosing that output is a generic interpretation not derived from a birth chart — a behavioral trait that affects how the agent should interpret results. No contradiction with annotations.

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 with zero waste. The action and resource are front-loaded in the first sentence, and the second sentence packs the two most decision-relevant facts (no birth data, generic output). No redundant phrasing.

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 no explanation; with 100% parameter coverage and full safety annotations, the description only needs to convey the tool's niche. It successfully communicates the three-level dasha scope and generic nature. Minor gap: no explicit routing note against the maha/antar dasha sibling tools, though the arrow notation implies the hierarchy.

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% with helpful examples for each planet parameter ('rahu', 'moon', 'mars') and a default for lan. The description adds the hierarchical relationship among the three parameters (Maha→Antar→Pratyantar), which clarifies ordering semantics beyond the schema, but the schema already carries the bulk of parameter meaning.

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 ('Get textual interpretation') and resource ('Pratyantar Dasha period'), and clarifies the structure (Maha→Antar→Pratyantar). It distinguishes itself via 'generic interpretation for the named three-planet combination' and 'No birth data needed', but does not explicitly differentiate from close siblings like divine_get_antar_dasha_analysis or divine_get_maha_dasha_analysis.

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?

The 'No birth data needed — generic interpretation' instruction conveys a key usage condition: this tool is for generic, non-personalized readings rather than chart-based ones. However, it never explicitly names alternatives (e.g., vimshottari dasha tools that DO need birth data) or states when-not-to-use it, leaving routing mostly implied by the dasha hierarchy.

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