Asterwise

Festival Calendar

asterwise_get_festival_calendar

Read-onlyIdempotent

Hindu festivals, vrats, sankrantis, eclipses and periods for a year at a location. Each lunar festival is fixed by its lunar month (amanta, with Adhik months found from new moons and sankrantis), its tithi, and the part of the day the tithi must hold (sunrise, forenoon, Madhyahna, Aparahna, Pradosh, Nishita, moonrise), with the classical tie-breaks when a tithi spans two days, Bhadra rules for Holika Dahan and Raksha Bandhan, and the Smarta Ekadashi rule. Checked against Drik Panchang (New Delhi).

WORKFLOW: BEFORE: asterwise_geocode — when you only have a place name. AFTER: asterwise_get_panchanga — the day's limbs and timings for a festival date.

INPUT CONTRACT: year (1900-2100), lat, lon, timezone (IANA, default Asia/Kolkata). categories: optional list of festival, vrat, sankranti, eclipse, period; the default is ["festival"] (about 50 named festivals). Add "vrat" for every Ekadashi, Pradosh, Sankashti, Purnima and Amavasya, "period" for Adhik Maas, Pitru Paksha and Chaturmas, "eclipse" for eclipses.

DO NOT CONFUSE WITH: asterwise_get_panchanga_calendar — daily limbs for a month, not festivals. asterwise_get_muhurta — auspicious windows for an activity, not festival dates.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-festival-calendar/

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	Yes	Latitude in decimal degrees, north positive.
`lon`	Yes	Longitude in decimal degrees, east positive.
`year`	Yes	Calendar year, e.g. 2026.
`timezone`	No	IANA timezone of the location.	Asia/Kolkata
`categories`	No	Which entries to return: festival (default, about 50 named festivals), vrat (Ekadashi, Pradosh, Sankashti, Purnima, Amavasya), sankranti, eclipse, period (Adhik Maas, Pitru Paksha, Chaturmas, Navratri, Holashtak, Kharmas).
`response_format`	No	Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedSep 28, 2026

addedInput schema / properties / categories

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "festival",
+          "vrat",
+          "sankranti",
+          "eclipse",
+          "period"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Which entries to return: festival (default, about 50 named festivals), vrat (Ekadashi, Pradosh, Sankashti, Purnima, Amavasya), sankranti, eclipse, period (Adhik Maas, Pitru Paksha, Chaturmas, Navratri, Holashtak, Kharmas)."
+}

addedInput schema / properties / lat

Added value: +{
+  "description": "Latitude in decimal degrees, north positive.",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

removedInput schema / properties / latitude

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Latitude in decimal degrees, north positive (e.g. 13.08)."
-}

removedInput schema / properties / location

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone."
-}

addedInput schema / properties / lon

Added value: +{
+  "description": "Longitude in decimal degrees, east positive.",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

removedInput schema / properties / longitude

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Longitude in decimal degrees, east positive (e.g. 80.27)."
-}

removedInput schema / properties / timezone / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / timezone / default
```
Previous value: -nullNew value: +"Asia/Kolkata"
```

changedInput schema / properties / timezone / description

Previous value: -"IANA time zone name, e.g. 'Asia/Kolkata'."New value: +"IANA timezone of the location."

addedInput schema / properties / timezone / type
```
Added value: +"string"
```

changedInput schema / properties / year / description

Previous value: -"Four-digit calendar year, e.g. 2026."New value: +"Calendar year, e.g. 2026."

addedInput schema / properties / year / maximum
```
Added value: +2100
```
addedInput schema / properties / year / minimum
```
Added value: +1900
```

changedInput schema / required

Previous value: -[
-  "year"
-]New value: +[
+  "year",
+  "lat",
+  "lon"
+]

Changed1 schema field changedSep 7, 2026

changedInput schema / properties / year / description

Previous value: -"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."New value: +"Four-digit calendar year, e.g. 2026."

Changed6 schema fields changedSep 5, 2026

addedInput schema / properties / latitude / description

Added value: +"Latitude in decimal degrees, north positive (e.g. 13.08)."

addedInput schema / properties / location / description

Added value: +"Place name, e.g. 'Chennai, India'. Alternative to giving latitude, longitude and timezone."

addedInput schema / properties / longitude / description

Added value: +"Longitude in decimal degrees, east positive (e.g. 80.27)."

addedInput schema / properties / response_format / description

Added value: +"Output format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload."

addedInput schema / properties / timezone / description

Added value: +"IANA time zone name, e.g. 'Asia/Kolkata'."

addedInput schema / properties / year / description

Added value: +"Four-digit calendar year, e.g. 2026. Defaults to the current year when omitted."

Changed2 schema fields changedSep 4, 2026
- addedInput schema / properties / response_format / default
```
Added value: +"markdown"
```
- changedInput schema / required
```
Previous value: -[
-  "year",
-  "response_format"
-]New value: +[
+  "year"
+]
```
AddedMay 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: how lunar festivals are fixed, tie-break and Bhadra/Smarta Ekadashi rules, and that results are checked against Drik Panchang (New Delhi), which tells the agent about the methodology and reliability.

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?

Well front-loaded and organized into scannable sections (WORKFLOW, INPUT CONTRACT, DO NOT CONFUSE WITH). The opening paragraph's dense jyotisha jargon (amanta, Madhyahna, Aparahna, Bhadra) is more than an agent needs for tool selection, but it is not wasteful padding.

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

Completeness5/5

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

Given an output schema exists, return values need no explanation. The definition supplies the year range, coordinate span, timezone default, category semantics, workflow prerequisites, and sibling routing — everything needed to invoke correctly.

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 100%, so the schema already documents year/lat/lon/timezone/categories/response_format. The description largely restates the categories enum and its default; the 'add vrat for every Ekadashi...' guidance is only marginally additive. Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb+resource+scope ('Hindu festivals, vrats, sankrantis, eclipses and periods for a year at a location') and explicitly distinguishes itself from three sibling tools. An agent can route to it without inspecting any schema.

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

Usage Guidelines5/5

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

Provides an explicit BEFORE/AFTER workflow (geocode before, panchanga after) and a DO NOT CONFUSE WITH block naming the two overlapping calendar/panchanga siblings with the condition that separates them. Nothing about when-to-use is left to inference.

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

All Asterwise tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?