Jaimini: Running Dasha Summary

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

Annotations already declare readOnlyHint/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-structured facts: the default target date is now, the cost is 20 credits (Tier 2), and the group/endpoint. Return-shape disclosure is unnecessary because an output schema exists.

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 well-formed sentences with the aggregate rationale front-loaded, followed by compact bracketed metadata (group, endpoint, cost). No filler; the metadata lines are terse and each carries an actionable signal rather than narrative padding.

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?

The input is a nested natal-chart body fully documented in schema, and an output schema exists, so description needn't explain return values. What remains is the aggregate-vs-single-endpoint decision and the now default, both stated; only an explicit when-not rule is missing.

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 baseline is 3, but the description adds one thing the schema does not: targetDate defaults to now when omitted (the schema declares no default for it). It says nothing about targetTime/targetTzOffset, which the schema handles.

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 ('returns the running Mahadasha for Chara, Sthira, and Shoola') plus the aggregation scope ('three running periods in a single call'). It explicitly identifies the alternative path (the dedicated /chara, /sthira, /shoola maha endpoints), so an agent can distinguish it from those siblings without opening either schema.

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?

'Convenience aggregate ... returns three running periods in a single call' plus 'Same builders as the dedicated endpoints' makes the selection condition clear: use this when you want all three at once. It stops short of an explicit when-not clause (e.g. 'use the single-school endpoint if you need only Chara'), but the alternative is directly named, leaving little inference.

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