AstroWay Vedic astrology

Regional calendar: convert a Gregorian date

astroway_vedic_calendar_regional_date

Read-onlyIdempotent

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)]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "calendar": "<calendar>",
      "date": "<date>",
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "astroway_vedic_calendar_regional_date"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Gregorian date, YYYY-MM-DD, local to the place.
`fields`	No	Compact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
`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.
`precision`	No	Compact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.
`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.

AddedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real computational behavior beyond that: the tithi is taken at local sunrise, paksha labels are Sud/Vad specifically for Gujarati, adhika months are flagged, and each answer reports the month's first and last civil day plus the rule used. It does not mention the 20-credit cost or pagination, but the domain conventions it does disclose are genuinely non-obvious.

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?

Two densely packed sentences, front-loaded with the core action, followed by clean metadata lines for group, endpoint, required params and cost. Every sentence carries information; the only slight weakness is that the parenthetical calendar lists could be skimmed past since they largely duplicate the enum documentation.

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?

With an output schema present, the return shape does not need explaining, and annotations cover safety, so the remaining burden is domain semantics — which the description handles by separating solar and lunisolar calendar behavior and noting the rule provenance. Ten parameters with only four required leaves compact-mode fields like fields, precision and ayanamsa undescribed here, and no sibling routing is given, keeping it just short of complete.

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 90%, so the schema already carries nearly all parameter meaning — including the solar-versus-lunisolar split and era systems for each calendar value. The description restates that same enum semantics (amanta for Gujarati/Marathi, solar months for Tamil/Malayalam/Bengali) and adds little the agent could not read from the schema. Baseline 3 applies when the schema does the heavy lifting.

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 gives a specific verb and resource: convert one Gregorian date into a named regional calendar at a given place, and it enumerates exactly what the answer contains for each family (month, month number, day, era year for solar; amanta month, sunrise tithi with paksha, adhika flag, era year for lunisolar). That is far more specific than a restatement of the title. It stops short of naming any sibling tool, so an agent gets no explicit differentiation from astroway_vedic_calendar_regional_months or astroway_vedic_calendar_months.

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?

Usage is only implied by the phrase 'One Gregorian date,' which signals single-date scope versus a month or range lookup, but no alternative tool is ever named and there is no explicit when-not guidance. Nothing tells the agent whether to pair this with panchang, festivals, or the regional_months sibling when it needs a span of days. Adequate but with a clear routing gap.

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

All AstroWay Vedic astrology tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?