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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the series is built from the Moon's longitude, warns that a date-only query would change the result, describes the ~100 KB payload when full=true at depth=3, and clarifies that from/to returns intersecting periods including an earlier-started mahadasha.

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 dense but every sentence earns its place: purpose, depth capability, birth-time prerequisite, range semantics, full=true warning, and sibling routing. It is front-loaded with the immediate use case and structured with clear visual markers for constraints.

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 10 parameters, no annotations, and an output schema present, this description is remarkably complete. It covers the main call patterns, the key caveat about birth time, the payload-size warning, and the distinction from a sibling tool. An agent can decide when to use it and how to invoke it correctly without needing additional documentation.

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?

The schema has 0% description coverage, but the description adds real meaning to key parameters: depth (1, 2, or 3 with no separate sub-tools), full (whole cycle vs. segment), and from/to (window-based period lookup). It also indicates the time-of-birth dependency behind date/time. Some parameters such as chart_id, geonameid, and place are not explicitly explained, but the core ambiguous ones are covered.

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 states a specific purpose: Vimshottari life periods, current period and what comes next, in a single call. It also distinguishes itself from sibling tools by explicitly noting there are no separate tools for mahadasha/antardasha/pratyantardasha and by routing event-date queries to life_events.

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 gives explicit when-to-use and when-not-to-use guidance: use range parameters for historical periods, use full=true only when the entire 120-year series is genuinely needed, and use life_events instead when the user provides their own event dates. It also states the hard requirement of a known birth time.

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