Regional calendar: month boundaries for a year

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

Annotations already declare a safe, read-only, idempotent call, and the description goes further by disclosing the actual computation rules per region (sankranti before sunset = that day, bengali after midnight = day after) and the shape of each month entry including adhika and kshaya months. That is genuine behavioral context an agent cannot get from the annotations, though the entry-field listing partly duplicates the 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 purpose is front-loaded in the first sentence and there is no filler, but the long parenthetical chain of regional rules largely duplicates the calendar enum description already in the schema, and the dense one-paragraph style makes it harder to scan. Trimming the duplicated rules would make it tighter.

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, and the description adequately covers the multi-calendar domain, latitude/timezone caveats being handled by the schema. The main gap is routing guidance relative to the non-regional and single-date siblings, which keeps it from a 5.

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 88%, so the schema already explains year, latitude, timezone, timezoneOffset and the calendar enum. The description restates the calendar meanings almost verbatim from the enum description, adding only the era context (Tamil samvatsara, Kollam era, Bangabda, Vikram Samvat from Kartika, Shaka from Chaitra) which does clarify the year field's meaning. Baseline 3 applies since the schema carries the parameter burden.

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 first sentence names the resource precisely (month boundaries of a regional calendar for a given year), and the body enumerates exactly which regional systems are covered (tamil, malayalam, bengali, gujarati, marathi) with their month-assignment rules. It never names the sibling astroway_vedic_calendar_months or astroway_vedic_calendar_regional_date, so an agent must infer that this is the regional-variant tool rather than the generic one from the calendar enum alone.

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 only implied: it returns month boundaries for a year, and the per-region rules hint at which calendar to pick. There is no explicit statement of when to choose this over astroway_vedic_calendar_months (whole-year non-regional months) or astroway_vedic_calendar_regional_date (single-date conversion), and no prerequisites or exclusions are given.

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