astroway-mcp

Official

by astroway

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Regional calendar: convert a Gregorian date

astroway_vedic_calendar_regional_date

Read-onlyIdempotent

Converts a Gregorian date and place into the regional Vedic calendar date for Tamil, Malayalam, Bengali, Gujarati, or Marathi, returning month, tithi, era year, and civil-day boundaries.

Instructions

One Gregorian date in a regional calendar at the place. Solar calendars (tamil, malayalam, bengali): month, its number, day of the month and the era year. Lunisolar (gujarati, marathi): amanta month, the tithi at local sunrise with its paksha (Sud and Vad for Gujarati), adhika flag and the era year. Each answer carries the month's first and last civil day and the rule used.

[Group: Vedic] [Endpoint: POST /v1/vedic/calendar/regional/date] [Required: calendar, date, latitude, longitude] [Cost: 20 credits (Tier 2)]

Input Schema

Name	Required	Description
`date`	Yes	Gregorian date, YYYY-MM-DD, local to the place.
`ayanamsa`	No	Sidereal school by name. Lahiri when omitted. Equivalent to ayanamsaId; send either.
`calendar`	Yes	tamil, malayalam, bengali (solar months from the sankranti by each region's rule), gujarati (amanta, Vikram Samvat from Kartika), marathi (amanta, Shaka from Chaitra).
`latitude`	Yes	Latitude in decimal degrees, north positive. Between -66 and 66: further out the Sun does not rise on some days and a Hindu day has no start.
`timezone`	No	IANA zone name such as Asia/Kolkata, America/New_York or Europe/Kyiv, or auto (default) to look it up from the coordinates. Resolved day by day: each day is read on the offset that zone kept that day, so summer time is followed.
`longitude`	Yes	Longitude in decimal degrees, east positive.
`ayanamsaId`	No
`timezoneOffset`	No	A fixed offset in hours instead of a zone, for the whole year. Ignored when timezone is sent.

Output Schema

Name	Required	Description	Default
`day`	No
`date`	No
`rule`	No
`year`	No
`month`	No
`place`	No
`tithi`	No
`adhika`	No
`calendar`	No
`monthEnd`	No
`monthStart`	No
`monthNumber`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Nov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful domain behavior: solar calendars return month/day/era year, lunisolar calendars return amanta month, tithi at sunrise, paksha, adhika flag, and each answer includes the month's civil boundaries and rule used.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, and the context block adds endpoint, required parameters, and cost without clutter. The second sentence is dense but carries relevant calendar-specific output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given eight parameters, five calendar variants, an output schema, and rich annotations, the description supplies the key calendar-specific output semantics and cost. It is close to complete, with the main remaining gap being explicit guidance on choosing this tool over related calendar tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high at 88%, so the schema already documents most parameters. The description reinforces the calendar parameter by grouping solar and lunisolar calendars and noting sunrise-based behavior, but it adds little about ayanamsa, timezone, or latitude/longitude beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly establishes that the tool converts a single Gregorian date into a regional calendar at a place, and it names the five supported calendars. It is distinct enough from a months-listing sibling, though it does not explicitly contrast with any sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'One Gregorian date' implies the tool is for single-date conversion rather than broader calendar listings, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The calendar choice is delegated largely to the schema.

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

Deploy Server