vedika_dasha

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

No annotations are provided, so the description must carry the behavioral burden. It discloses useful context such as cost range, calculation basis (Moon nakshatra at birth), and that exact start/end dates are shown. It does not describe authentication needs, rate limits, error behavior, or the response structure, leaving meaningful gaps for a tool with no annotations or output schema.

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 description is short and front-loaded: it states what the tool calculates, then explains the primary and alternative systems, then notes the basis and cost. Sentences are informative and mostly free of waste. A minor improvement would be to surface the sibling-tool distinction earlier or more explicitly.

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?

Given six parameters, no annotations, and no output schema, the description supplies the essential context: what periods are produced, which systems are supported, the calculation dependency, and the cost. It does not describe the return payload format, but without an output schema the description's explanation of Mahadasha, Antardasha, and Pratyantar with exact dates is reasonably complete.

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 input schema already documents every parameter, including the system enum and its options. The description reinforces the Vimshottari/Yogini distinction and notes the calculation basis, but adds little parameter-specific detail beyond the schema. This meets the baseline of 3 when schema coverage is complete.

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 uses a specific verb and resource: calculate planetary period timelines (Dasha). It explains Vimshottari, Mahadasha, Antardasha, and Pratyantar, and mentions Yogini as an alternative cycle, so an agent can understand the tool's function. It does not explicitly distinguish this tool from the sibling vedika_dasha_ashtottari, which limits it to a 4.

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 description clarifies that Vimshottari is the primary 120-year cycle and Yogini is an alternative 8-year cycle, which gives context for the system parameter. However, it does not explain when to use this tool versus the closely related sibling vedika_dasha_ashtottari or any when-not conditions. Usage is therefore implied rather than fully guided.

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